Support package.yaml

[lorefnon]

Will it be feasible to support a yaml alternative to package.json ?

JSON is really not a good configuration format and yaml would be beneficial in many ways:

• Supports comments

  This is the single biggest advantage. I find myself wondering so many times why a specific rc/alpha/outdated version was included in the package (instead of the latest stable), Some details about a script etc.

• Supports anchors

  Remove duplication between peer deps and dev deps etc.

• Multiline strings

  Useful for npm scripts involving commands

etc.

[zkochan]

I like the yaml format. I'd be OK with this feature. However, we currently don't implement the publish command and publish would have to convert package.yaml to package.json

[lorefnon]

I see. In that case will it be fine if I generate (or idempotently overwrite) the equivalent package.json (if package.yaml exists) whenever cli is run ?

Perhaps this can be made more safe by inclusion of an additional entry like { "pnpm" : { "autogenerated" : true }} in the generated package.json which indicates to users that it is auto generated and also prevents package.json from being overwritten if not present (in which case the cli will abort with an error).

[octogonz]

Cool!

We recently investigated JSON5 vs YAML, based on a couple requirements:

1. We wanted to put comments in our NodeJS config files

2. We don't want a mixture of different file formats across our systems. (Inconsistency adds complexity without any benefit.)

It seemed to me that JSON5 has a number of advantages compared to YAML:

• YAML requires additional learning beyond plain JavaScript. Its design philosophy is to provide many equivalent notations for a given object. In practice this means a /lot/ of nuances to learn.

• All existing JavaScript tooling (parsers, pretty-printers, syntax highlighters, member-sorters, schema validators, linters, etc) can process JSON5 files. The format is a proper subset of ECMAScript. By comparison, YAML requires additional tooling on each platform where it may be used.

• Spacing changes can break things in YAML. This is no issue for a specialized audience like Python engineers. But config files are often edited by novices who maybe don't even know what a TAB character is.

• YAML seems to be a complex dependency. As an example, installing js-yaml brings along all of ESPrima and has polyfill requirements. By contrast, json5 is a simple self-contained library. (And if you don't have the library handy, you could use eval() to parse JSON5.)

From a functional perspective, YAML doesn't seem to have any killer features that JSON5 lacks. Thus, it seemed difficult to justify "yet another" file format if there is no clear advantage.

One major disadvantage of JSON5 is that it's less widely used. The problem it solves is somewhat specific to NodeJS.

[zkochan]

From an implementation point of view, the complex part is adding support to any alternative. So once we support anything else than .json, supporting X formats is easy.

We have js-yaml as a dependency already, so I think it makes sense to support .json5 and .yaml as well.

Personally, I think it will be cool to use multiline string in YAML. For instance, I could rewrite the scripts in pnpm/package.yaml like this:

  scripts:
    pnpm-registry-mock: pnpm-registry-mock
    test-tap: ts-node test --type-check
    test: >-
      pnpm run lint &&
      pnpm run tsc && 
      rimraf ../../../.tmp/ &&
      rimraf node_modules/.bin/pnpm &&
      pnpm-registry-mock prepare &&
      npm-run-all -p -r pnpm-registry-mock test-tap
    tsc: rimraf lib && tsc
    release: sh .scripts/release.sh
},

[zkochan]

Created #1803 to track what commands support the new manifest formats

[zkochan]

🚢 3.3.0-0