Parcel 2: .parcelrc should actually be called .parcelrc.json

💬 RFC

The new configuration file .parcelrc is a JSON file, and the file name should reflect it as such.

🔦 Context

Using a name without an extension is cute, but doesn’t have any real positive effects when you’re using a well established format. Adding the extension on the other hand gives you…

• Editor code completion
• Syntax highlighting
• Increased clarity!

💻 Examples

Many tools that use configuration files have moved away from file names without extensions. ESLint is probably the most well known. Yarn is making the transition in their upcoming v2 from the name .yarnrc to .yarnrc.yml to reflect its YAML syntax.

[devongovett]

.js config files are not going to happen in parcel. We’ve discussed them generally in various other issues. They may seem nice at first, but have many many downsides. Once you support .js, it’s a slippery slope to webpack.config.js. We want the configuration experience using Parcel to be as minimal as possible, if you need it at all.

There are also other technical reasons for not supporting them, such as the possibilities of indeterminism and non-cacheability they create. This happens with babel.config.js already, for which we have to disable much of Parcel’s caching support, leading to slower performance. We recently contributed support for babel.config.json to alleviate this.

[jamiekyle-eb]

The new configuration file .parcelrc is a JSON file

That’s actually not the case. Technically .parcelrc is JSON5 right now, although we are discussing using JSONC.

{
  // this is a valid .parcelrc
  "transforms": {
    // ...
  }
}

Using .json in the filename does not save us from having to tell every single syntax highlighter (editors, github, etc) that .parcel.json should be JSONC. See tsconfig.json in Linguist for example.

So for your list:

• Editor code completion (Nope, will break without explicit mapping)
• Syntax highlighting (Nope, will break without explicit mapping)
• Increased clarity! (Potentially)

I know I was confused when tsc --init generated a JSON file with comments. And my editor was very angry about it, giving me red syntax error squiggles over the entire file.

In that case it seems better to actually it rendered as plain text unless the editor has mapped the file extension ahead of time.

The alternative here is to use something like:

parcel.jsonc
parcel.json5

I have a feeling that people will complain about those names though, let’s just jump straight to “Y U NO USE TOML/YAML?”

Originally I wanted to use TOML, but I couldn’t come up with a configuration syntax that wasn’t annoyingly verbose because of the globs.

extends = [ "@parcel/config-default" ]

[[tranforms]]
match = "*.js"
plugins = ["@parcel/transform-babel"]

[[transforms]]
match = "*.css"
plugins = ["@parcel/transform-postcss"]

In the case of YAML, I felt like it was an overly complex format for what I wanted out of Parcel’s configuration. I expect/want most .parcelrc files to be very small. I wanted a really restricted format so that online examples are easy to understand and copy-and-paste. YAML allows you do so many things that can cause confusion and that make it hard to copy and paste.

The other notable alternative was to use a .js file, like many tools have been doing recently. But again, Parcel configs are meant to be small, very static (making it easier to cache), and very easy to share. Allowing them to be scripted cause a whole suite of downstream tooling problems.

Having helped introduce the original .babelrc file, and having watched the results of the Babel team adding almost a dozen other filenames. I know that it’s not an ideal name, but it is far better than the alternatives. Babel is just digging a hole for itself for no good reason.

Right now I still feel like .parcelrc is the best file name choice.

1. If you don’t recognize it, you’ll probably go googling for it, and hopefully our SEO will be good enough that you’ll be dropped on a page explaining it.
2. Editors/syntax highlighters/etc will have to add mappings to it pretty quickly and will never have to be updated ever again.

I could be convinced that a better name would be:

.parcelconfig
.parcel.jsonc (or .parcel.json5 if we continue using JSON5)
parcel.jsonc

I did bring up using .json with the team though, mine is not the only opinion.