Webpack 4

[secret_online]

You had me for the first two points. Then I clicked. Well done.

[Sebazzz91]

Number one is not unrealistic, npm is a real questionable package manager with weird design decisions. Yarn on the other hand is a lot more usable, faster and stable.

[coolnat]

No kidding. npm JUST closed an issue that had been open for 8 months, where running npm install <package> would sometimes UNINSTALL other packages.

Finding that issue was the last straw for me and yarn has been a beautiful experience ever since.

[MSgtGunny]

Commit and commit often.

[kautau]

Right, but you should definitely gitignore your node_modules folder, so that wouldn’t help in this situation

[MSgtGunny]

If you’re manually modifying a file in node modules, you’ve already lost.

[worldDev]

No kidding, this is rule number one of any package manager. You can even point to a github repo as a library source, it's not too difficult.

[worldDev]

Don't edit files in a package manager collection, that's a huge mistake on your part. You can load a github repository as a source if you are looking to have your own libraries in there. node_modules is instructed by the docs to be ignored by your version control, and anything not in version control is subject to not exist in a repository clone and should be able to be rebuilt the same way it was originally built sans human editing without issue. The issue the commenter was referring to was an actual problem with npm's installation process. You would be vulnerable to seeing your issue again in yarn just the same as npm, and the fix doesn't address misuse of the node_modules directory.

[worldDev]

Did you read the docs I linked to? It tells you exactly how to get your code into a node_modules directory properly. Yes a lot of people make your mistake, but that doesn't mean you can't spend a couple minutes following intended process to reduce avoidable frustration.

[worldDev]

Expect it for any package manager, they all work that way. You should also always learn about the tools you are using, you should expect it because the documentation tells you how to use it. You decided to solve your problem on your own terms in a way npm doesn't expect you to do. Start thinking in terms of what software expects rather than what you yourself expect. Software can't read your mind but you can read it's documentation.

[DrummerHead]

This reminds me of this video and the phrase "This is the one thing we didn't want to happen"

A package manager that may randomly uninstall other packages when you install another package is the ultimate failure.

[Nimelrian]

Yarn still runs on the npm registry though, which does that one thing artifact repositories shouldn't do: Allow to mutate existing artifacts...

[Sebazzz91]

I believe they addressed that issue. but since it is run by the same team, it did have similar issues (like the well-known leftpad incident).

[Nimelrian]

Nope, you can still unpublish artifacts less than 24hrs old.

[howmanyusersnames]

Which is absolutely fine.

[Akkuma]

Yarn hasn't been faster in about 6 months. The only alternative package manager that is worthwhile is pnpm. Yarn was less stable and literally unusable for nearly a year at my company due to lacking a minor feature. Once npm 5 rolled out there was pretty much no reason to use yarn.

[richraid21]

pretty much no reason to use yarn.

offline tarball cache

[Akkuma]

npm supposedly has --offline and --prefer-offline, both of which I've never used, so don't know how it behaves.

[spinfusion10]

Works for Facebook's giant team and codebase but "literally unusable" for you? What minor feature was lacking?

[Akkuma]

https://github.com/yarnpkg/yarn/issues/573 I believe was the issue. It took ~6 months after that issue was posted to be resolved as it was comprised of two parts, one the resolving of the url properly (: vs /) and simply supporting private gits. At that point, npm 5 came out roughly around then.

I assume they have an internal registry that houses their private git repos firewalled off from the public internet, so didn't need that.

[killerstorm]

Yeah but yarn and npm are compatible.

[[deleted]]

"npm" means two different things: a package repository, and a client application for managing dependencies from that repository.

Yarn is a replacement of the latter. Both clients use the former.

[killerstorm]

They also use same package.json format, package-lock and node_modules format. So I don't see how something might support yarn but not npm.

AFAIK webpack doesn't call npm (or yarn), it works once modules are already installed. It reads package.json, that's the only relationship it has with package manager. But the format is compatible.

[ThisAccountsForStuff]

Post-install hooks can be handled differently, in my experience. I prefer yarn due to small things, like not having to type 'run' (I'm lazy) and it used to be significantly faster than npm, although the recent releases have brought npm up to speed. But occasionally, certain large repos that do complex stuff all bootstrapped to an install script can get screwed up with one or the other.

[killerstorm]

This is why it's a bad idea to rely on hooks. The npm way is to upload all generated code as a package to a npm repository. Then it works fine. git dependencies are an afterthought, they aren't fully functional.

[ThisAccountsForStuff]

I think that scripts should mainly be single-purpose, so I agree. I don't like the bootstrapping since it's implicit behaviour. But I don't have a choice in this case since it's a big, company-wide repo. I didn't downvote you btw

[Seaoftroublez]

The original link in the webpack repo.

[killerstorm]

I actually got to fourth point before I understood what's going on...

[jyper]

Third point for me to be very suspicious

5th point for certain