We've run into a problem parsing a pnpm-lock.yaml file with version 5.4.
Keys of the form are being interpreted with a trailing underscore being part of the version:
/@babel/helper-define-polyfill-provider/0.3.1_@babel+core@7.18.5:
That is, the current implementation sees the version as 0.3.1_ rather than 0.3.1.
I found a discussion regarding the format of package keys that provides some helpful background. The short version is that the underscore should be treated as a separator.
The fix is, AFAICT, relatively simple: add underscore as a separator in the regular expression that we use to parse this. I'm going to make that update.
FWIW, the format of pnpm-lock.yaml files is, AFAICT, poorly documented. IMHO, we should should get out of the business of trying to support various undocumented (oftentimes volatile) file formats and depend on the package managers themselves to provide us a list of dependencies. We have similar challenges with package-lock.json files, for example (see #415).
/cc @reissim
We've run into a problem parsing a
pnpm-lock.yamlfile with version 5.4.Keys of the form are being interpreted with a trailing underscore being part of the version:
That is, the current implementation sees the version as
0.3.1_rather than0.3.1.I found a discussion regarding the format of package keys that provides some helpful background. The short version is that the underscore should be treated as a separator.
The fix is, AFAICT, relatively simple: add underscore as a separator in the regular expression that we use to parse this. I'm going to make that update.
FWIW, the format of
pnpm-lock.yamlfiles is, AFAICT, poorly documented. IMHO, we should should get out of the business of trying to support various undocumented (oftentimes volatile) file formats and depend on the package managers themselves to provide us a list of dependencies. We have similar challenges withpackage-lock.jsonfiles, for example (see #415)./cc @reissim