ematipico
commented
11 months ago Divergence
Bogus or duplicate modifiers on class properties
Input
// Multiple accessibility modifiers
class Foo {
private public a = 1;
}
// Declare function with body
declare function foo ( ) { }
// Invalid use of abstract
class Bar {
abstract foo ;
}
// Duplicate Readonly
class Read {
readonly readonly x: number;
}Diff
// Multiple accessibility modifiers
class Foo {
- private a = 1;
+ private public a = 1;
}
// Declare function with body
-declare function foo() {};
+declare function foo ( ) { }
// Invalid use of abstract
class Bar {
- abstract foo;
+ abstract foo ;
}
// Duplicate Readonly
class Read {
- readonly x: number;
+ readonly readonly x: number;
}Related Prettier Tests
- typescript/conformance/classes/classDeclarations/classAbstractKeyword/classAbstractProperties.ts
- typescript/declare/declare_function_with_body.ts
- typescript/conformance/classes/constructorDeclarations/constructorParameters/readonlyReadonly.ts
- typescript/conformance/classes/classDeclarations/classAbstractKeyword/classAbstractInstantiations2.ts
- typescript/conformance/classes/classDeclarations/classAbstractKeyword/classAbstractMixedWithModifiers.ts
- typescript/custom/abstract/abstractProperties.ts
Reason
Prettier's Babel-based parsing for JS/TS is very loose and allows multiple errors to be ignored. Biome's parser intentionally has stricter rules than Prettier and correctly asserts that the statements in these tests are invalid. Duplicate modifiers for functions are not semantically valid, function declarations are not allowed to have bodies, non-abstract classes cannot have abstract properties, etc.
In Prettier, these errors aren't considered parse errors, and the AST is still built "correctly" with the appropriate nodes. When formatting, Prettier then just treats these nodes as normal and formats them accordingly.
In Biome, the parsing errors result in Bogus nodes, which may contain any number of valid nodes, invalid nodes, and/or raw tokens. When formatting, Biome treats bogus nodes as effectively plain text, printing them out verbatim into the resulting code without any formatting, since attempting to format could be incorrect and cause semantic changes.
For class properties, Prettier's current parsing strategy also uses boolean fields for modifiers, meaning only one of each kind of modifier can ever be present (accessibility modifiers are stored as a single string). When printing, Prettier just looks at the list of booleans and decides which modifiers to print out again. Biome instead keeps a list of modifiers, meaning duplicates are kept around and able to be analyzed (hence the parsing error messages about duplicate modifiers and ordering). When printing out the bogus nodes, this list is still kept intact, and printing out the unformatted text results in those modifiers continuing to exist.
There are ways that Biome can address this. One possibility is to try to interpret the Bogus nodes when formatting and construct valid nodes out of them. If a valid node can be built, then it would just format that node like normal, otherwise it prints the bogus text verbatim as it does currently. However, this is messy and introduces a form of parsing logic into the formatter that is really not meaningful.
Another option instead is to introduce some form of "syntactically-valid bogus node" into the parser, which accepts these kinds of errors that are purely semantic (duplicate modifiers, abstract properties in non-abstract classes). It would continue to build the nodes like normal (effectively matching the behavior in Prettier), but store them inside of a the new kind of bogus node, including the diagnostics along with it. When formatting, these special bogus nodes would just attempt to format the inner node, and then fallback if there's an error (the existing format_or_verbatim utility would do this already). This keeps the parsing and formatting logic separate from each other, but introduce more complexity to the parser, allowing invalid states to be considered semi-valid.
After a little bit of discussion in Discord, the decision for now is to not worry about this divergence unless it's needed to reach 95% compatibility with Prettier.
Conaclos
thorn0
fisker
ghost
GabenGar
faultyserver
_NOTE: This issue thread is for explaining intentional divergences from Prettier. It is not intended as a place to seek clarification about formatting rules or point out discrepancies with Prettier. For those, please open a new issue or discussion. Once a decision has been made, a new entry will be added to this thread explaining the rationale and purpose behind choosing to diverge from Prettier's rules._
This Issue will function as a hub for collecting divergence from Prettier. When you want to comment, please use the following template: