Use fairly explicit version numbers for dependencies

[cletusc]

From #320:

This defeats the whole point of node (or any other packaging system with version control).

This defeats the whole point of semantic versioning. By specifying * as the version, that's telling npm that you'll accept anything, no matter what. Whatever is latest on npm is what you will get, this includes alpha, betas, major releases, prerelease, whatever is newest on npm. By specifying 1.* or 1.2.*, that means you are opting to get only new features or bugfixes, but not releases that can break backwards compat. As is, a PR could work today, but be broken tomorrow because one of our deps decided to release a known to break release (major) and we just accepted it.

My $0.02 is that we should be explicit with version numbers to at least the major release.

[Martii]

we should be explicit with version numbers to at least the major release

Leaning towards +1 at the moment for package.json with npm distributed modules. GH urls may be another story since that is a commit hash on some projects, or a date, or non-existent.

We do however have an issue with some packages right now. ace-builds for example uses a date and isn't officially listed in the npm repo. :\ See also the READEME.md. I'm still adding things to that because there are still the cloudflare CSS references that I ran into a while back too... those, as I stated before, should stop being present in our code and maintained on production/dev instead of some user account out there that paid for cloudflare access that may or may not be the project maintainers.

[cletusc]

A lot of the work you've done on the readme could be eliminated by david.

[Martii]

A lot of the work you've done on the readme could be eliminated by david.

Using yields https://david-dm.org/OpenUserJS/OpenUserJS.org.png (dependencies up to date which is definitely not true). Plus we wouldn't want just a quick yes or no. Interesting linkage though... may just add it at the top for kicks. ;)

[cletusc]

https://david-dm.org/OpenUserJs/OpenUserJS.org.png yields the correct image. repo needs to be the actual repo name, not "repo". https://david-dm.org/OpenUserJs/OpenUserJS.org is the full-blown details of our repos.

[cletusc]

dependencies up to date which is definitely not true

But they are up to date, which is the point of this issue. Specifying * as the version means you'll take anything whatsoever, so it is always up to date, but potentially breaking. That's why we specify 3.5.1 for Express, because our code isn't written to use the breaking changes in 4.*.

[Martii]

needs to be the actual repo name, not "repo".

Figured that out before you posted this. ;) I added it to the README.md however it's too vague to be useful. Yes or No isn't a good visualized diagnostic tool.

But they are up to date, which is the point of this issue

If we fixed the major versions to be constant it would still probably say up to date. ;)

[cletusc]

If we fixed the major versions to be constant it would still probably say up to date

If the most up-to-date major release is the one we specify, then that would be correct. Take Express for example:

If we specified 3.x, we'd get the bugfixes and features for express, but not the breaking changes. Express still isn't up to date, and david says that. This issue is about making sure we aren't just blindly accepting all versions.

[Martii]

but not the breaking changes.

Maybe... see #315. They did provide a backport for it for now but we'll see what their next version number is. :)

Take Express for example

express README.md is using shields.io. Setting david to theirs yields this . How did you get that whole screenshot? n/m https://david-dm.org/OpenUserJS/OpenUserJS.org

David is currently BETA, which means it may be unreliable, unavailable or not working.

Interesting quote from them. It's in our README.md so we'll see what it does over time. :)

[cletusc]

Maybe... see #315. They did provide a backport for it for now but we'll see what their next version number is.

You deprecate in minor releases, remove in major releases. As we are specifying * as the version, we are accepting major releases. If #315 doesn't get fixed before moment updates, any PR after moment updates may work for the PR submitter, but not for anyone else.

How did you get that whole screenshot?

See the full blown david summary that I already linked above.

@sizzlemctwizzle @jerone @Zren The rest of the team needs to weigh in on this. This shouldn't even be an argument.

David is currently BETA, which means it may be unreliable, unavailable or not working.

Interesting quote from them. It's in our README.md so we'll see what it does over time. :)

This issue is about managing our dependencies. Regardless of whether we use David or not, things will break at some point.

To prove that this is an issue, clear your node_modules folder, change the express version to * in the package.json, npm install, then try the site. It will fail.

[Martii]

You deprecate...

I know how major.minor.build works. Been doing that for more decades than I care to remember. ;)

This issue is about managing our dependencies. Regardless of whether we use David or not, things will break at some point.

You are the one that brought up david not me. :) I'm more than aware of the dependencies being out of date for quite some time. If you recall #249 was created by myself. This particular issue here is a step in that direction but you keep having me try new things out so I haven't had a chance to link it in here. :p

See the...

Again you didn't give me enough time to try things out before responding. Davids documentation isn't all that great but it's in our README.md for now including the linkage that I figured out before you responded.

To prove that this is an issue, clear your node_modules folder, change the express version to * in the package.json, npm install, then try the site. It will fail.

My networks aren't exposed to the general internet inbound so it will fail regardless because david won't be able to get in. Moot issue.

Anyhow I think we ought to let the others have a chance with their say too. @OpenUserJs/admin @OpenUserJs/owners @OpenUserJs/backend @OpenUserJs/frontend

[cletusc]

Again you didn't give me enough time to try things out before responding.

Please don't edit your posts so frequently. I posted the exact same time you edited. Test what you need, do the research, then post. I apologize for being rude, but it is really hard to keep up with the amounts of edits you do. I have to refresh multiple times while composing a post, and multiple times after to make sure my post is still relevant.

My networks aren't exposed to the general internet inbound so it will fail regardless because david won't be able to get in. Moot issue.

This isn't about david. I referenced david solely because you referenced the README which showed out dep. status. Ignore david. Consider david 110% off-topic.

1. As-is, right now, run the site locally. It works, correct?
2. Delete your local node_modules folder.
3. Change the version of express in our package.json to *.
4. Run npm install.
5. Run the site locally again. It fails, correct?

The failing is because you specified * and it is pulling the latest version of express, which isn't compatible with our code.

[Martii]

don't edit your posts so frequently. I posted the exact same time you edited. Test what you need, do the research, then post.

That's not going to happen ever. As I've told @joesimmons give me at maximum about an hour between replies. You are quite familiar with my meta forum responses. I'll do my best to keep things brief but you also took a tangent with david that I thought would be useful in our README.md e.g. I'm listening and acting upon it since it's not part of the BLOCKING label by any means with the README.md. Thanks for that badge intel btw. :)

The failing is because you specified * and it is pulling the latest version of express, which isn't compatible with our code.

Uhm stating the obvious there. Someone else said this a while back that express 4.x isn't compatible with our code. We're fixed for whatever that reason was. I'm not saying that there isn't room for improvement but it seems to me like you are being a little too demanding in this respect. I know the issues we have and I also know what deficiencies we all have here on this project especially with only a handful of the staff/people contributing code and commenting. I appreciate when you come in because it offers different perspectives just like @jerone, @Zren and everyone else. I just wish the rest would pop in more often.

Getting back to ontopic... my leaning hasn't changed and we (that includes you) need to give someone else a chance to respond. Jerone is in a different time zone so expect delays. :)