Improve .babelrc filename per dotfile conventions and with filename extension

[jasonkarns]

Feature request:

Two concerns with the current .babelrc filename:

1. The leading dot violates the long-standing convention that dotfiles are intended to be hidden. They are intended to be hidden because they are user specific preferences. As such they would typically remain local to a machine, and not be committed to version control. Babel's configuration file is none of these. It should be versioned, should be shared with the team, should not be hidden, and is not a preferences file. As such, the babel configuration file should not have a leading dot.

2. The babelrc file contents are parsed as JSON5 but the filename does not use the corresponding extension. As such, babel users lose all the benefits provided by their IDE or editor: syntax highlighting, autocomplete, linting, formatting, etc. As a JSON5 file, it should have a .json5 extension so all the benefits of our IDEs are not lost for this file. (for prior art, eslint supports .eslintrc.json among others to automatically reap the benefits that a file extension provides authors)

Ideal filename, IMO: babel.json5

I originally considered opening these two concerns as separate issues since they could be resolved separately. However, my ideal outcome would be to name the file babel.json5 or babelrc.json5 which would address both concerns at once, without any transitional filename concerns.

And I fully appreciate that this would be a breaking change (or at the very least, require a transitional release that supports the current .babelrc filename as a fallback).

[jasonkarns]

I will add that if only one of the two mentioned "problems" with the filename is addressed, I would much rather see the file extension added. The dotfile thing is an annoyance and grates at me from a convention and aesthetic perspective; but it has much less practical impact day to day. (Though I have to admit: considering the number of ways in which the dotfile is not hidden: ie, on github, in git itself, in many IDE tree views, etc makes me wonder why on earth the dot was ever added in the first place.)

[jasonkarns]

(Sorry, didn't find #4892 till now. searches for babelrc file extension didn't include that PR)

[loganfsmyth]

The leading dot violates the long-standing convention that dotfiles are intended to be hidden. They are intended to be hidden because they are user specific preferences. As such they would typically remain local to a machine, and not be committed to version control.

I think there's a big assertion here that dotfiles have a standard. I personally have zero expectations that a dotfile is private to your machine. This pattern is also well established in the JS community. Just in Babel's repo, we've got .editorconfig, .eslintrc, flowconfig, .github, .gitignore, and .travis.yml. These are all things that are absolutely project-specific.

Dotfiles that are user-specific are user-specific because they live in the user's home folder, not because they are dotfiles.

Babel's configuration file is none of these. It should be versioned, should be shared with the team, should not be hidden, and is not a preferences file. As such, the babel configuration file should not have a leading dot.

I think you're assertion about the meaning of the dot prefix do not match real-world usage of that prefix.

The babelrc file contents are parsed as JSON5 but the filename does not use the corresponding extension.

I think that's a fair criticism. In Babel 7 we've added .babelrc.js support, so I'd expect that once your file is at the point where syntax highlighting would matter, most users will have transitioned to using that, which should address that concern. I think I'd be less likely to rename the existing files though since it'd be a breaking change that doesn't provide a ton of benefit that using the .js version wouldn't already achieve.

[jasonkarns]

I personally have zero expectations that a dotfile is private to your machine.

yeah, agreed, I phrased that really poorly (butchered). What I meant is that it is less germane to the project itself. If you removed all of the files that you listed, the way the app is built, interacted with, or run would not change at all. They are not fundamental to how the app works. Phrased better: leading-dotfiles can be removed from the app without impacting how it builds/runs.

.github is full of meta preferences (preferences that affect the repo itself, not the app within the repo). .editorconfig, .eslintrc, .flowconfig are all linting and stylistic preferences. Remove them and the app would build/run without change.

However, remove .babelrc and your resulting app is now fundamentally different.

Counter examples that adhere to this "app vs preference" distinction (that I butchered in the OP):

• package.json itself. defines entrypoints, how it's built, what even is the app
• webpack.config.*: fundamental to how the app is built. remove it and the app is broken
• makefile: remove it and you don't have a deployable app/lib
• gruntfile.js: same
• gulpfile.js: same
• lerna.json: fundamental to building a runnable app
• .npmrc: user configuration. it can be removed without affecting the app

An app's babel configuration is fundamental to how the app builds or is run. It's removal results in a fundamentally different app.

I'm glad that the new filename will include the .js extension. That was by far the more important of my two concerns.

[grogi]

There is a convention as old as Unix - dot files are hidden. And as such, they really are not intended to be edited by users.

Dot files and directories are use to keep cache, settings etc. They might be indeed used to keep users preferences, but in this case those would be updated from an UI or CLI, not by directly editing the file.

Nevertheless the update of the filename to .babelrc.js is very welcomed :)

[loganfsmyth]

We now support babel.config.js files that load from the working directory by default, so I'm closing this as fixed-enough :)

[jasonkarns]

👍