babel / babel-eslint

:tokyo_tower: A wrapper for Babel's parser used for ESLint (renamed to @babel/eslint-parser)
https://github.com/babel/babel/tree/main/eslint/babel-eslint-parser
MIT License
2.96k stars 208 forks source link

Allow pass options directly in babelOptions rather than a config file #768

Closed otakustay closed 4 years ago

otakustay commented 5 years ago

Is it possible to allow babel options in eslint config like:

module.exports = {
    parser: "babel-eslint",
    parserOptions: {
        babelOptions: {
            presets: [
                '@babel/env',
                '@babel/typescript',
            ],
        },
    },
};

In this case we can simply wrap configurations in a common module other than placing a standalone babel config file.

This results in a "No Babel config file detected" error currently.

axten commented 5 years ago

we strongly need that before version 11.0, we don't have a babelrc file in our projects. Its all configured within webpack babel loader config

axten commented 5 years ago

any other thoughts here?

kaicataldo commented 5 years ago

Rather than duplicating this configuration, would it be possible to create a separate module for the Babel config that is then imported into the Webpack config and is pointed to in the ESLint config?

The motivation behind the change is to have Babel’s parser have the same configuration during the parsing step for both Babel and ESLint.

axten commented 5 years ago

That is exactly what I try to achieve, I now have 3 tools that need a babel config, webpack, jest and eslint. The problem is, that babel in webpack is configured slightly different than in jest. So I already have a custom js file that exports all different kinds of babel config we need in our projects. But to get this approach to work with babel-eslint, I need this feature :) ATM we're unable to use private class methods proposal because of babel-eslint.

kaicataldo commented 5 years ago

Do you mind explaining why giving the path to the config file doesn't work? It seems like what is being proposed here is the opposite of what you described - i.e. having to duplicate your config in the .eslintrc file.

axten commented 5 years ago

Thats the key, I don't have a duplicate config ;) I' have a shared custom config file

// babel-configs.js (simple pseudo example)
const common = {}
const webpackModernBrowsers = {}
const webpackLegacyBrowsers = {}
const jest = {}

module.exports = {
    jest: { ...common, ...jest },
   webpackModern: { ...common, ...webpackModernBrowsers },
   webpackLegacy: { ...common, ...webpackLegacyBrowsers },
}

And I think it's not a problem to add this direct option passing feature and have a config path option beside that. babel-eslint should support both ways like the other tools do.

nicolo-ribaudo commented 5 years ago

I'm curious: why don't you use a normal babel.config.js with an env block to override, for example, jest-specific plugins?

axten commented 5 years ago

Because we use grunt and pass runtime specific options from grunt to the config (debug flag, browserlist)

// babel-configs.js (next simple pseudo example)
const common = {}
const webpack = {}
const jest = {}

module.exports = {
    jest: { ...common, ...jest },
   webpack: (options)  => { ...common,  ...webpack, ...options },
}
otakustay commented 5 years ago

We are encapsulating babel, jest, webpack, rollup, eslint and tslint in a universal cli tool for internal use, we don't allow engineers to modify babel config themselves in order to archive high consistent architecture through apps, so we don't really want to expose a babel config file which can be modified.

jharris4 commented 5 years ago

For anyone who's interested, I made a PR that does exactly what is requested by this issue: #784

kaicataldo commented 4 years ago

Thank you for the issue. Now that @babel/eslint-parser has been released, we are making this repository read-only. If this is a change you would still like to advocate for, please reopen this in the babel/babel monorepo.