True but beyond hobby projects this becomes a double-edged sword that swings back at you.
back
2 comments
Could it not have both? Can’t something work like Maven or Gradle but have some nice utility commands to make installing things easy? Or does that already exist?
What did you learn first, npm or Maven/Gradle?
I started in Java land, and to me, the idea that you would run a command to add a dependency has always seemed a bit weird. The file with dependencies in is part of the source code, and i don't want to modify it at arm's length with a command any more than i want to write code that way.
also fwiw, while xml is kind of not very pretty, for most dependencies, you literally google "mydependency maven", click the first link, click the version you want, then literally just copy/paste the XML into your pom.xml.
Is it as slick as 1 command? No. But it's certainly not rocket science, and most libraries github readmes even provide you the maven <dependency /> blob, so it's not usually confusing imo. And also, I do want to point out that "just npm -i mything" comes with problems like typosquatting, which is a lot less common in java afaik.
I probably learned npm or pip first so I guess it depends on what you’re used to
But with npm you can still modify the package.json and it feels simpler than than the Maven XML still (though I have no idea what’s going on with the package_lock file, but I don’t think you’re meant to edit that manually)
This is a dinosaur opinion, wow.
Would you also avoid generating client types for type-safe API consumption because you have to run a command to do that instead of writing the client yourself? After all, the client is source code for the client
I don't see these as comparable at all.
Say more.
My package.json is part of source code. I can manually write it myself and run `npm install` afterwards; or I can do both steps via a command. The end result is identical: my package.json has a new package, and my local machine has a copy of that package somewhere too.
Why wouldn't I use the command, exactly?
> The end result is identical
Citation needed.
Installing npm dependencies in different orders is not garanteed to be deterministic due to npm's package flattening and, before npm 8, plain broken dependency resolution strategy.
The package-lock.json is essential to get the same mess that the initial developer got on the same order as his install.
> and my local machine has a copy of that package somewhere too.
On maven/gradle, like on pnpm, you get one copy of each library. Not 3000x copies of lodash spread around your disk.
> > The end result is identical
> Citation needed.
What do you mean? You cited it yourself:
> Installing npm dependencies in different orders
Fortunately, there is no difference in order between running it as a command and adding it and running `yarn install`, since you already had all the other packages locally either way.
Anyways, these complaints are ridiculous, I'm sure I could dig into the past and find some broken Maven or Gradle resolutions. Let's see, 10 second time limit:
> gradle.lockfile
LOL wow.
> 3000x copies of lodash spread around your disk
LOL
Modifying text files that are human readable are a big no-no. Generating files that you never touch is absolutely ok (and is a huge thing in Java, mind you, starting from annotation processors).
> Modifying text files that are human readable are a big no-no.
Silly absolutes are a big no-no. You don't use automatic code formatting!?
Using commands to modify a literal list is fine.
IntelliJ has a dependency browser GUI that can edit your Maven/Gradle builds, but yes you're right, the CLI tooling from other ecosystems is nicer. Unfortunately the lack of robustness isn't. Just today I was debugging a sudden failure of a Python script because someone released a new version of a dependency of a dependency of a dependency which for some reason just fails to install on Ubuntu 20 without a proper error message. In the JVM world there's no such thing as a failure to install a library, because there's no install process at all, and you don't need lockfiles or any of these other hacks to avoid stuff breaking.
Yes especially in an education setting where the level of overhead of Maven/Gradle for a student just learning to program is too high.
Lol, what? NPM is amazing
For stress testing file operations?
For my Java projects, to support different environments - corp proxies, let's say - I have to have entire different gradle files, plugins, options, routing, it's just disgusting.
For my JS projects (obviously actually TS these days), I use the exact same config, it's parametrizable to take in one argument - the private registry to use.
It's amazing for really using. Unlike Java package managers.
Gradle literally creates a configuration from a script, which it can later use to build the project. It is absolutely trivial to use different proxies in different environment based on env vars, local files, etc.
Gradle is not too liked (android's overly complex builds probably give it a bad name), but it is an absolutely capable build system.
> It is absolutely trivial to use different proxies in different environment based on env vars, local files, etc.
For something to be "absolutely trivial", you would expect the average user to be able to produce trivial-looking configuration. It is certainly not the case with any Java program I've seen which has to handle two build environments.
On the other hand, all my NodeJS projects show absolutely no sign they had to be "adapted" to the second+ environment.
But sure, we can pretend Java package management is up to snuff, just throw some more "it's trivial"-type aphorisms around
IME npm sucks even more that Java if you really need to change repositories ( not just proxy ).
I was stuck under very old (and deprecated) versions of node and NPM, and at my $OLDJOB lockfiles were respected with a CI under restrictive proxy service and alternative npm repo.
"delete lockfile, npm install everything again with correct repository under VPN" was a very recurring thing on every project where someone thought "it's just a npm install, what could go wrong?".
Have you tried using profiles?
Maven supports build profiles.
Spring and other frameworks also supports runtime profiles, where you can have a YAML file for each profile/environment
The root of this thread is the person I responded to claiming NPM, as an easy-to-use package manager, would "become a double-edged sword that swings back at you"
Meanwhile, you are having to tell me Java package management is actually better because... it has profiles
I think that Java guys might have their heads too far up their asses
No, we have just worked with huge enterprise applications for 20 years and attempted to get the build system right a few times already, learning from previous attempts — as opposed to creating some mess of ad-ridden (seriously — having terminal ads, are we crazy?!!), slow (windows literally chokes up on deleting the node_modules folder, which is not a rare operation), displaying some insane number of vulnerabilities no matter what, which is also due to having way too many too small packages, and every one bringing in a huge deal of other bullshit tiny dependencies.
Oh, did you know that maven wasn’t hit by those dependency confusion attacks, being almost alone in that? Also, I can literally build a million lines repo faster than the frontend which is relatively small and just outputs goddamn js and css files..
> Also, I can literally build a million lines repo faster than the frontend which is relatively small and just outputs goddamn js and css files..
My UI type-checks, transpiles, and stores itself as an NGINX container or a static bundle on my CI in 1min10, so I'm going to go ahead and press X to doubt.
> windows
There's your problem!
Thats just rude
These downvotes are absurd.
The parent comment asserts, without evidence, that "NPM being easy to use is a double-edged sword that will swing back at you".
I have never seen any evidence of this in action. What would it even mean!? Something being easy to use being casted as a negative in-and-of-itself sounds like Stockholm Syndrome.
If you'll downvote a long-time NPM user for questioning what's wrong with NPM given how much better it is at navigating the complex corporate environment I sit in than Gradle or Maven, at least leave an anecdote.
It's all on you. You brought npm into the discussion which was until then quite generic comparing java builds against "others". You barge into a thread of people praising a certain ecosystem by defending your own turf and trying to convince everyone that your tools are actually ok. What did you expect? Sure bro, use npm, whatever.
How is it "on me" that stupid "opinions" are being expressed?
First of all, the context was:
my initial comment's GP: "I do really like how easy the packaging is in Python and JS is", "Maven and Gradle are a bit of a pain to configure in comparison"
my initial comment's parent: "True but beyond hobby projects this becomes a double-edged sword that swings back at you."
This comment CONTINUES to be a naked assertion based on nothingness. The negative points about NPM I've heard are:
* You should never touch human-readable files with CLIs (like package.json)
* NodeJS imports make many files because it's interpreted code
* running a command to install a package is "weird" and doing it manually is better
* Something about module resolution that was fixed half a decade ago but still didn't impact most shops that avoided drowning in libraries
You can't be serious that this is meaningful feedback.
> stupid "opinions"
Whatever the subject, I expect people who like a certain tech to express their distaste about other techs. I just, you know, let it slide cause otherwise it's never over. If you're looking for a bone to chew, I'd suggest you go to Reddit. Seriously.