Currently when
- Prettier is invoked from the CLI, and
- The file being formatted doesn't match any of the extensions supported, and
- No
--parser option is passed, and
- No
parser is in a prettier config file,
then it will fall back to the babylon parser and treat the file as JavaScript. This made sense when prettier only supported JS (and then TypeScript), but now that it supports vastly different languages perhaps it is time to challenge that default.
In #2882, we discovered this can have negative repercussions when used with --write **/*, modifying files inside of a .git directory.
If we were to change the default from JavaScript to a no-op, these kind of issues would go away, and we'd also have less issues reported along the lines of "My CSS doesn't parse", when they're accidentally using the babylon parser.
It is already possible to associate other extensions with a parser in .prettierrc.
{
"overrides": [{
"files": "*.mjs",
"options": { "parser": "babylon" }
}]
}
Thoughts @lydell @vjeux?
Currently when
--parseroption is passed, andparseris in a prettier config file,then it will fall back to the babylon parser and treat the file as JavaScript. This made sense when prettier only supported JS (and then TypeScript), but now that it supports vastly different languages perhaps it is time to challenge that default.
In #2882, we discovered this can have negative repercussions when used with
--write **/*, modifying files inside of a.gitdirectory.If we were to change the default from JavaScript to a no-op, these kind of issues would go away, and we'd also have less issues reported along the lines of "My CSS doesn't parse", when they're accidentally using the babylon parser.
It is already possible to associate other extensions with a parser in
.prettierrc.{ "overrides": [{ "files": "*.mjs", "options": { "parser": "babylon" } }] }Thoughts @lydell @vjeux?