prettier: Consider removing default parser / Skip processing unsupported file types

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?

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 9
Comments: 35 (29 by maintainers)

Most upvoted comments

I consider this behavior a bug, not a feature, and by that logic, I think we should make this change without waiting for 2.0.

suchipi on Apr 5, 2018

not sure there exists a list of all developers who are using Prettier as part of their tools

Let’s just ask the most popular ones.

vim-prettier: @mitermayer
vim neoformat and ale: unclear who to ask (https://github.com/sbdchd/neoformat/blob/d74189db83ba6b9d50e219586e7235b7efb1d1ee/autoload/neoformat/formatters/javascript.vim#L39-L45, https://github.com/w0rp/ale/blob/3331f6c8f4a1a8ffff90ec1a2faea36eff55fe7c/autoload/ale/fixers/prettier.vim)
prettier-emacs: @rcoedo
WebStorm: @prigara (made several setup docs PRs)
Visual Studio: @madskristensen

The question is: If prettier file/with/unknown.extension printed a warning to stderr instead of trying to format file/with/unknown.extension as JS, would that cause problems for editor integrations?

lydell on May 1, 2018

I think it’s really important that we figure out a non-breaking way that fixes 80% of the cases as soon as possible, because lots of users are confused when Prettier tries to format HTML files, which sometimes succeeds and sometimes doesn’t, depending on if the HTML is valid JSX or not.

Could this work out, maybe?

If Prettier is told to format a file with an extension it does not recognize and the parser option has not been set (either in the CLI or in a config file), print a warning for that file (Skipping file with unknown extension .html: /home/lydell/foo/src/index.html).

We have to be really careful so we don’t break editor integrations that rely on the CLI such as vim-prettier (ping @mitermayer) though.

I also think we can consider this a bug and not wait for 2.0.

lydell on May 1, 2018

Hi! I’m the developer who wrote most of the code for the WebStorm integration. It would not be a problem for WebStorm, we use getSupportInfo to determine if the file is acceptable. Thank you so much for giving the heads up! In the future, feel free to @ - mention me also.

undeadcat on May 2, 2018

It wouldn’t be a problem for prettier-emacs. The users could conditionally add specific --parser options for custom or unsupported extensions.

rcoedo on May 1, 2018

@robwise Do you specify the parser for unsaved draft documents also? You wouldn’t be able to pass a filepath for those even after #4341, so I’m wondering how you do it now. Do you use the editor scope? Maybe prettier needs to support editor scope for parser inference in addition to filepath?

suchipi on May 7, 2018

In the same vein, @mitermayer @rocedo @undeadcat @madskristensen we are thinking about changing the JavaScript API to require passing either parser or filepath, otherwise the text will be passed through as-is.

> prettier.format("function bla      () {}")
'function bla      () {}'
> prettier.format("function bla      () {}", { filepath: "foo.js" })
'function bla() {}\n'
> prettier.format("function bla      () {}", { parser: "babylon" })
'function bla() {}\n'

This will affect prettier.format, prettier.formatWithCursor, and prettier.check.

Would this adversely affect you? Are you always specifying either parser or filepath?

Context: https://github.com/prettier/prettier/pull/4426#discussion_r186271892

suchipi on May 6, 2018

I opened a PR that implements this change, I need some help implementing the error message that @lydell mentioned in https://github.com/prettier/prettier/issues/2884#issuecomment-385642962, but otherwise it is functional

suchipi on May 5, 2018

Hi @lydell,

This is not a problem for vim-prettier as we always include the --parser option. I am currently on the process of rewritting most of it for 1.0 release so changes like that should be ok since we will do a major release with other breaking changes.

cc @docwhat

mitermayer on May 2, 2018

@undeadcat thanks so much for building it, it’s been a highly requested from people using prettier!

vjeux on May 2, 2018

@lydell could this be implemented as built-in an HTML plugin, which simply does not do anything? I.e. it’ll parse the entire text into a syntax tree with a single node and simply print it back as is.

kachkaev on May 1, 2018