4 ms·

My impression was that npm does little more than fetch code from the Web and stick it in a 'node_modules' directory. I've even seen npm used for things that are

My impression was that npm does little more than fetch code from the Web and stick it in a 'node_modules' directory. I've even seen npm used for things that aren't even JS, just bunch of files. This approach ends up with multiple, potentially-incompatible versions of the same package in a project. True that's less of a problem in JS, since it's interpreted (deferring imports to runtime) and un(i)typed (no need to check if interfaces match up). Yet even that has lead to replacements/complements like yarn.

fctorial 6y ago
> This approach ends up with multiple, potentially-incompatible versions of the same package in a project. If data generated by one version of a library is being consumed by another version, that's a bug in the code that moves data between them.
oefrha 6y ago
> My impression was that npm does little more than fetch code from the Web and stick it in a 'node_modules' directory. Yes. There's hardly even a standard directory structure, let alone a standard way to convert source code to published code. Every slightly non-trivial repo basically has an ad hoc build system of its own. Ever tried to fix a bug in a package, and realized that using git://github.com/user/repo#branch doesn't work, because npm only downloads the source code, which bears no resemblance to the built products? I fixed two bugs in two third party packages within the past week, had to deal with this twice. Ran into the Node 12+ and Gulp 3.x incompatibility issue twice in the past month (with totally modern, actively developed packages), too. npm has more sophisticated dependency resolution and locking than pip, sure. Python packaging is more consistent in basically every other regard.