Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:22

    zkochan on main

    fix: typo (#5195) (compare)

  • 11:22
    zkochan closed #5195
  • 10:19
    exsesx commented #3779
  • 09:58
    palexandrefernandes commented #5176
  • 09:53
    bobbyphilip commented #3439
  • 09:51
    bobbyphilip commented #3439
  • 09:20
    zkochan deleted #5197
  • 09:12
    palexandrefernandes commented #5176
  • 09:05
    palexandrefernandes commented #5176
  • 08:59
    palexandrefernandes commented #5176
  • 08:58
    palexandrefernandes commented #5176
  • 08:18
    yw0525 commented #5197
  • 08:17
    dohooo commented #5197
  • 08:14
    17858274056 commented #5197
  • 08:05
    dohooo labeled #5197
  • 08:05
    dohooo opened #5197
  • 07:35
    pitgrap commented #5187
  • 06:54
    Valar103769 opened #5196
  • 06:54
    Valar103769 labeled #5196
  • 06:51
    dev-itsheng review_requested #5195
Zoltan Kochan
@zkochan
created an issue at resolve substack/node-resolve#130
and at resolve-from sindresorhus/resolve-from#6
Andrei Neculau
@andreineculau
question: if one does not want shrinkwrap.yaml created, is there a flag to pass on to pnpm?
Zoltan Kochan
@zkochan
why would someone not want it? All node package managers have lockfiles now because they are awesome!
but there is no such flag, if you really don't want it, you have to put it to gitignore
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
Andrei Neculau
@andreineculau
:) maybe they are awesome, not contesting that, but maybe some people don't want to be awesome :p ---
  1. 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)
  2. 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
  3. 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
  4. 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: ?
Zoltan Kochan
@zkochan
it will work. there is a specifiers field in shrinkwrap.yaml and it is matched with the ones in package.json
package.json is the boss
Andrei Neculau
@andreineculau
:clap:
Zoltan Kochan
@zkochan
have you read this article by James Kyle? https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all/
Andrei Neculau
@andreineculau
i will give it a try (generate and commit), i come back with feedback. can very well be more claps. fwiw thanks to everyone that started and contributed to pnpm. it's a breath of fresh air to see simplicity in the nodejs world :smile:
Zoltan Kochan
@zkochan
:tada:
Andrei Neculau
@andreineculau

@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?"

Zoltan Kochan
@zkochan
I can't tell how the 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
Zoltan Kochan
@zkochan
We have an interesting discussion about the possibility to override subdependencies: pnpm/pnpm#651
Andrei Neculau
@andreineculau
is pnpm install X supposed to be different than pnpm add X ? (install doesn't do uninstall and install, add does)
Zoltan Kochan
@zkochan
I think we don't currently have the add alias but it would just be an alias to install tjat would fail without args
Andrei Neculau
@andreineculau
ok, pnpm doesn't have an add alias but i can do pnpm add ?!
Andrei Neculau
@andreineculau
i see.. pnpm add will be proxied as is to npm add
opened up a new issue
Zoltan Kochan
@zkochan
We need to add a whitelist of commands that are proxies to npm
The new add alias was a surprise to me
JR Utily
@JR-Utily
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
Nik
@nikdojo
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.
Zoltan Kochan
@zkochan
@nikdojo I never heard about this use case. If it works with npm then file an issue please. With a package.json for reproducing, if possible
@JR-Utily a dependency with no spec? If it works with npm then we'll fix it, please create an issue for it
Nik
@nikdojo
Sure, I'm just testing the whole day today with all those fixes for Ember resolver. It works better now, but new issues appear, including this one.
JR Utily
@JR-Utily
this is while including https://github.com/aam229/local-dependencies in my deps
Zoltan Kochan
@zkochan
so you say the "inquirer-path": "*", part fails? That would be weird but I'll recheck tonight. The fix will be easy if that is the case
JR Utily
@JR-Utily
that's it pnpm/pnpm#865
thanks a lot
JR Utily
@JR-Utily
@zkochan thanks for the fix :)
Zoltan Kochan
@zkochan
you're welcome
Wei Wang
@onlywei
Hi, what happened to the README? https://www.npmjs.com/package/pnpm
Zoltan Kochan
@zkochan
I don't know, I published it the same way I always did
the readme is in the registry. Maybe the npm website has issues
Wei Wang
@onlywei
Spent all day making this reproducible error case for pnpm: pnpm/pnpm#867
Wei Wang
@onlywei
how does pnpm determine what URL to fetch from?
Sometimes it tries to hit:
://npm-registry.domain/p/pnpm/_attachments/pnpm-1.10.1.tgz (correct)
And sometimes it tries to hit:
://npm-registry.domain/pnpm/-/pnpm-1.10.1.tgz(causes 406)
Zoltan Kochan
@zkochan
sometimes from the shrinkwrap file and if there is no such then from the dist field of the metadata.
Zoltan Kochan
@zkochan
@onlywei the fix is ready for CR pnpm/supi#6
Wei Wang
@onlywei
@zkochan thanks! What's the best way for me to test this before you cut a release?
Zoltan Kochan
@zkochan
you can clone pnpm from master and supi from the fix/npm-enterprise branch. Link supi to pnpm, run npm run tsc in both projects
and then you can use pnpm from the cloned repo