Support for ./package.yml ?
Closed this issue · 30 comments
npm install search for local ./package.json file
Why don't also support ./package.yml file if ./package.json is not found ?
Exactly like Grunt support Gruntfile.js and Gruntfile.coffee, which very is useful
Personal feelings aside, this is additional complexity without much benefit, if any. There's nothing stopping you from writing a package.json or package.yml for your application or module, but it's on you (and should be) to ensure that somehow gets transpiled into appropriate json.
Thanks a lot for the quick reply. Not to much for the quick close ;)
I'm sorry that using yaml for configuration is not a good idea for you, but closing so quickly the idea on your only opinion is sad
About yaml transpiled to json, there is already a module for this https://npmjs.org/package/npm-yaml It's good but you finally need to have ./package.yml and ./package.json in the same folder. No so good
@jeromedecoster The reason that @st-luke closed it quickly is that he knows that I'll say the same thing, because this conversation has been had before :)
If the cost of two files is higher than the benefit of having your package metadata in yaml, then just use json.
For me, the cost of increasing npm's complexity in this way is not worth the benefit of parsing yaml files, because I don't prefer yaml to json.
I know this is a closed issue but just wanted to add a data point. We love using npm scripts for our frontend stuff and build tools. Being able to cut out tools like Grunt and Gulp and their sporadically updated plugin ecosystems is great. For a medium sized project our npm scripts object looks like the below. Afaik indenting the lines is as close as we can get to imbuing some human readable meaning, and making things a bit more maintainable and visually parseable,
"scripts": {
"start": "npm run -s build && npm run -s watch",
"build": "rm -rf dev/* && npm run -s html && npm run -s css && npm run -s js && npm run -s img && npm run -s svg",
"html": "mkdir -p dev; cp src/index.html $_",
"css": "mkdir -p dev/css; ./buildcss.js",
"js": "mkdir -p dev/js; browserify src/js/landing-page.js -o dev/js/landing-page.js",
"img": "mkdir -p dev/img; cp -r src/img/ $_",
"svg": "npm run -s svg:generate && npm run -s svg:mv",
"svg:generate": "svg-sprite --css --css-render-css --css-common Svg --css-prefix .Svg--%s --css-sprite spritesheet.svg --css-render-css-dest spritesheet.css --css-dimensions --css-bust \"\" --css-dest src/css/ src/svg/*.svg --transform \"\"",
"svg:mv": "mkdir -p dev/css; mv src/css/spritesheet.svg $_",
"watch": "parallelshell \"npm run -s watch:html\" \"npm run -s watch:css\" \"npm run -s watch:js\" \"npm run -s devserver\"",
"watch:html": "nodemon -q -w src/ -e html -x 'npm run -s html'",
"watch:css": "nodemon -q -w src/css/components/ -w src/css/core/ -w src/css/landing-page.css -e css -x 'npm run -s css && SOFT_FAIL=true npm run -s test'",
"watch:js": "watchify src/js/landing-page.js -v -o dev/js/landing-page.js",
"devserver": "(cd dev; live-server --port=3000 --no-browser)",
"deploy": "node_modules/git-state/bin/issues && npm test && npm run build && npm run dist && npm run compress && divshot push && divshot promote development production && git add -A && npm version patch -m \"Deployed %s\" --force && git push origin master --tags",
"compress": "npm run -s compress:js; npm run -s compress:css; npm run -s compress:svg; npm run -s compress:img",
"compress:js": "uglifyjs dist/js/landing-page.js -o dist/js/landing-page.js -m -c unused=false",
"compress:css": "cleancss --s0 --skip-import --skip-rebase --skip-aggressive-merging -o dist/css/landing-page.css dist/css/landing-page.css",
"compress:svg": "svgo --enable=removeTitle --enable=removeDesc --disable=removeUnknownsAndDefaults dist/css/spritesheet.svg",
"compress:img": "imagemin --progressive src/img dist/img",
"dist": "rm -rf dist/* && cp -r dev/ dist/",
"test": "./lintcss.js"
}Being able to add formatting and comments as in a natively supported package.yaml would be really really nice, and improve the DX for using npm scripts in this way immeasurably.
support for comments would be fantastic 👍
yeah, that's why i own 2 2560x1440 displays...
with commands that operate directly on the package manager like npm version patch, npm install --save, etc. it becomes virtually impossible to have a yaml file that stays in sink with the package.json file. It would be infinitely better to have npm support both yaml and json natively. I don't see how the complexity would increase that much. You just check if there is one or the other file and import that and make sure that it is exported in the same format. Literally two functions. Unless I'm missing something...
After thinking about it some more. It doesn't make sense for npm to support anything other than package.json in json format. I like to use npm as my task runner for the command line. This is easily done in yaml and then merged with the package.json file. Then there is no difficulty in having it overwritten by all the other process that manipulate package.json.
I'd like to add my 2 cents. JSON was a great hack when it was invented, because it gave us a serialization format with great parsing performance in the browser, since it relied on JavaScript's eval() which was written in C (in all browsers.)
But JSON is a horrible format for a configuration file. It has a lot of inflexible syntax, such as the commas at the end of lines, it does not support multi-line strings, it does not support comments, and so on.
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.
Updating the file would be trickier, but nothing that the YAML library cannot handle. There are many examples on using YAML as a config file while keeping the user's formatting and comments.
No. This is not something that is going to change. JSON is simple and therefore safe. YAML is not. Please don't open new issues about this.
Ok. Sorry @othiym23.
To close, if you want this feature check out package-yml. Cheers!
Just use .toml 🤣
@sergeysova any tutorials on this?
I mean - on how to use it with npm
@avalanche1 toml it's just proposal from me
[package]
name = "foo"
version = "0.1.0"
description = "Example project"
main = "index.js"
keywords = [
"example",
"foo",
"bar",
]
license = "MIT"
[scripts]
test = "npm run test:lint && npm run test:ava"
"test:lint" = "eslint ."
"test:ava" = "nyc ava"
[repository]
type = "git"
url = "git@github.com:user/repo.git"
[author]
name = "Foo Bar"
email = "foo@bar.me"
url = "bar.me"
[devDependencies]
ava = "^0.25.0"
nyc = "^11.6.0"
"@babel/core" = "^7.0.0-beta.42"
[dependencies]
debug = "^3.1.0"
ramda = "^0.25.0"
[config.commitizen]
path = "node_modules/cz-customizable"True dat! JSON as config file is shitty!!
But JSON is a horrible format for a configuration file. It has a lot of inflexible syntax, such as the commas at the end of lines, it does not support multi-line strings, it does not support comments, and so on.
For me, the cost of increasing npm's complexity in this way is not worth the benefit of parsing yaml files, because I don't prefer yaml to json.
Why is such a major potential improvement being overruled by personal preference? The majority of your users (see: upvotes & downvotes in this thread) would prefer to use YAML over JSON. Preferences aside, there are objective benefits to using YAML. Namely: commenting, which would result in improved readability/organization/maintainability, which would be a huge improvement over JSON.
JSON was made for data, not for configs. Therefore it should be dumped in favor of more suitable format.
For me, the cost of increasing npm's complexity in this way is not worth the benefit of parsing yaml files, because I don't prefer yaml to json.
The tide of times , man, the tide of times. You will have to listen to the users.
JSON works fine guys. I found that the only place that I want comments is for the scripts. So, I write it in JavaScript and compile it down to JSON and insert it into the package.json file. Easy peasy. No need to rock on the boat on this one when solutions already exist.
Riding in wooden carts was also fine - until there was Tesla 😉
jQuery was fine until there was React.. and so on.
JSON works fine guys.
have you seen @jedrichards comment above, could you tell me what this script tag is doing ??
"scripts": {
"start": "npm run -s build && npm run -s watch",
"build": "rm -rf dev/* && npm run -s html && npm run -s css && npm run -s js && npm run -s img && npm run -s svg",
"html": "mkdir -p dev; cp src/index.html $_",
"css": "mkdir -p dev/css; ./buildcss.js",
"js": "mkdir -p dev/js; browserify src/js/landing-page.js -o dev/js/landing-page.js",
"img": "mkdir -p dev/img; cp -r src/img/ $_",
"svg": "npm run -s svg:generate && npm run -s svg:mv",
"svg:generate": "svg-sprite --css --css-render-css --css-common Svg --css-prefix .Svg--%s --css-sprite spritesheet.svg --css-render-css-dest spritesheet.css --css-dimensions --css-bust \"\" --css-dest src/css/ src/svg/*.svg --transform \"\"",
"svg:mv": "mkdir -p dev/css; mv src/css/spritesheet.svg $_",
"watch": "parallelshell \"npm run -s watch:html\" \"npm run -s watch:css\" \"npm run -s watch:js\" \"npm run -s devserver\"",
"watch:html": "nodemon -q -w src/ -e html -x 'npm run -s html'",
"watch:css": "nodemon -q -w src/css/components/ -w src/css/core/ -w src/css/landing-page.css -e css -x 'npm run -s css && SOFT_FAIL=true npm run -s test'",
"watch:js": "watchify src/js/landing-page.js -v -o dev/js/landing-page.js",
"devserver": "(cd dev; live-server --port=3000 --no-browser)",
"deploy": "node_modules/git-state/bin/issues && npm test && npm run build && npm run dist && npm run compress && divshot push && divshot promote development production && git add -A && npm version patch -m \"Deployed %s\" --force && git push origin master --tags",
"compress": "npm run -s compress:js; npm run -s compress:css; npm run -s compress:svg; npm run -s compress:img",
"compress:js": "uglifyjs dist/js/landing-page.js -o dist/js/landing-page.js -m -c unused=false",
"compress:css": "cleancss --s0 --skip-import --skip-rebase --skip-aggressive-merging -o dist/css/landing-page.css dist/css/landing-page.css",
"compress:svg": "svgo --enable=removeTitle --enable=removeDesc --disable=removeUnknownsAndDefaults dist/css/spritesheet.svg",
"compress:img": "imagemin --progressive src/img dist/img",
"dist": "rm -rf dist/* && cp -r dev/ dist/",
"test": "./lintcss.js"
}
@botcheddevil , That's what I'm saying, do it in JavaScript or YAML or whatever your preferred language is. Then compile it to the package.json file. Not only do you get comments but you get all the flexibility you would like. Stop viewing package.json as your source file but but view it like the compiled code. You only look at compiled code when you absolutely have too. Instead look at your source code for what it does.
@jon49 Not practical. Problem is that package.json is touched/regenerated by tools like npm and yarn, so if you wanted to compile it from another source you'd have to re-compile it every time it gets touched automatically by another tool, otherwise you'll lose information. Gets messy quickly.
+1 for toml. easy to parse and edit.
Just use .toml
In my experience, Toml does not have a stable syntax (its author changes their mind every once in a while); it does not have a formal specification; it does not allow unlimited nesting of objects / arrays as JSON and YAML do; it's not well supported by libraries; and is not as widely used and tested.
Additionally, it's not backwards compatible with JSON, while YAML is: you can rename a .json file to .yaml and it will still work fine, because the latter's syntax is a superset of the former.
@tobia
rust uses toml and didnt have to change anything in my config files.
@jedrichards That's why I'm saying you do it only with the scripts object - which isn't changed by other programs. The other parts you don't normally change by hand anyways.
Since it seems pretty clear that YAML won't be used for NPM, would you consider implementing a JSON5 parser instead?
This would be an excellent compromise. JSON would still be used so nothing major has to change; and users would get some features that alleviate many of the issues mentioned in this thead, while retaining backwards compatibility.