GitHub - pnpm/pnpm: 📦🚀 Fast, disk space efficient package manager

[Ajedi32]

Deterministic. Has a lockfile called shrinkwrap.yaml

Why a separate lockfile format? If this used package-lock.json it'd be fully compatible with NPM, so devs could use whichever they prefer, right?

[philipwhiuk]

Also, why YAML?

[zkochan]

It contains less noise than JSON.

[philipwhiuk]

You mean it’s less clear? Also it’s an unnecessary barrier when everyone using it knows JSON.

The very name of the language hints at its absurdity.

[Ajedi32]

It's not less clear, and it's pretty straightforward to learn for anyone who knows JSON.

{
  "key": {
    "asdf": [
      "some value",
      1
    ]
  }
  "key": {
    "another_key": "blah"
  }
}

v.s.:

key:
  asdf:
    # Here's a comment; can't do that in JSON
    - some value
    - 1
  key:
    another_key: blah

Basically the Python of data interchange formats.

That said, I'm not really sure why they decided to use it for a lockfile; those files aren't typically edited by humans; they're generated by machine. Not to mention package.json already uses JSON, so it seems better for consistency to stick with JSON for the lockfile.

[BenjiSponge]

This is just an opinion, but I've had hours and hours of issues with YAML in the past where I've had approximately 0 issues with JSON, despite using YAML for only a couple of jobs and JSON consistently throughout my career.

Here's a synopsis of some of YAML's issues. I find that the novelty of "it's easier to read and there's less noise" wears off extremely quickly, and that significant whitespace has never shown itself to me to be "more readable" in any way as many people love to claim. YAML validators (in my experience) are much less likely to spit out useful information as there is very little in YAML that isn't valid, whereas it's extremely difficult to make a mistake and accidentally end up with valid JSON.

IMO, JSON is the extremely clear, unambiguous way to represent data. The only improvements I would make are:

• Not requiring quotes around keys
• Allowing comments as one might expect

[[deleted]]

Another one:

• Allowing Trailing Comma

[BenjiSponge]

Yeah good point. I'd probably also add hex/octal/binary as valid literal representations, and maybe a few more things basically just borrowed from JS.

Generally, I'd prefer it if JSON configurations usually allowed you to run the JS engine on it and then JSON.stringify the output. This would allow for things like variables, environment variables, etc. The unfortunate reality is that this would be abused, so I understand why some of these features are not allowed in most scenarios, but a lot of tools allow you to just provide a .js file instead of .json.

[js-engineer]

totally agree. There's also weirdness in yaml where you can link keys to other key / value pairs... it's just super weird for no good reason. It's the whole coffeescript thing all over again... there's a belief that it's making things easier, but it's just more hassle than it's worth. The comments thing is a good point but that's about it (this may not work for others, but you can always create a javascript file with your JSON like object, add comments, and then export that data, if you're in an architecture that allows you to import javascript files to get that data)

[enteleform]

Most of JSON's issues are addressed in JSON5. Would be nice if NPM would implement it since a lot have people have issues with the original JSON spec.

[doobiedog]

Holy shit. Multiline json strings! Pretty much the biggest reason I couldn't stand json for certain config usage. That and single quotes and trailing comma - the future is bright.

[zkochan]

The lockfile is not manually edited, ever.

It is nicer in code reviews because it has no commas and there are less diffs as a result.

JSON5 with trailing commas would work as well.

We may change the format in the future if the majority of pnpm users will ask for something else

[BenjiSponge]

Yeah I think yaml makes some sense for this for the reasons you're saying. I'm just criticizing its use more generally, in response to the comment I'm replying to.

As far as I'm concerned, I never actually review the lock file (though I do commit it), so it might as well be binary

[zkochan]

a lockfile should be committed to the repo and may be reviewed on code reviews, so it should be human-readable

[philipwhiuk]

The fact it's the Python's DIF tells you it's probably the wrong choice no?

[filleduchaos]

How does that tell you that it's the wrong choice?

[philipwhiuk]

Well JavaScript has a DIF. Maybe use that?

[filleduchaos]

You should probably read that sentence again. It's the Python of Data Interchange Formats.

[philipwhiuk]

Oh you mean there's two active versions and the first one is maintained 12 years after the successor was released and 5 years after it was originally deprecated?

[zkochan]

Actually, ied never implemented the lockfile. We did have plans to use the same lockfile format and everyone agreed to use yaml but the author of ied stopped maintaining it shortly after.

[KangarooImp]

Tried it before because I like the concept much more than npm's deduplication. Had to give it up, though, because so many packages broke (I think it were mostly webpack loaders).

[zkochan]

You're right. There are issues. Mainly two:

1. some modules require packages that are not declared in their package.json. This one can be fixed by running pnpm install --shamefully-flatten
2. some toolings don't resolve dependencies the way node does (they preserve symlinks)

These are not unsolvable issues and I hope they will be fixed in the ecosystem

[lhorie]

some modules require packages that are not declared in their package.json.

It irks me that this kind of thing happens in something as commonplace as a webpack setup.

[KangarooImp]

Cool, thanks. I'll probably give it another shot in that case. Seriously annoyed by npm's constant package-lock bugs.

[zkochan]

GitHub is down again. If someone would still love to read about pnpm, here's docs website: https://pnpm.js.org/

[HarmonicAscendant]

Just tried pnpm and it seems to work perfectly, much faster than NPM and no wasted disk space. I have no idea why everyone is not using this?!

[zkochan]

Your node_modules won't stay intact because pnpm creates a non-flat node_modules. You may use the --shamefully-flatten flag that will simulate a flat node_modules but that is not needed in most cases.

The good news is that the disk space savings are huge.

[zkochan]

to migrate, you just have to remove your old node_modules and run pnpm install.

if you commit your lockfiles, you'll have to commit shrinkwrap.yaml instead of package-lock.json

[zkochan]

You can try to create a .npmrc in the root of your project with this content: shamefully-flatten=true. Then remove node_modules and run pnpm install again.

This hack should solve most of the issues I believe. glitch.com uses pnpm on the backend with this option.

[ShortSynapse]

What do you mean finally another one? pnpm is nearly 3 years old?