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

[aslilac]

💬 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.

[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.

[aslilac]

I would definitely be okay with the json5 or jsonc extension, as long as it has an extension that represents the contents of the file. .config.js would also be really cool (and like you said, everyone is doing it) but I also understand the technical things that make it worse for the Parcel team at the expense of a slightly nicer experience for devs using Parcel.

[jamiekyle-eb]

at the expense of a slightly nicer experience for devs using Parcel.

I would argue that a .js file makes it a significantly worse experience for developers. Look at all the weird and unreliable configuration it takes to cache Webpack or Babel. Having been on the receiving end of lots of criticism, I don't think anyone has ever accused Babel or Webpack of having a good configuration experience.

[aslilac]

@jamiekyle-eb I was mostly referring to how people always seem to want to be able to execute code in their configs, not that that's an actual good thing or that Babel or Webpack are fun to use (because they aren't).

[Pytal]

Any chance support will be added for .js config file?

[DeMoorJasper]

@Pytal probably not, there's not really a reason to do so

[bbugh]

Given Parcel 2's goal to be usable in large scale production apps, I'd like to strongly advocate for allowing non-json formats for configuration as well.

Most other major JS projects (babel, eslint, prettier, etc.) have moved away from format-enforced configuration and allows teams to choose based on their needs because it's impossible to predict what shenanigans JavaScript's build pipeline will require even today, let alone after Parcel 2 launches!

Non-programmable files like JSON have not been a great format for configuration in my experience. If the only choice is JSON for configuration, then when we need to add some configuration option - like some special CI build need, or set up certain things in a test environment, etc. - we're stuck with crappy or no options. This has happened on every large project I've worked on.

Sure, it's nice if/when we can have a simple configuration file that's easily structured, but it's very limiting when scaling a project. There will inevitably be some weird pipeline, library requirement, or some new quirk of JavaScript compilation that wasn't considered.

As far as I can tell, Parcel 2 is focused on "zero config, unless you need to" and is interested in larger-scale projects. I'd really like it to succeed in that front because I'm so tired of webpack, but I think it would be a mistake to force json-only config for .parcelrc.

[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.

[ghost]

How I configure .parcelrc.json with the same options that in package.json. For example:

"build": "parcel build *.html --no-source-maps --detailed-report" is my typical configuration on package.json. How I do it in this .parcelrc.json ??

[mischnic]

.parcelrc only specifies which plugins you want to use. These CLI options didn't change

[toastal]

I'm going to bump this. While JSON5 does support comments so I can do things like

// vim: noai ts=2 sw=2
// vim: filetype=json5
{
  "...": 0
}

to get the desired behavior in Neovim, it means I need to include new rules to my .editorconfig and everything else whereas I want the formatting to be basically identical to what I'd expect to see in package.json, .postcssrc.json, et. al. other configuration files where this is supported. I can understand keeping the default, extension-less file to be a JSON5 mime-type, I don't think it's fair to require all editors to make special rules for this file nor help users that do want the file extension to be more specific.

---

I think the above argument is over-conflating the possibility of future syntax support as well. Just because some configuration languages (e.g. TOML) would be unintuitive, it doesn't mean all would; CSON or Dhall would play well with what exists here. Both of these options, unlike a different comment is asking for .js support, won't mess with caching because they are static or like Dhall enforces that the "configuration code" terminates and is side-effect-free despite having functions -- which is very much why Parcel highly encourages users to use static, cacheable configuration files over code execution.

[hyperupcall]

I stumbled upon this issue looking for this exact behavior. I think there is some additional benefits in supporting at least .parcelrc.json file:

• Automatic support for code formatters:
  • By ending with a .json file, formatters, like Prettier will automatically know how to handle it. Special rules (supported by some formatters) won't need to be provided and warnings about invalid file extensions won't be printed. In my view, this is enough to support a regular format like .json, like nearly every other tool out there
  • And even though the format is technically JSON5, I would argue that 99.9% of people are going to be using either JSON or JSONC - and all serious formatters support parsing comments in regular JSON files because it's so common (JSON5 users can always just use .parcelrc)
• Conformity with the rest of the ecosystem
  • Just conformity in the sense that tools have already moved away from non-common file extensions. I'm not asking for a huge like mess like Babel or for supporting JavaScript - I feel like also supporting just one common file extension, .json is a good middle ground

Some people brought up other file formats besides .json - Because I really would like to see this feature added, I think focusing only on the .json thing would make it easier to get consensus - and additional formats can be proposed later if needed

[uiolee]

Agreed, I think it's a good practice to specify the type of a file.