Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 22:33
    zkochan synchronize #4259
  • 22:33

    zkochan on injected-deps-info

    test: injected deps (compare)

  • 21:44
    7rulnik commented #4260
  • 20:46
    zkochan synchronize #4259
  • 20:46

    zkochan on injected-deps-info

    feat: save relative path to inj… (compare)

  • 20:43
    7rulnik synchronize #4260
  • 20:42
    7rulnik synchronize #4260
  • 20:35
    7rulnik synchronize #4260
  • 20:34
    zkochan synchronize #4259
  • 20:34

    zkochan on injected-deps-info

    feat: always save injected deps (compare)

  • 19:25
    PabloSzx labeled #4261
  • 19:25
    PabloSzx opened #4261
  • 17:51
    7rulnik opened #4260
  • 17:14
    ruifortes commented #2255
  • 14:06
    7rulnik synchronize #4254
  • 13:35
    zkochan opened #4259
  • 13:35

    zkochan on injected-deps-info

    feat: save the locations of inj… (compare)

  • 13:22
    nujarum opened #4258
  • 13:22
    nujarum labeled #4258
  • 12:15
    zkochan milestoned #4091
Zoltan Kochan
@zkochan
when the two shrinkwraps differ?
Vaughan Rouesnel
@vjpr
notice the optional has a v
prefixed
i remember this is an issue i submitted earlier
Zoltan Kochan
@zkochan
yes, I couldn't repro
maybe the difference between inner/outter shrinkwrap causes these
Vaughan Rouesnel
@vjpr
ok so i can reproduce it everytime now
maybe its a corrupt store or something
rm shrinkwrap.yaml
rm -rf node_modules
pnpm i

rm -rf node_modules
pnpm i

shrinkwrap.yaml has changed
react-highcharts and the optional module
the second time it reports these messages and then adds them to the shrinkwrap
  WARN Cannot find resolution of /highcharts-release/v4.2.7 in shrinkwrap file
  WARN Cannot find resolution of /highmaps-release/v1.1.10 in shrinkwrap file
  WARN Cannot find resolution of /highstock-release/v2.1.10 in shrinkwrap file
  WARN Cannot find resolution of /optional/v0.1.3 in shrinkwrap file
Vaughan Rouesnel
@vjpr
i will try find where it happens in the code
Zoltan Kochan
@zkochan
I think I reproduced it.
happens when the shrikwrap.yaml inside node_modules difference from the one outside
so after a branch switch very likely
Vaughan Rouesnel
@vjpr
im seeing it without the inside and outside being different
Vaughan Rouesnel
@vjpr
so in shrinkwrap.ts pkgIdToRef, pkgVersion sometimes can start with a v
i will find the root cause
Zoltan Kochan
@zkochan
thanks
Vaughan Rouesnel
@vjpr
haha so highcharts-release puts of v in its package.json version
is this even valid?
Zoltan Kochan
@zkochan
wow
according to this site it is valid
Vaughan Rouesnel
@vjpr
haha
Zoltan Kochan
@zkochan
TIL
A leading "=" or "v" character is stripped off and ignored.
boom
i think ive seen packages with leading equals too
ah there was a bug related to that
Zoltan Kochan
@zkochan
I see, there's a semver.clean method for stripping off the v and stuff
Vaughan Rouesnel
@vjpr
cool, where is the best place to do it?
Zoltan Kochan
@zkochan
I don't know. I'd add a test that reproduces the issue first
where to put it, maybe to readPkg.ts, normalizing the version property
also we use read-pkg, which can normalize the package.json as well. https://github.com/npm/normalize-package-data#what-normalization-currently-entails
oh, and we have to be sure that after the fix, we won't save this changes to the package.json
so that we don't rewrite v1.0.0 ot 1.0.0 in the project's package.json
Vaughan Rouesnel
@vjpr
possible to get a quick fix for this published?
Zoltan Kochan
@zkochan
I'll look into it
Zoltan Kochan
@zkochan
I will publish a fix in 30 minutes
Zoltan Kochan
@zkochan
I've prepared a new article about pnpm. pnpm's strictness helps to avoid silly bugs: https://www.kochan.io/nodejs/pnpms-strictness-helps-to-avoid-silly-bugs.html
Vaughan Rouesnel
@vjpr
Nice post. Flat node_modules was such a bad design decision.
Zoltan Kochan
@zkochan
What also disturbs me is the devDependencies. Sometimes I start using them in normal code.. but once it gets published, it breaks
Vaughan Rouesnel
@vjpr
It's a shame too, because it flat node_modules will become such a norm thst I see library owners refusing to adhere to the resolver spec.
When trying to get PRs in to fix pnpm compatibility
Zoltan Kochan
@zkochan
yeah, some people see it as a feature
Vaughan Rouesnel
@vjpr
Yep
:(
I think the main argument for it was windows file paths