From 6dab6711cfc2356cb509e4fe35b3b3aee65ce84b Mon Sep 17 00:00:00 2001 From: Bert De Block Date: Tue, 3 Dec 2024 16:12:03 +0100 Subject: [PATCH 1/3] Vanilla Prettier Setup in Blueprints --- ...55-vanilla-prettier-setup-in-blueprints.md | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 text/1055-vanilla-prettier-setup-in-blueprints.md diff --git a/text/1055-vanilla-prettier-setup-in-blueprints.md b/text/1055-vanilla-prettier-setup-in-blueprints.md new file mode 100644 index 0000000000..67a5b60a85 --- /dev/null +++ b/text/1055-vanilla-prettier-setup-in-blueprints.md @@ -0,0 +1,93 @@ +--- +stage: accepted +start-date: 2024-12-03T00:00:00.000Z +release-date: +release-versions: +teams: + - cli +prs: + accepted: https://github.com/emberjs/rfcs/pull/1055 +project-link: +suite: +--- + +# Vanilla Prettier Setup in Blueprints + +## Summary + +This RFC proposes to migrate to a vanilla Prettier setup in the blueprints, instead of running Prettier via ESLint and Stylelint. + +This RFC also proposes to not include any custom values for specific Prettier options, and instead truly rely on Prettier's defaults for formatting. + +## Motivation + +1. Because we run Prettier via ESLint and Stylelint, we only run the files these linters support through Prettier - Using a vanilla Prettier setup, would format all files Prettier supports, ensuring even more consistency in projects +2. Less dependencies in the blueprints - `eslint-plugin-prettier` and `stylelint-prettier` would not be needed anymore +3. The Prettier team recommends running Prettier directly, and not via linters: + - Running Prettier directly is faster than running Prettier via ESLint and Stylelint + - ESLint and Stylelint show red squiggly lines in editors (when using the corresponding extensions), while the idea behind Prettier is to make developers forget about formatting +4. Not including any custom values for specific Prettier options makes the blueprints less biased, and introduces more consistency - I.e. double quotes for _all_ files, instead of single quotes for `.cjs`, `.cts`, `.gjs`, `.gts`, `.js`, `.mjs`, `.mts` and `.ts` files, and double quotes for the rest - To me, this makes more sense, especially for new projects + +`3.` is mostly taken from [Integrating with Linters > Notes](https://prettier.io/docs/en/integrating-with-linters.html#notes) + +## Detailed Design + +We would add the following scripts to the `package.json` file in the `app` blueprint: + +```diff ++ "lint:format": "prettier . --cache --check", ++ "lint:format:fix": "prettier . --cache --write", +``` + +- `lint:format` would check the formatting of _all_ files Prettier supports +- `lint:format` would also run when running the `lint` script +- `lint:format:fix` would format _all_ files Prettier supports +- `lint:format:fix` would also run when running the `lint:fix` script + +We would remove the following dependencies from the `package.json` file in the `app` blueprint: + +```diff +- "eslint-plugin-prettier": "*", +- "stylelint-prettier": "*", +``` + +As these would not be needed anymore. + +> NOTE: We will keep `eslint-config-prettier` installed, as we need this package to turn off the stylistic ESLint rules that might conflict with Prettier. + +We would update the `.prettierignore` file in the `app` blueprint: + +```diff ++ /pnpm-lock.yaml +``` + +To make sure Prettier does not format pnpm's lockfile. + +We would update the `.prettierrc.js` file in the `app` blueprint: + +```js +module.exports = { + plugins: ['prettier-plugin-ember-template-tag'], +}; +``` + +To only include the `prettier-plugin-ember-template-tag` plugin, and configure nothing else. + +We would also need to make sure that every file generated by the `app` blueprint, conforms to Prettier's default config. + +## How We Teach This + +N/A + +## Drawbacks + +- Some developers or teams prefer running Prettier via ESLint and Stylelint +- Most Ember projects probably use single quotes for JS related files, because of the current Prettier config file in the blueprints - These projects would need to ignore the Prettier config changes when updating, or migrate to using double quotes instead + +## Alternatives + +I anticipate using the default Prettier config for _all_ files being a hurdle for a lot of developers or teams, and therefore, I'm also fine with omiting that part from this RFC. + +## Unresolved Questions + +N/A \ No newline at end of file From 7a9081721f75c0318f79ce50d20dcccb2ff8051e Mon Sep 17 00:00:00 2001 From: Bert De Block Date: Mon, 9 Dec 2024 14:40:20 +0100 Subject: [PATCH 2/3] Drop using the default Prettier config from the RFC --- ...55-vanilla-prettier-setup-in-blueprints.md | 22 ++++--------------- 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/text/1055-vanilla-prettier-setup-in-blueprints.md b/text/1055-vanilla-prettier-setup-in-blueprints.md index 67a5b60a85..3b0fd2d5a4 100644 --- a/text/1055-vanilla-prettier-setup-in-blueprints.md +++ b/text/1055-vanilla-prettier-setup-in-blueprints.md @@ -17,16 +17,13 @@ suite: This RFC proposes to migrate to a vanilla Prettier setup in the blueprints, instead of running Prettier via ESLint and Stylelint. -This RFC also proposes to not include any custom values for specific Prettier options, and instead truly rely on Prettier's defaults for formatting. - ## Motivation 1. Because we run Prettier via ESLint and Stylelint, we only run the files these linters support through Prettier - Using a vanilla Prettier setup, would format all files Prettier supports, ensuring even more consistency in projects 2. Less dependencies in the blueprints - `eslint-plugin-prettier` and `stylelint-prettier` would not be needed anymore 3. The Prettier team recommends running Prettier directly, and not via linters: - - Running Prettier directly is faster than running Prettier via ESLint and Stylelint - - ESLint and Stylelint show red squiggly lines in editors (when using the corresponding extensions), while the idea behind Prettier is to make developers forget about formatting -4. Not including any custom values for specific Prettier options makes the blueprints less biased, and introduces more consistency - I.e. double quotes for _all_ files, instead of single quotes for `.cjs`, `.cts`, `.gjs`, `.gts`, `.js`, `.mjs`, `.mts` and `.ts` files, and double quotes for the rest - To me, this makes more sense, especially for new projects + - Running Prettier directly is faster than running Prettier via ESLint and Stylelint + - ESLint and Stylelint show red squiggly lines in editors (when using the corresponding extensions), while the idea behind Prettier is to make developers forget about formatting `3.` is mostly taken from [Integrating with Linters > Notes](https://prettier.io/docs/en/integrating-with-linters.html#notes) @@ -63,17 +60,7 @@ We would update the `.prettierignore` file in the `app` blueprint: To make sure Prettier does not format pnpm's lockfile. -We would update the `.prettierrc.js` file in the `app` blueprint: - -```js -module.exports = { - plugins: ['prettier-plugin-ember-template-tag'], -}; -``` - -To only include the `prettier-plugin-ember-template-tag` plugin, and configure nothing else. - -We would also need to make sure that every file generated by the `app` blueprint, conforms to Prettier's default config. +We would also need to make sure that every file generated by the `app` blueprint is formatted correctly. ## How We Teach This @@ -82,11 +69,10 @@ N/A ## Drawbacks - Some developers or teams prefer running Prettier via ESLint and Stylelint -- Most Ember projects probably use single quotes for JS related files, because of the current Prettier config file in the blueprints - These projects would need to ignore the Prettier config changes when updating, or migrate to using double quotes instead ## Alternatives -I anticipate using the default Prettier config for _all_ files being a hurdle for a lot of developers or teams, and therefore, I'm also fine with omiting that part from this RFC. +N/A ## Unresolved Questions From a73d12a2ecc2791ced8fb2922f8ccc2c84af27f4 Mon Sep 17 00:00:00 2001 From: Bert De Block Date: Thu, 12 Dec 2024 09:53:16 +0100 Subject: [PATCH 3/3] Update script names --- text/1055-vanilla-prettier-setup-in-blueprints.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/text/1055-vanilla-prettier-setup-in-blueprints.md b/text/1055-vanilla-prettier-setup-in-blueprints.md index 3b0fd2d5a4..278bcd4efc 100644 --- a/text/1055-vanilla-prettier-setup-in-blueprints.md +++ b/text/1055-vanilla-prettier-setup-in-blueprints.md @@ -32,14 +32,16 @@ This RFC proposes to migrate to a vanilla Prettier setup in the blueprints, inst We would add the following scripts to the `package.json` file in the `app` blueprint: ```diff ++ "format": "prettier . --cache --write", + "lint:format": "prettier . --cache --check", -+ "lint:format:fix": "prettier . --cache --write", ``` - `lint:format` would check the formatting of _all_ files Prettier supports - `lint:format` would also run when running the `lint` script -- `lint:format:fix` would format _all_ files Prettier supports -- `lint:format:fix` would also run when running the `lint:fix` script +- `format` would format _all_ files Prettier supports +- `format` would also run when running the `lint:fix` script + +> NOTE: We use `format` instead of `lint:format:fix`, because we don't want to run Prettier parallel to ESLint and Stylelint when fixing lint errors. The `lint:fix` script will be updated to always run `format` last. We would remove the following dependencies from the `package.json` file in the `app` blueprint: