Bugzilla

We understand that coding styles can be subjective, and that this can be an invasive change.

The main purpose of using Prettier across mozilla-central is having more consistency and predictability, not just within teams but _within Mozilla_. We still have styling inconsistencies in our codebase and we have been unnecessarily spending human time when writing, reviewing, and discussing code. The prime directive is therefore to have consistent, predictability and enforceable styling.

Starting with July 5, Mozilla will not continue using eslint for enforcing styling. Rules strictly pertaining to code quality will be preserved, and this task will continue to be in eslint’s domain. Most styling-related rules will be removed in favour of separating this concern into Prettier’s domain. Some off the lines may be blurry here, however Prettier style has precedence and conflicting or redundant eslint rules will be removed.

I elaborate more on _why_ in the email sent to dev-platform and firefox-dev two weeks ago, and I hope that the presentation at the all-hands in Whistler shed additional light on this and how we picked both Prettier and the configuration rules. There's also a quick FAQ in https://docs.google.com/document/d/1UDERMflocqdszMGhhtxiVhaCTVOHo6jxLsGbt4BR9uw/

When the changes were changes were approved both by Firefox senior engineering leadership and the Firefox Technical Leadership Module, we’ve decided that compatibility with the existing styling is not an end-goal, and eslint strictness is not favoured over Prettier.

We understand that coding styles can be subjective, and that this can be an invasive change.

The main purpose of using Prettier across mozilla-central is having more consistency and predictability, not just within teams but _within Mozilla_. We still have styling inconsistencies in our codebase and we have been unnecessarily spending human time when writing, reviewing, and discussing code. The prime directive is therefore to have consistent, predictability and enforceable styling.

Starting with July 5, Mozilla will not continue using eslint for enforcing styling. Rules strictly pertaining to code quality will be preserved, and this task will continue to be in eslint’s domain. Most styling-related rules will be removed in favour of separating this concern into Prettier’s domain. Some of the lines may be blurry here, however Prettier style has precedence and conflicting or redundant eslint rules will be removed.

I elaborate more on _why_ in the email sent to dev-platform and firefox-dev two weeks ago, and I hope that the presentation at the all-hands in Whistler shed additional light on this and how we picked both Prettier and the configuration rules. There's also a quick FAQ in https://docs.google.com/document/d/1UDERMflocqdszMGhhtxiVhaCTVOHo6jxLsGbt4BR9uw/

When the changes were changes were approved both by Firefox senior engineering leadership and the Firefox Technical Leadership Module, we’ve decided that compatibility with the existing styling is not an end-goal, and eslint strictness is not favoured over Prettier.

We understand that coding styles can be subjective, and that this can be an invasive change.

The main purpose of using Prettier across mozilla-central is having more consistency and predictability, not just within teams but _within Mozilla_. We still have styling inconsistencies in our codebase and we have been unnecessarily spending human time when writing, reviewing, and discussing code. The prime directive is therefore to have consistent, predictability and enforceable styling.

Starting with July 5, Mozilla will not continue using eslint for enforcing styling. Rules strictly pertaining to code quality will be preserved, and this task will continue to be in eslint’s domain. Most styling-related rules will be removed in favour of separating this concern into Prettier’s domain. Some of the lines may be blurry here, however Prettier style has precedence and conflicting or redundant eslint rules will be removed.

I elaborate more on _why_ in the email sent to dev-platform and firefox-dev two weeks ago, and I hope that the presentation at the all-hands in Whistler shed additional light on this and how we picked both Prettier and the configuration rules. There's also a quick FAQ in https://docs.google.com/document/d/1UDERMflocqdszMGhhtxiVhaCTVOHo6jxLsGbt4BR9uw/

When the changes were approved both by Firefox senior engineering leadership and the Firefox Technical Leadership Module, we’ve decided that compatibility with the existing styling is not an end-goal, and eslint strictness is not favoured over Prettier.

We understand that coding styles can be subjective, and that this can be an invasive change.

The main purpose of using Prettier across mozilla-central is having more consistency and predictability, not just within teams but _within Mozilla_. We still have styling inconsistencies in our codebase and we have been unnecessarily spending human time when writing, reviewing, and discussing code. The prime directive is therefore to have consistent, predictable and enforceable styling.

Starting with July 5, Mozilla will not continue using eslint for enforcing styling. Rules strictly pertaining to code quality will be preserved, and this task will continue to be in eslint’s domain. Most styling-related rules will be removed in favour of separating this concern into Prettier’s domain. Some of the lines may be blurry here, however Prettier style has precedence and conflicting or redundant eslint rules will be removed.

I elaborate more on _why_ in the email sent to dev-platform and firefox-dev two weeks ago, and I hope that the presentation at the all-hands in Whistler shed additional light on this and how we picked both Prettier and the configuration rules. There's also a quick FAQ in https://docs.google.com/document/d/1UDERMflocqdszMGhhtxiVhaCTVOHo6jxLsGbt4BR9uw/

When the changes were approved both by Firefox senior engineering leadership and the Firefox Technical Leadership Module, we’ve decided that compatibility with the existing styling is not an end-goal, and eslint strictness is not favoured over Prettier.