@/all pnpm version 1.3 is out
It is 5% faster than 1.2 and has a nice new summary of added/deleted root dependencies:
all the changes here
[WARN] long wall of text coming up
I didn't know about pnpm until today actually, but it sure sounds great :clap: .
Before I give it a shot in my team, I wonder if you have already solved the following problem: creating a deployable bundle that is space-optimized when unpacked (the archive compressor would take care of most of the duplication, but we have limited disk space when unpacking the bundle).
A bit of context is that today we do something similar to pnpm (i.e. we don't use npm install the regular way, and use symlinks to gain speed) and at build-artifact step, we actually do a full copy and call
npm dedupe <rant>npm@3 actually, since that's the only one that still works properly...</rant>
AFAICS using pnpm, instead of our install setup, should work just as well, and then we could still do a full copy (i.e. no hardlinks) and call
But do you (pnpm users or pnpm itself) have anything to aid the need for a deduped node_modules ? Thanks!
Hi! We're happy you have discovered pnpm!
pnpm would be a perfect choice for your team if you are currently hacking npm with symlinks. pnpm uses a symlinked node_modules structure and it hard links a package/version only once to a project, then it
creates symlinks to create the dependency tree. Read more about the symlinked node_modules here: https://github.com/pnpm/pnpm/blob/master/docs/symlinked-node-modules-structure.md
pnpm doesn't need dedupe because the structure it creates is always the same. It is very deterministic. Nothing that is not needed is added or is left in node_modules.
Cannot find module 'route-recognizer' from '/my-app/node_modules/.registry.npmjs.org/ember-cli-pretender/1.0.1/node_modules/pretender', so it can't find deps in a flat structure of modules. I read all the docs I could find and issue tickets for pnpm/ember-cli, but seems nothing points on this. Does anybody have experience using pnpm with Ember, or have any idea where the problem is? Appreciate any help, thanks.
Hi, this is just a symlink, dependencies of
pretender won't be resolved from this path
/my-app/node_modules/.registry.npmjs.org/ember-cli-pretender/1.0.1/node_modules/pretender. The real location of pretender is used to resolve
route-recognizer, which is probably
and there should be a symlink to
If you can file an issue with steps to repro, we'll be able to help. Ideally with an example repo or a package.json
@zkochan please download the basic Ember app here: https://drive.google.com/file/d/0B6psKNv4yBIcU3VXTWpld2dqQmM/view?usp=sharing
pnpm i && bower i && ./node_modules/.bin/ember serve
Should see the error.
resolve-from. It seems it doesn't make any difference in terms of resolving pnpm-structure. You see, the thing is both
node-module-pathmethod to get a list of possible directories for a module. But none of them provide a possibility to get a proper dir name for
node_modules/.registry.npmjs.org/MODULE_NAME/VERSION/...'coz no module version is available at this time. And there is no symlink to it in the current folder of
pnpm install- the shrinkwrap.yaml will prevail, right? or does pnpm check modification time :clap: ?
package.jsonis the boss
@zkochan missed your link. yes, i read it, pretty much when it was published. sorry if it doesn't change my stand.
i hope we can at least agree that issues like these are not just smoke - yarnpkg/yarn#2155 yarnpkg/yarn#1776 and similar thread on all package managers that have a lockfile. And most of them end up saying "yes, commit it, because it's going to make your life easier, but when you get merge conflicts, delete it and regenerate it" --- and on each one there's a person that gets the lightbulb "hold on.. if I have version A from 1995, version B from 2000, I want to merge them them, get a conflict, I delete and regenerate in 2005, doesn't it mean I will basically upgrade all sorts of sub-dependencies and loose the lock on them?"
shrinkwrap.yamlcurrently behaves when merged because I don't use it currently in a team. The company I am working at uses npm4.
foo@^1.0.0, foo@^1.1.0:in a line. Which can differ on merge, in
shrinkwrap.yamlalways blocks differ, not lines