Use standard .*rc files

[EnoahNetzach]

After ejecting it is not immediately clear how to add, for example, new scripts that use babel-cli.

The configuration I'm used to is in a .babelrc file which is loaded automatically by babel, right now I'm not sure how to replicate this standard behaviour with babel.dev.js.

[EnoahNetzach]

The same goes for .eslintrc

[denkristoffer]

I agree, that seems like expectable behaviour to me as well.

[gaearon]

It's not trivial to implement in a way that won't break in the future. Do you have implementation suggestions for this?

[gaearon]

(If we do this we also can't guarantee that ejecting is safe. For example if there is a broken babelrc in a parent folder, it would not be taken into account after eject, but with your suggestion, it could start throwing).

[jamesblight]

I ran into an issue trying to use the source-preview atom package https://atom.io/packages/source-preview. It expects to find a .babelrc file and won't be able to generate the source if plugins/presets are required. This may be a problem for other packages that expect a .babelrc.

Setting the babel extends config option in package.json to extend the internal react-scripts config would work if there was a .babelrc.

It would be even better if the babel extends option accepted a JavaScript file like eslintConfig extends does. Then, your package.json could simply include:
"babel": { "extends": "./node_modules/react-scripts/config/babel.dev.js" }

And you could add your own config on top of that.

[gaearon]

If you can figure out a way to make this project use .babelrc internally and then eject it, please send a PR. This is not currently a high priority for us but we’ll be happy to review that effort.

[jamesblight]

I'm not across the issues caused by using .babelrc internally, but I can have a look.

[hillscottc]

The MobX docs tell me I must "use the transform plugin transform-decorators-legacy and make sure it is first in the plugins list", in order for the decorators to work. How can I do that when there is no .babelrc? Is there some workaround?

[gaearon]

@hillscottc

You can’t use decorators with this setup currently.
I explained why here: #411 (comment).

However you don’t need decorators for MobX. I wish its docs put more emphasis on this.
See here how to use it without decorators: #214.

cc @mweststrate, this confusion came up 5 times, maybe worth making it more apparent that they’re not necessary?

[mweststrate]

@gaearon yep, had on my todo list where to investigate where the confusion comes from, to make it more clear that is optional.

@hillscottc where would you have expected that for example? The readme currently starts with an example how to do things both with and without decorators. Was that clear?

For people stumbling into this in the future, here is a small create-react-app based repo with MobX, without decorators:

https://github.com/mobxjs/create-react-app-mobx

Edit see also: http://mobxjs.github.io/mobx/best/decorators.html

[gaearon]

Thanks for taking the time to do that!

[jamesblight]

@gaearon is the main issue with using .babelrc internally the potential conflict with an existing .babelrc on eject?

[gaearon]

The main issue is that nobody did this :-). If you submit a PR we can start looking at individual problems.

[gaearon]

(I'm not talking about supporting decorators or merging configs which is unrelated to this thread. I meant outputting RC files on eject.)

[EnoahNetzach]

I have an almost working hacked together script that does it, in a couple of days I should be able to open a decent PR.

It tries to merge the (optionally) existing .babelrc with a version extracted from the .js configs.
Not sure what to do when it fails (e.g. for config clashes):

• fail with a list of clashing configs
• output a .babelrc.fail file
• overwrite clashes
• ask interactively what to do

Ideas?

[gaearon]

I think we won't support any attempts to merge configs. It is just impossible to do safely because of how Babel is implemented (some plugins can only be used together in a specific order).

[gaearon]

This is implemented in #705 and will be released in 0.5.0.

[gaearon]

0.5.0 is out with this.
Please read the release notes for migration instructions.

[tuchk4]

Suggested implementation for custom babel configuration #1357