Codecov Report

Merging #4892 into 7.0 will increase coverage by 0.12%.
The diff coverage is 98.68%.

@@            Coverage Diff            @@
##              7.0   #4892      +/-   ##
=========================================
+ Coverage   85.27%   85.4%   +0.12%     
=========================================
  Files         203     203              
  Lines        9531    9532       +1     
  Branches     2690    2702      +12     
=========================================
+ Hits         8128    8141      +13     
+ Misses        915     904      -11     
+ Partials      488     487       -1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 39eca84...d054cd0. Read the comment docs.

Thinking about this more, I'm personally a bit hesitant to support dynamic config.

We've discussed in the past having a babel init command that can generate a config for you. I think it would be huge if you could use the same tooling to allow editing your existing configuration (adding new plugins, configuring preset options, etc). If we allow dynamic configuration, we won't be able to programmatically modify the config, and then serialize it back to disk.

@DrewML Do you think it would be harmful to simply not support JS configs with that new feature? I ask because I feel like those who prefer dynamic JS configs would most likely not be interested in a CLI tool that manages it for you anyway.

We already do have the env option which gives us a way to share a single config file among scripts that might require different setups, but it ends up being verbose and cumbersome if there are shared configs because order for plugins matters and it ends up forcing you to duplicate plugin entries. I know I'd personally prefer to have control over that.

Didn't know about the discussion about a babel init command. We have a similar command for ESLint (though it doesn't edit existing configs), but it's mainly geared towards a) giving those who are new to the tool/ecosystem a quick way to get started using the tool and b) give those who aren't interested in managing their own configuration a way to get started using a pre-existing preset. Having what is essentially a babel plugin manager sounds interesting.

