81–89 of 89 posts
I never thought to myself, "wow, npm is slow." Is that really the core problem this is solving?
I never thought to myself, "wow, npm is slow." Is that really the core problem this is solving?
NPM 2.x is actually very slow. Part of that is just the monstrous number of files involved. For example, one of our projects has 48 dependencies, which installs 24,421 files under node_modules. NPM could probably benefit from managing each dependency as an archive. We do atomic deploys and try to make them reproducible, so for each deploy we do a fresh install from npm-shrinkwrap.json, but even when all the modules a…
Earlier quoted context omitted.
NPM 2.x is actually very slow. Part of that is just the monstrous number of files involved. For example, one of our projects has 48 dependencies, which installs 24,421 files under node_modules. NPM could probably benefit from managing each dependency as an archive. We do atomic deploys and try to make them reproducible, so for each deploy we do a fresh install from npm-shrinkwrap.json, but even when all the modules a…
Well, you're definitely in for a treat with NPM 3. And I don't mean that in a good way.
You say you are creating a more performant NPM. Is it impossible to fix the current NPM? Why not submit fixes back to NPM? Why create a new project?
In answer, why not create a new project? NPM INC controls npm, hasn't contributed it to the node foundation (despite playing a pivotal role in creating said foundation), and hasn't been especially good at taking contributions recently.
A new project dodges all those existing problems, demonstrates alternate approaches are both feasible and compatible, and destroys the myth that npm is fundamental to node, rather than simply the first of many package management systems that take advantage of node's import semantics.
You say you are creating a more performant NPM. Is it impossible to fix the current NPM? Why not submit fixes back to NPM? Why create a new project?
The irony of this question should be apparent if you search for packages on npm today. How many "new projects" are there? In answer, why not create a new project? NPM INC controls npm, hasn't contributed it to the node foundation (despite playing a pivotal role in creating said foundation), and hasn't been especially good at taking contributions recently. A new project dodges all those existing problems, demonstrates…
Earlier quoted context omitted.
Its install process is very different from the one npm uses. E.g. just look into the node_modules directory produced by npm vs the one produced by ied. Also the way it wires up dependencies (using symlinks) has been called "non humane design" by npm... so I thought it would be easier to just start a new project... it's not a lot of code/logic needed there actually... :)
npm v3 already uses the 'flat by default' design, so the node_modules folders aren't that different.
I made a quick comparison here: https://gist.github.com/alexanderGugel/a10ed5655d366875a280
Basically ied uses symlinks in order to resolve circular dependencies, while ied exploits the fact that require "falls back" in the directory structure.
Earlier quoted context omitted.
npm v3 already uses the 'flat by default' design, so the node_modules folders aren't that different.
They are extremely different. I made a quick comparison here: https://gist.github.com/alexanderGugel/a10ed5655d366875a280 Basically ied uses symlinks in order to resolve circular dependencies, while ied exploits the fact that require "falls back" in the directory structure.
> Basically ied uses symlinks in order to resolve circular dependencies, while npm exploits the fact that require "falls back" in the directory structure.
Earlier quoted context omitted.
They are extremely different. I made a quick comparison here: https://gist.github.com/alexanderGugel/a10ed5655d366875a280 Basically ied uses symlinks in order to resolve circular dependencies, while ied exploits the fact that require "falls back" in the directory structure.
Understood. Though I believe your comment (which compared ied with itself) should actually read: > Basically ied uses symlinks in order to resolve circular dependencies, while npm exploits the fact that require "falls back" in the directory structure.
You say you are creating a more performant NPM. Is it impossible to fix the current NPM? Why not submit fixes back to NPM? Why create a new project?