scscgit
commented
3 years ago I'd also suggest removing the .prettierrc and instead moving its content to package.json (as supported by cosmiconfig) in order to reduce the unnecessary amount of files in the root directory. Most users won't ever touch the defaults, and there doesn't seem to be any advantage in a separate file anyway (e.g. having JS available):
"prettier": {
"semi": false,
"singleQuote": true
},
lint:prettierscript to provide users with a recommended way to enforce a unified code style in the project, which is less accessible if they have to research the correct usage, or even access it via npx. The intention should be to provide a configuration where linters don't conflict with each other. Also included this in thelintscript by default to enforce best practices (but anyone is free to remove it). I can't comprehend why new users should be forced to research this on their own; we need a reference solution as a source of truth for example if we want to setup IDE extensions and make sure that they converge on the same code style (definitely not trivial with all the options in VSCode like Vetur, Prettier, Eslint, built-in...)..prettierignore, especially to exclude directories like.nuxt. Due to https://github.com/prettier/prettier/issues/8288 and https://github.com/prettier/prettier/issues/8506, we have to duplicate the.gitignorecontent without being able to include it e.g. by referencing two ignore files. Users may require this file to differ from their.gitignore, e.g. if they need to include results of code generators. Note that there is no analogy ofeslint-disable(https://github.com/prettier/prettier/issues/9310), so this file cannot be avoided. As for code re-use (DRY) in the template file, I was unable to import the content via EJS, and the SAO generator lacks a copy action: https://github.com/saojs/sao/issues/176lintfixscript to provide a quick way of fixing any issues in the entire project, especially before they make a commit. Prettier includes--list-differentto display only changed files (unified with other linters) instead of every single file in the project.prettierto the beginning oflintfixto avoid ESLint causing conflicts of rules like no-return-assign (without having to use Prettier via ESlint by installing eslint-plugin-prettier and using plugin:prettier/recommended), fixing https://github.com/nuxt/create-nuxt-app/pull/827create-nuxt-app: runlintfixat the end instead of hard-coding all of the scripts individually; just like what the user is supposed to do on a regular basis.lint-stagedinpackage.jsonto include prettier by default, where it requires--ignore-unknownhttps://github.com/prettier/prettier/issues/8136, as you can reproduce the issue by trying to commit an unstyled file that's referenced in the.prettierignore. Additionally use--cacheforeslintas a recommended performance improvement, which is already assumed as our current.gitignoreincludes the.eslintcache.prepareat the end. (Or could we move it to the top?).tsto supportedeslinttypes. I'd personally prefer keeping it there even if the project is JS-only, but for the sake of consistency I only added it for TS projects..scss,.sass, and.htmlto supportedstylelinttypes. Fixing CSS<style>tags inside HTML definitely sounds like an expected default behavior to me. This list may not be exhaustive, so please make sure it's kept up-to-date with any popular use-cases.lintStagedconditions to include it even withouteslint. Previously this meant that together with husky they weren't configured if the user has only chosencommitlint, which I believe is a bug. Now it installs even for prettier, but I also allowed it to be installed as an empty block if chosen alone, because the effects of that selection don't make any sense otherwise; who are we to judge if someone wants to lint something else on staging?