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
package.jsonthere r some modules with
*version. If the module doesn't exist in npm repo, the module won't be installed, as well as other modules from deps list. Ember CLI requires to have
*as a value for addons development. npm handles it fine and installs the rest of modules.