@zkochan please download the basic Ember app here: https://drive.google.com/file/d/0B6psKNv4yBIcU3VXTWpld2dqQmM/view?usp=sharing
Then:pnpm i && bower i && ./node_modules/.bin/ember serve
Should see the error.
ok, I've seen this error before in a few projects. This is because the resolve package does not resolve dependencies the way Node does... We'll have to create an issue there. There is actually an alternative to
resolve that works correctly - resolve-from by Sindre Sorhus
@zkochan I took a look at
resolve-from. It seems it doesn't make any difference in terms of resolving pnpm-structure. You see, the thing is both resolve & resolve-from use node-module-path method 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 ember-cli-pretender.
and at resolve-from sindresorhus/resolve-from#6
I don't know if you checked it, but shrinkwrap.yaml looks really nicely on
git diff
it precisely shows what deps were changed where
IMHO, the most readable lockfile diffs and nicer for CR than yarn.lock and package-lock.json
but again, there is no way to disable it because pnpm's algorithm relies heavily on the shrinkwrap.yaml file. So if you don't want it in your repo, just ignore it
:) maybe they are awesome, not contesting that, but maybe some people don't want to be awesome :p ---
- generally speaking, committing generated content on a routine basis like adding/updating/removing deps is plain wrong (generating some images for instance, committing them, and maybe regenerating them one year later is a diff thing)
- whoever is working towards a clean, atomic commit history (i.e. rewrites history in the local/topic branch) increased their chances to get merge conflicts, which they didn't create in the first place
- most of the times when no.2 happens, the feeling of "whatever" takes over so the shrinkwrap.yaml becomes out of sync with its source (package.json) leading to other errors or making it impossible to git checkout a commit and run with it
- it makes total sense to have the shrinkwrap part of the distribution package yes i.e. have a stable deployment, both when dependencies are bundled in the distro, and when they are not
that said, i noticed the love and care that was given in the design of the file :clap: and i guessed the diff was a factor
.gitignore-ing the file is not enough i think e.g. what happens if someone updates the package.json manually, upgrades a dep, and then runs
pnpm install - the shrinkwrap.yaml will prevail, right? or does pnpm check modification time :clap: ?
package.json is 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?"
I can't tell how the
I think however it should be pretty good at merges because it doesn't have commas like npm's json
and it doesn't have specs in one line like yarn
shrinkwrap.yaml currently behaves when merged because I don't use it currently in a team. The company I am working at uses npm4.I think however it should be pretty good at merges because it doesn't have commas like npm's json
and it doesn't have specs in one line like yarn
yarn has something like
foo@^1.0.0, foo@^1.1.0: in a line. Which can differ on merge, in shrinkwrap.yaml always blocks differ, not lines
opened up a new issue
The new add alias was a surprise to me
Hello, I have a problem with some dependency resolution, it works fine with npm, but failed to find it with pnpm
There is a dependency declared as "inquirer-path": "" in the package.json of the dep I want to include in my app
So I can not modify it myself, this is just what I get
pnpm answer me "No compatible version found: inquirer-path@
Versions in registry:
1.0.0-alpha1, 1.0.0-alpha2, 1.0.0-alpha3, 1.0.0-alpha4, 1.0.0-alpha5, 1.0.0-beta2, 1.0.0-beta3 "
I wonder if there is a way to force resolution when this happen
There is a dependency declared as "inquirer-path": "" in the package.json of the dep I want to include in my app
So I can not modify it myself, this is just what I get
pnpm answer me "No compatible version found: inquirer-path@
Versions in registry:
1.0.0-alpha1, 1.0.0-alpha2, 1.0.0-alpha3, 1.0.0-alpha4, 1.0.0-alpha5, 1.0.0-beta2, 1.0.0-beta3 "
I wonder if there is a way to force resolution when this happen
I have no answer, but have a related to a version issue. In
package.json there 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.
@JR-Utily a dependency with no spec? If it works with npm then we'll fix it, please create an issue for it
thanks a lot
