Skip to content
This repository has been archived by the owner on Aug 18, 2021. It is now read-only.

Discussion: how do we handle missing Babel config files in v11 #738

Closed
kaicataldo opened this issue Jan 10, 2019 · 4 comments · Fixed by #743
Closed

Discussion: how do we handle missing Babel config files in v11 #738

kaicataldo opened this issue Jan 10, 2019 · 4 comments · Fixed by #743

Comments

@kaicataldo
Copy link
Member

kaicataldo commented Jan 10, 2019

From #711 (comment)

Original question:

It looks like babelCore#parseSync will still parse without a config file, it just won't enable any plugins. Does this seem like a reasonable default? I'm worried about it being confusing behavior since Babel itself won't run any transformations without a config file. An alternative would be to run a check to see if a config file can be found (not sure if @babel-core provides an API for this already or not) and throw an error with a helpful message, if not.

Sounds like there might issues with any approach that doesn't just parse using defaults, as described here by @loganfsmyth :

The issue is that not all files in your project may have a config. If you have a .babelrc in src/ but didn't bother with any Babel config for the rest of your project, you should still be able to lint those files using the parser's defaults.

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.

@loganfsmyth
Copy link
Member

FWIW despite my previous comment, I'm not against this as a default, as long as there is an opt-out.

We could do:

const cfg = babel.loadPartialConfig(/* ... */);
if (!opts.allowNoConfig && cfg && !cfg.hasFilesystemConfig()) {
  throw new Error(`No Babel config file detected for ${cfg.options.filename}. Either disable config file checking with allowNoConfig:false, or configure Babel so that it can find the config files.`)
}
const ast = cfg && babel.parse(cfg.options);

@kaicataldo
Copy link
Member Author

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.

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.

@kaicataldo
Copy link
Member Author

kaicataldo commented Jan 14, 2019

This was discussed in today's Babel meeting. Notes can be found here.

The solution we landed on is as follows:

Each time babel-eslint parses a file and no corresponding config file is found, an error will be thrown with an optional opt-out. (this should be an edge case)

@danpoq
Copy link

danpoq commented Apr 8, 2019

I got the error @loganfsmyth proposed above in 11.0.0-beta.0 and had to solve it by passing the location of babel.config.js in parserOptions.babelOptions.configFile because I'm working in a monorepo. This is specifically documented on the README (👍) but just posting this here in case anybody else comes to this issue in the same situation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants