Vanilla Prettier Setup in Blueprints

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