-
-
Notifications
You must be signed in to change notification settings - Fork 209
Discussion: how do we handle missing Babel config files in v11 #738
Comments
FWIW despite my previous comment, I'm not against this as a default, as long as there is an opt-out. We could do:
|
I'm starting to wonder if making exceptions for this case would be a mistake. Saying that babel-eslint will only run on code that Babel is set up to transform makes things a lot easier from a maintenance standpoint. typescript-eslint-parser has always worked this way and it hasn't really been an issue. |
This was discussed in today's Babel meeting. Notes can be found here. The solution we landed on is as follows:
|
I got the error @loganfsmyth proposed above in |
From #711 (comment)
Original question:
Sounds like there might issues with any approach that doesn't just parse using defaults, as described here by @loganfsmyth :
I guess we have to decide if
babel-eslint
is quite literally only for code that is transformed by Babel or if it can also be used for non-transformed code in a project that mostly consists of files that are transformed by Babel. Concrete example I can think of off the top of my head is a tooling config file (.eslintrc.js
,babel.config.js
, etc.) that might not have a config.From a philosophical standpoint, I actually don't think it's unreasonable to say that those files should be parsed with the default parser (which will always be available since it's a dependency of ESLint and is totally possible with ESLint's glob-based configuration). Practically speaking, though, I'm not sure it's a good idea. It increases the overhead for every new project that uses babel-eslint and has any non-transformed JS code.
The text was updated successfully, but these errors were encountered: