Closed bollwyvl closed 2 years ago
Thanks a lot for starting this.
"use_prettier": "y",
"use_eslint": "y",
"use_stylelint": "y",
I'm always reluctant of adding more options to the cookiecutter (I wish it came with a way to do basic and advanced configuration :cry: ). This exposes more tooling to the beginners and because answering no to those will likely be a corner case.
more options to the cookiecutter
Yeah: cookiecutter
hasn't really evolved much from a user perspective, even if it can do more powerful things. I liked the yeoman
user experience better, but you still have to pay the npm tax to get in the door... but it had a more robust concept of storing the choices made, such that you could re-run the generator to update things... or have sub-generators that worked harmoniously.
Anyhow: as linting isn't currently exposed on the cookiecutter, i'd just leave this one... or discuss on a related PR.
Another thought (for another PR): for all three of the linters, we could move all of the config to package.json
... though I don't think there's a way to put the file ignores in.
Merging
References
Changes
stylelint
, withprettier
integrationstylelint --fix
can actually make substantive changes, e.g. ordering of properties associated with a selector, it gets called before prettier, which handles the cosmetic changes, e.g. whitespacejlpm run
tojlpm
Discussion
While I generally think starting out with more guidance towards standard compliance and best practices in as many domains as possible, is desirable to save pain down the line, I guess this (and other linters) could be made optional. So long as a project doesn't make
tsc
andwebpack
fail, it's technically fine.Even so, I'd probably make them opt-out, so
cookiecutter.json
would look more like:They could still then all be run with
jlpm lint
andjlpm lint:check
.