zkochan on v7.9.1
zkochan on main
chore(release): 7.9.1 (compare)
zkochan on main
feat: extend cafs object (#5186… (compare)
zkochan on extend-cafs-object
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.