-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for .babelrc.yaml #4980
Comments
I would like something like this. Would it be possible to support placing everything under a |
This option already exists https://babeljs.io/docs/usage/babelrc/#use-via-package-json |
Someone commented:
The reason I am mentioning this is because most people who are advocating JavaScript file as a configuration format do so because:
– https://www.reddit.com/r/javascript/comments/5hdpkh/would_you_like_babel_to_support_yaml/dazhau6/ |
If this is optional, then I don't care. I wouldn't use it, but that's me. However, forcing this requirement would be Babel 6 all over again. |
This proposal is for addition of YAML syntax in addition to the existing configuration format. Nevertheless, you/ me do need to care because we will eventually inherit projects that use one variation of the configuration format. I do think that most projects will stick with JSON format, because it is native to JavaScript platform. However, YAML syntax enables more complex projects to use YAML when needed. |
As an option, I'm all for this and #4892. I'm not a fan of yaml even if I agree with the logic employed by the issuer for the inclusion of yaml. |
I'd rather not have the mental overhead of having multiple formats different projects. If YAML is supported, then half the teams I work with will end up using it and then the burden is on me (or anyone else who jumps between projects) to comprehend both formats equally well for I'd like to stick to one standard, and JSON5 is a good one. |
To me it all comes down to simple reasoning:
|
Valid considerations. As a simple workaround, I written a small script that I have added to the build step that converts the YAML file in the earlier example to JSON file. It could be released as a separate tool. |
To me this feels like dependency creep because it's cool to support multiple file formats these days (though the code reuse aspects are definitely useful and difficult to argue against). There's a lot of problems I have with babelrc files - the inability to specify a preset and override the options of one plugin inside of said preset is one - but the file format has both never been an issue for me, and is standard across all projects. Allowing JSON+JS+YAML (assuming both of these issues were resolved) is more code for anyone jumping into contributing to Babel to wrap their heads around, and fragments the community a bit (see also, Gruntfiles written in, for example, CoffeeScript - anyone wanting to edit that project's build process now has to learn CoffeeScript, despite having used plain ol' JS on every Gruntfile they've come across before). My opinion likely means a bit less as a user rather than contributor to Babel, but I eye all efforts like this with a bit of skepticism, and arguably, conservatism, in the name of KISS. |
I was actually referring to the YAML file. |
My concern is that YAML is less portable, you'll need a module to read it and if you want to share the configuration with other tools it'll be trickier than a simple |
https://www.npmjs.com/package/jsonscript is another option. |
I'd rather we go with a js file instead of supporting YAML so closing in favor of #4892 We can have a distinction between dynamic configs = JS and static configs = JSON |
This is an alternative proposal to #4892 ("Add support for .babelrc.js files").
I am worried that adding configuration support in JavaScript format will lead to complex configurations that are hard to read. A case in point is webpack. webpack configurations have a tendency to grow in size out of proportion, include an exceeding amount of conditional checks and merging logic.
With no disrespect to the author of the following code example, consider this configuration:
In the above configuration:
__TEST__
variable__DEV__
variable__PROD__
variableIn short, there is no way see whats the resulting configuration without executing the code.
However, I do see an issue of repetition in
.babelrc
.Lets use this configuration as an example:
This is a long configuration that shares a lot in common. I cannot use
plugins
in the general scope because plugin order is important.First, lets start by rewriting the above configuration using YAML:
Thats already a reduction from 68 lines of code to 48 (30% reduction). However, we can do better.
YAML format supports merge key. Using merge and anchoring, we can rewrite the above configuration as:
Thats a reduction from 68 lines of code to 38 (45% reduction).
The most import thing here is not reduction of lines though, but reduction of repeated content thats shared across multiple configurations.
One of the most common mistakes that I make when configuring multiple environments, is forgetting to add some configuration to one of the configs that needs to be shared across a group of configurations. Using YAML solves this issue.
In contrast to allowing JavaScript configuration files, YAML configuration files introduce a set level of complexity.
The text was updated successfully, but these errors were encountered: