support package.yaml format

[wclr]

Why not support yaml package files?

YAML

1. supports comments
2. supports multiline
3. supports external imports
4. prettier too look at
5. and the main reason: start with the same letters as "yarn" and contains the same number of letters.

So that:

1. yarn init --yaml would create package.yaml (or package.yml) instead of json
2. if --yaml not specified yarn would also lookup for package.yaml (yml) along with package.json
3. also include ability to convert json <--> yaml

And npm wouldn't want to do this (as many other useful things)
npm/npm#3336

I've seen this issue:
#178

I wouldn't worry about interoperability with npm because it is already broken in many other cases, and json still will remain default option.

Also maybe option for custom package file name could be added.

[wyze]

Please open this up at yarnpkg/rfcs.

[rmm5t]

I know getting package.yml support accepted might be a long-shot, because NPM was so against it and "because backwards-compatibility," but it's a path that I whole-heartedly agree with. IMO, JSON is a great data interchange format but not something humans should write and read, and the benefits of YAML for a dependency management config (especially for deployed packages like websites and apps) far outweigh the potential downsides.

@whitecolor Were you planning to submit the associated RFC for this, or would you prefer someone else do it?

[wclr]

@rmm5t I have no plans for this.

[mormahr]

@rmm5t please submit one 😊

[clayrisser]

This would be ammmmazzzing

[ghost]

And how we are supposed to add comments in a package.json file then?

[danielkcz]

There is a somewhat lengthy discussion over at NPM about this and by looking at thumbs it's quite a popular feature request, but they basically forbid it because of personal preference. Would be nice if Yarn would be more open-minded on this. npm/npm#3336

One interesting quote from that issue by @tobia

YAML is backwards-compatible with JSON, meaning that a JSON file is also a valid YAML file. But YAML adds all those additional features in a very flexible and human-friendly syntax. Replacing JSON.parse() with YAML.parse() should (in theory) not cause any problems and it would let people use such advanced features as comments in a configuration file.

@rmm5t I assume you haven't considered writing RFC? I don't feel for that either, we need some brave hero who can see some light in this... Personally, I love Yaml, even if was only about getting rid of those lame dangling commas, it would be a win, but comments and more concise syntax are great bonuses as well.

[rmm5t]

@FredyC No, I don’t plan to write an RFC for this. While, I would very much prefer Yaml, after much thought, I don’t feel that this is something that Yarn can do solo. For example, most of my projects need to stay compatible with NPM, even though I only use Yarn.

[fantapop]

This may not be the correct bug to debate about this but having support for a .js file for the package definition would be much more useful than .yml in my opinion. Many other projects allow this type of programmatic config (node-config, serverless, webpack, etc) and I much prefer it. Being able to comment is only the tip of the iceberg. Imagine being able to run all of your favorite preprocessors on your package definition (i.e. eslint, prettier, jest). Imagine being able to require your shared repo which contains the definitions of all of your common package scripts and dependencies. This would solve one of the biggest pain points of using the multi-repo pattern.

[danielkcz]

@fantapop I think it's a bad idea. Given that package.json file is more like a metafile used to control installation (and other) process, it might be rather an error-prone. The whole file would need to be executed before any operation could even happen. That would be probably slower than just parsing JSON/YAML file. Also, any package running arbitrary code before installation even begins is quite frankly terrifying.

Btw, you can use Prettier on JSON, but I do not recommend it, because NPM/Yarn would overwrite your formatting eventually.

[hzamir]

JSON doesn't meet the most basic requirements for a configuration file (IMO) since it does not accept comments. What could be more basic than the ability to include comments as to why certain dependencies or versions are specified? Also json is unnecessarily noisy, loaded with unnecessary double quotes.

I also don't think that backward compatibility is an issue, since any time someone needs the file in .json format it is trivial to convert. I also think setting an example would encourage npm to do the same, since after all, aren't they playing catch-up with yarn at this point?

[clayrisser]

Maybe we could scrap backwards compatible and build yyarn (yaml-yarn), then the node community would have 3 package managers for node. Instead of having noisy configuration files, we would have a noisy experience figuring out what tool to choose for handling our packages, as if the Node community isn't already noisy when it comes to choosing tools.

[hzamir]

I just included the any-json module as a dev-dependency, added a json script that converts the package.yaml into package.json. So the package.json is derived, I only manually update the yaml file, and when I build it updates package.json.

[fhewitt]

For people who came here like me and think "what a bunch of lazy developer who didn't listen to their user base"...

After some thinking, I realized that this came with some serious technical challenge. The fact is that both JSON5 and YML parsing don't preserve the comments (by definition). This means that any action that change package file would remove the comments, or need complex text difference analysis to reinsert the comments into the new generated output. Definitely not something I would like to code, maintain and support. The nightmare when users start to complain the their comments don't stick with the correct line when adding new dependencies and the list got reordered... ew...

When absolutely needing comments, because the script is absurdly complex, I use something like:

"scripts": {
    "__symlink": "For shared models and utility functions",
    "symlink": "node scripts/symlink.js"
},
"__dependencies": "Waiting 2.7 release for TSOA to update because it will came with awesome new features and the update can wait".

That's kind of wrong, can't be used everywhere in the file. But because it's still JSON data it can be preserved properly when using yarn commands.

Or I use the readme file, or a page in our wiki...

[sarimarton]

@fhewitt This unfortunately gets screwed up by sorting package.json, which is a highly encouraged practice. Furthermore, the lack of syntax highlighting renders it quite hackish and hard to recognize. https://eemeli.org/yaml does support parsing yaml with comments preserved.

[hzamir-pai]

Pnpm supports package.yaml, if yarn would support it also, there would be critical mass. It just screwed up npm-runall and similar scripts that import an assumed package.yaml file, so I forked that one to use on pm's package.Jason/yaml resolution logic.

I'm still hesitant to update package.jsons to yaml until another packager joins the club.