Where communities thrive


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

    zkochan on v7-global-bin

    test: fix (compare)

  • 01:10
    zkochan synchronize #4280
  • 01:10

    zkochan on v7-global-bin

    test: fix (compare)

  • 00:50
    zkochan synchronize #4280
  • 00:50

    zkochan on v7-global-bin

    test: fix (compare)

  • 00:18
    zkochan opened #4280
  • 00:18
    zkochan milestoned #4280
  • 00:11

    zkochan on v7-global-bin

    feat!: global bins should be cr… (compare)

  • Jan 25 22:03

    zkochan on v7

    fix(core): don't try to read th… chore(deps): update chore(release): @pnpm/core@2.5.2 and 1 more (compare)

  • Jan 25 16:47
    ysaskia commented #2933
  • Jan 25 16:21
    zkochan pinned #2933
  • Jan 25 16:20
    ysaskia commented #2933
  • Jan 25 16:20
    ysaskia commented #2933
  • Jan 25 16:11
    dolphin0618 commented #4230
  • Jan 25 16:09
    dolphin0618 commented #4230
  • Jan 25 16:09
    dolphin0618 commented #4230
  • Jan 25 15:15
    ksnyde commented #1801
  • Jan 25 14:45

    zkochan on main

    chore(release): @pnpm/core@2.5.2 (compare)

  • Jan 25 14:40

    zkochan on main

    fix(core): don't try to read th… chore(deps): update (compare)

Vaughan Rouesnel
@vjpr
i think i need something like pnpm i —force-but-dont-modify-my-shrinkwrap.
say i am reusing a node_modules dir, but i have changed branch and want to run pnpm i to use the new shrinkwrap
Zoltan Kochan
@zkochan
I think it won't update the shrinkwrap.
Vaughan Rouesnel
@vjpr
im finding that the new node_modules/.shrinkwrap.yaml is not the same as shrinkwrap.yaml which means its doing an entire deploy each time
Zoltan Kochan
@zkochan
but the outer shrinkwrap is not modified, right?
the inner is rewritten to be the same as the outer
Vaughan Rouesnel
@vjpr
hmm ok it seems like that is the case
but im seeing my shrinkwrap change each time i install
e.g.
  /soap/0.17.0:
    dependencies:
      compress: 0.99.0
      debug: 0.7.4
      ejs: 2.3.4
      lodash: 3.10.1
      node-uuid: 1.4.8
      optional: 0.1.3
      request: 2.81.0
      sax: 1.2.2
      selectn: 0.9.6
      strip-bom: 0.3.1
      ursa: 0.9.4
      xml-crypto: 0.8.5
    resolution: 1fccd7e19031a143ee53dec09afe89ba379e051e
  /soap/0.17.0:
    dependencies:
      compress: 0.99.0
      debug: 0.7.4
      ejs: 2.3.4
      lodash: 3.10.1
      node-uuid: 1.4.8
      optional: v0.1.3
      request: 2.81.0
      sax: 1.2.2
      selectn: 0.9.6
      strip-bom: 0.3.1
      ursa: 0.9.4
      xml-crypto: 0.8.5
    resolution: 1fccd7e19031a143ee53dec09afe89ba379e051e
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