This is a feature, Gradle is decades ahead of node build tooling.
And then to upgrade to the latest I had to manually go figure out what the latest was, and manually change the line number to the latest version. I did see there's a separate plugin you can install to now add it though, built by a third party, but still.
Decades.
But this:
> And then to upgrade to the latest I had to manually go figure out what the latest was
Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick.
I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.
It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
[0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions.
If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.
But of course you may think this behavior is a joke, I do not.
How? Why? What's your use-case?
1) For local development, I’m seeking a command I can use after pulling, to safely and quickly install any needed dependencies that have been added by others. Currently I use npm ci but it’s absurdly overkill (and therefore very slow).
2) For CI itself. I cache node_modules/ across builds, which significantly speeds up my builds. Currently I npm i, and check if lockfile changed, and if it did, checkout lockfile and npm ci.
I shouldn’t need to npm ci ever unless my node_modules/ became corrupt for some reason. Because npm ci ALWAYS blows away node_modules/, it’s not a reasonable piece of everyday functionality, it’s just a semantically ambiguous way to rm -rf node_modules/ && npm i -—respect-lockfile (made up flag I wish existed). The obvious explanation is that the npm developers couldn’t figure out how to reliably reconcile node_modules/ with the lockfile, so just gave up and shipped npm ci.
Or if the rm -rf node_modules/ isn’t strictly necessary for npm ci, then give me npm ci —-skip-drop-node-modules, that would be equivalent and fine for my purposes.
btw ci is super fast (caching) unless you have one of those modules that download the whole effing chromium after install (brain dead behavior).
What do you mean ci is super fast? Is it intended to be caching the packages somewhere other than node_modules?
There's been some bugs in the implementation but never had anything in the last few years, other than some people accidentally committing unapplied package.json changes, and built a precommit hook and a server-side check for that in many projects.
> What do you mean ci is super fast? Is it intended to be caching the packages somewhere other than node_modules?
Yes: https://docs.npmjs.com/cli/v6/commands/npm-cache#configurati... . If you want a more Java-like (to be more accurate, artifactory-like) experience, you can also opt-in for Verdaccio: https://verdaccio.org/ You can also use the artifactory itself: https://www.jfrog.com/confluence/display/RTF/Npm+Registry
I had more success with verdaccio though.
Quality of the packages has been discussed to death, say about that anything you like, but npm has been rock-solid for me in the last few years. Definitely not a joke IMHO.
I've been writing JS with npm locked to specific, exact versions of dependencies since 2014, IIRC.
Not everyone does this, obviously, but the tooling has been able to at least do a decent approximation of this for a long time (and I was and am very far from being a bleeding-edge adopter).
Pray tell me where the dependency comes from then? When I add a ‘This package requires dependency x at version y’ to my gradle/maven file, it doesn’t magically appear on my system.
Or rather, I think it does magically appear on my system, which is incredibly confusing.
Should it display ads instead and put random executables to my path? Or create a 1000000 file directory everywhere on which windows god damn chokes to open?
If you enable the general maven repository (the maven() you see at the top of many gradle build scripts), you'll get the code from maven. If you also add your personal repositories (which most people probably don't have), you'll get packages from there as well. I'm not sure how you add a second repository to node package managers, but I assume it's possible in some way without specifying the http download url.
The biggest difference between the two ways of package management in my opinion is that node packages are just a word or two and Java packages are a full com.example.product.service.package name. That's a lot better in my opinion as it distinguishes between projects much more easily. I thought node-ipc was related to the nodejs project, for example. Some nodejs packages use namespaces, but most don't.
Another difference is that nodejs has tons of tiny packages (I'll never get over how silly it is that is-odd and is-even appeared in my node folder by transitive dependencies) whereas the Java world generally uses huge packages almost exclusively. This leads to more boilerplate code (actually having to write simple functions like that yourself), but also to less dependencies that can break.
Once you do that in Node, the package lock will specify what version you've downloaded, to make it a repeatable build. You can tweak it to indicate you want to pin the version at a given levels, as well; that's done in one place, and separately from the package-lock file that gets generated, that tells you what -actually- is being used.
My follow up point is that when that version eventually goes stale, it's as simple as 'npm outdated' to determine if there's something more recent, and 'npm update' to update everything (based on whether you've pinned to a major/minor in your dependency list). You can also update specific packages with 'npm update (package name)'. I sure wish the Java community would learn this obvious 'trick' that every OS package manager enables. I know I want Jackson, say, I should be able to say "gradle install jackson" or whatever, and it would tell me all the options in the repo with jackson in the name. Then 'gradle install jackson com.fasterxml.jackson.core' and it would add that to my gradle file, with the most recent stable version. And 'gradle update jackson' would seek to update that dependency to the latest stable (with some syntax to pin the release, major, and maybe the full version, to enable 'gradle update' to update everything within a particularly defined scope).
1.1) Gradle is a build system. As such it doesn't care where you are getting your dependencies. You can skip all public package repositories and only use your own private one or mix and match. Adding repositories is literally as easy as doing the following to your build.gradle file:
buildscript { repositories { google() mavenCentral() maven("your private repo url") }
1.2) As has been mentioned in previous comments, you add dependencies to the project rather than install them in the system. Gradle then has various cache folders where these dependencies recide and will fetch those that it doesn't find locally (new libraries, new versions etc). This is akin to how most software defines its dependencies. Python's pip & requirements.txt, Flutter's pupspec.yaml etc.
1.3) Complaining about having to use a full resource identifier ('com.google.guava:guava:31.1-jre') for the dependency rather than just an alias ('guava:31.1-jre') for the package name simply sounds like complaining for the sake of it. What if a fork exists of guava ('my.forks:guava:31.1-jre'), how would that get used along side the original if dependencies are only defined by their project name?
2.1) In my books, package updating should be methodical processes where each and every update is made in isolation, thoroughly tested and then merged in. In that respect I find it very nice that the build system isn't constantly telling me about a new library version everytime it runs, as it pushes naive developers to upping all libraries to their latest versions immediatly and then scratch their heads when unexpected behaviour starts popping up all over the place.
2.2) Various IDE's have mechanisms for notifying visually about when a package has a new version available to them. There are also various tools available to check for package version statuses, such as the 'Gradle Version Plugin' just to name one. I use this plugin extensively to get information on stable dependency updates.
2.3) If you want to always use the latest version of a dependency, you have various mechanisms available to you. It is easy to declare if you want to always go for the latest major, minor og patch versions automatically. See 'https://docs.gradle.org/current/userguide/single_versions.ht...' for details. I'd hate to work an a project that had not clear version definition though as that would just signal very naive developers and/or sloppy practices (automatically going for latest patch versions is fine in my books).