Make input file extensions configurable via .babelrc/API (T6673)

[babel-bot]

Issue originally made by @aoberoi

Bug information

• Babel version: 6.2.0
• Node version: 4.2.2
• npm version: 2.14.7

Description

I'd like to be able to declare my "extensions" inside my .babelrc file so that anyone running babel-cli in the project directory will get the same "extensions" option I chose. As I understand, this would mean extending the general options for babel to use extensions, rather than baking that into the babel-cli module. I think this makes sense because the extensions in which the code is authored is more a concern at the project level than a concern that someone could have regarding where input comes from and where output goes to (such as the current babel-cli options).

[babel-bot]

Comment originally made by @loganfsmyth

Could you clarify what you mean? Extensions for what? Some solid examples would be useful.

[babel-bot]

Comment originally made by @aoberoi

Sure. The default value for extensions value is .js,.jsx,.es6,.es as noted in the Options section CLI usage instructions. In my project, I have an executable (exposed in my package.json) that has no extension. Right now, I run babel src -d build --extensions ".js," in order for that file to also be compiled (notice the comma, I'm essentially saying ".js" or ""). All of my other options are described in my .babelrc file (such as which plugins to use). I feel like the extensions information belongs there in the .babelrc rather than on the command line.

[rattrayalex]

Are you open to PR's for this?

[hzoo]

I think we'd like to move less options into babelrc in general? Do you have any particular use case that would require this?

[rattrayalex]

Interesting.

In this case, LightScript, which operates as a babel plugin, uses the .lsc file extension. The plugin doesn't process files without .lsc in the filename, so that normal JS can coexist next to LightScript files.

If extensions were an available option in the .babelrc, LightScript users could run babel, babel-node, etc, rather than specifying babel --extensions ".lsc",".js",etc every time.

An alternative would be to allow the plugin itself to specify extensions, but a quick glance at the code indicates that might be tricky in some cases. For example, babel-register, babel-cli, etc, would need to check with plugins at boot time, essentially.

[wcjohnson]

As someone using babel-cli with LightScript, I'm also interested in this. I think when someone hands a directory to babel-cli for compilation, what they mean is "compile everything you can in this directory" -- so if LightScript plugin is installed, the babel should compile all LightScript files. Thus the plugins should register their own extensions, imo.

[loganfsmyth]

There are a few issues I see with this. I think the biggest one is just that we don't control the callsites of most Babel usecases. A standard Webpack usecase is test: /\.js?x/, so your extensions config has no effect. Same for babel-register, the require hooks for a set of extensions are registered before Babel is ever called.

babel-cli is the one case where we do control both ends so we could make it pass everything to babel-core where it could check the extensions from the .babelrc, but it tries to be consistent with babel-register currently, which seems like a good default.

Maybe a better compromise would be to allow a --transform-all or --extensions with no argument that would make babel-cli skip the extension checking and pass everything to Babel? Then in your .babelrc you could do

{
  only: ['**/*.lsc', '**/*.js']
}

to limit it to only compiling the files you care about?

[rattrayalex]

Interesting.

It's currently much easier to use webpack than babel itself for this kind of use-case, because of what you mentioned. Most webpack users are used to being explicit about file extensions, so I'm not personally worried about duplicate code in the user's configs there.

The bigger problem occurs when config leaks out of config files. If a project can't build without special flags, that's unfortunate (assuming a config file is available).

babel-register and babel-cli both currently have options for extensions, which is nice. babel-core does not, which I think is fine, since it doesn't filter by filename anyway, afaik.

If babel-register doesn't read from .babelrc before booting, then I guess this would only apply to babel-cli. While it would be a much better user experience to only have to type babel myFolder or babel-node myScript.lsc, I can certainly understand your hesitancy to add an option to .babelrc that only applies to babel-cli.

All that being said, the proposed compromise doesn't seem like enough of a win to justify its addition (though I appreciate it!).

Chances are, in this case, I'll create a lightscript-specific cli that shims babel with the required flags.

[bradzacher]

Another use case is typescript.

When using a build flow like browserify -> tsify -> babelify to compile then transpile typescript to JS, the babel transform will get skipped unless you specifically configure babel to accept TS/TSX files.

The other option is to use a flow like browserify -> tsify -> rename extension -> babelify, or browserify -> tsify -> write files -> babel, both of which are less intuitive.

It'd be great if I were able to instead have this config in my .babelrc file as a global config option.

My personal opinion is that if you're able to configure it from the CLI, you should be able to add it to .babelrc, so that you can run the without CLI any arguments.

[loganfsmyth]

Closing in favor of #8652