@DrewML why not just call JSON.parse(JSON.stringify(require('./whatever/.babelrc.js')) early on in program lifecycle, if it fails, then tell the user what's wrong, they can fix it. It's not that hard for users to ensure that their config is serializable.

@DrewML why not just call JSON.parse(JSON.stringify(require('./whatever/.babelrc.js')) early on in program lifecycle, if it fails, then tell the user what's wrong, they can fix it. It's not that hard for users to ensure that their config is serializable.

@ORESoftware That doesn't solve the use-case I am referencing. That would verify that the value returned from evaluating the file is serializable. If someone has a JS configuration, we can't make modifications to the parsed value, and then blow away their JS and replace it with JSON.

@DrewML yeah but when would you overwrite the user provided config, and write it back to the filesystem? Probably never, right? Or are you? Their of course are projects that do this, but it doesn't get written back to the developer's source code. I do see it as a slightly risky move.

@ORESoftware:

We've discussed in the past having a babel init command that can generate a config for you. I think it would be huge if you could use the same tooling to allow editing your existing configuration (adding new plugins, configuring preset options, etc). If we allow dynamic configuration, we won't be able to programmatically modify the config, and then serialize it back to disk.

It is an idea relating to a bigger discussion we've had regarding how to make editing the .babelrc less error prone

@DrewML this one is easy. Have both .babelrc and .babelrc.js. The latter is optional, the former required. The latter requires/imports the former and can override things. Babel edits the former.

might be kind of annoying to implement though, and there might be some gotchas in there.

In general, I like dynamic config and using .js instead of .json, that's just my preference. I like Webpacks use of .js config and suman also will use .js config.

I don't think it's the greatest solution to require anyone that wants to write their config in JS maintain 2 separate files for configuration. I'm much prefer @kaicataldo's solution of just not having any tooling like that support custom .babelrc.js files.

@DrewML sure, I don't have anything at stake in this particular convo, just adding my 2 cents. I am more interested in the issue regarding dynamically specifying the exact path to .babelrc

Cool! No worries.

@DrewML Do you think it would be harmful to simply not support JS configs with that new feature? I ask because I feel like those who prefer dynamic JS configs would most likely not be interested in a CLI tool that manages it for you anyway.

@kaicataldo You do make a good point. It's also, in no way, set in stone that we'd be implementing CLI editing of existing config. Just an idea I had floated at one point.

@DrewML so you put an idea above something that would already work?

@ForsakenHarmony Nothing has been put above anything. This is a discussion.

Personally I would leave .babelrc as it is, and any CLI tool will edit that. If it's missing and a .babelrc.js exists, you don't do anything and warn the user. If there is not .babelrc(.js), creating .babelrc is fine. This would allow people to choose CLI or JS and prevent them from doing something weird.

If both files are present, it might be best to just warn the user, or it could be an optional feature that passes the contents of .babelrc into a function in .babelrc.js.

@hzoo @loganfsmyth @danez @Kovensky @existentialism Anyone else have any opinions on this?

Not sure if this should be posted in this PR or on the corresponding issues, so i'm just dropping it here.

At first, one might say most users will still use .babelrc vs .babelrc.js files to configure their compilation and that only advanced ones will benefit from it.

That said, it also allows for cleaner ways to configure the compilation, for example NODE_ENV based specific options. All can benefit from that.

Supporting the .js format will also allow for more creativity in the babel community (I have in mind it would allow the end-user to extend a plugin exporting a babel .js configuration via its main).

Regarding the loading, IMO the .js file should have the higher priority, and if it loaded, the resolution should stop. That way experienced user could also leverage the babel init CLI once it lands, and inherit the generated file in their dynamic configuration, e.g. (on mobile, sorry about typos if any):

const generated = JSON.parse(require('fs').readFileSync('./.babelrc'));

module.exports = Object.assign(generated, {
  // dynamic stuff
});

With that in mind I don't see how a tool enabling the user to generate JSON5 .babelrc files will create backward compatibility issues, while it benefits all the users.

Any other thoughts on what we want to do about this?

I don't have a strong opinion on this but I would prefer an API in Babel to allow to run it with a given configuration object. This would allow user to implement whatever configuration they want (#4980).

I aggree with @DrewML, users will have more flexebility but will also be a lot more error prone.

I think #4970 (Specifying a different file (different filename, same file type) for config other than .babelrc) could solve this and why not #5039 (Add support for DOTFILES_PATH environment variable).

To be clear, I think dynamic configuration should be done using Babel's API.

@hzoo Looks like you thumbed the original comment at the top, but what are your thoughts? I'm still pretty new to the project - so I might be missing something here - but supporting different file types in ESLint has been pretty unproblematic.

I think JS based config files are extremely useful and also quite common e.g. ESLint, Webpack, and PostCSS all support JS config files.

In my experience it is quite common to change the value of some config option based on an environment variable, or to want to share some common value between different config files e.g. between babel and webpack.

Would love to see this land.

Nice work on this one!! 🎉

Appreciate all the input on this one ❤️

Hooray! 🎉

Would you be so kind as to backport this to 6.x? Otherwise what is the ETA on 7.x stable release? This feature would help me preserve my sanity when dealing with a particular preset 😄

has this been released? I'm finding that the babel compiler doesnt notice my .babelrc.js at all

you'll need to use 7.0 (alpha), or wait

@hulkish I saw you mentioned in #4630 that this would be useful for isomorphic apps. I'm having the same issue using babel and babel-node in the same directory. Did you get this working with .babelrc.js, would you mind sharing your setup.

@MrLoh I ended up being forced to sidestep babelrc by directly configuring babel via babel-loader and using the babelrc: false option

Possible workaround (works for me):

{
  "presets": [
    "./.babelrc.js"
  ]
}

Just create the .babelrc.js file and export an object using module.exports.

Afterwards you can just remove .babelrc and babel 7 will work with .babelrc.js.

This is awesome! Any reason I shouldn't suggest to people that they do this?

Not really, I probably would of suggested it earlier really 😄 , pretty funny though

In some cases there may be problems with caching when changing the contents of .babelrc.js, e.g. I had some probs when working with Next.js. I don't really know how to turn caching off atm, so I have to manually remove the cache each time 😛

But that's only when changing the config, no other problems.