editorconfig-core-js
editorconfig-core-js copied to clipboard
editorconfig
Add editorConfig properties to package.json?
In the spirit of ESLint and Babel, would it make sense to allow editorConfig settings in package.json? I feel like it probably doesn't, but I wanted to have it documented either way to be definitive.
i.e.
"editorConfig" : {
}
Could also add presets: https://github.com/editorconfig/editorconfig-core-js/issues/31
That's rather JavaScript specific, which isn't really in the design goals of EditorConfig.
@jedmao No. It's not.
Look at how YAML does it. https://docs.cloudfoundry.org/devguide/deploy-apps/manifest.html#multi-manifests
Ah, see, I didn't realize this was on the core-js repo. Seeing as it is, I have no problems with such a feature; though, we still need to look in subfolders for both .editorconfig and package.json files, which means the package.json file needs to define "root": true if that's the case. Then, what happens if you have both an .editorconfig as well as a package.json file in the same folder, both with an EditorConfig configuration? Which one takes precedent? I can see some issues to address here.
Tools like eslint have this exact scenario. It's just a priority order. http://eslint.org/docs/user-guide/configuring#configuration-file-formats
http://eslint.org/docs/user-guide/configuring#extending-configuration-files
Would prefer to see someone make some standard config file (or folder) for all configs to live in rather than continuing to clutter package.json with xyz.
...that said, if it does get in, I'll probably use it.
Likewise, I will use this. @jedmao, what can we do to help? Do we need to look into the plugin and make a PR for the functionality? Could someone help with documentation? I’d love to see this get in on the next release.
First, we need to come up with an acceptable spec. At first glance, I'm imagining something like the following:
{
"editorConfig": {
"root": true,
"settings": [
{
"*": {
"indent_style": "space",
"indent_size": 4
}
},
{
"package.json": {
"indent_size": 2
}
}
]
}
}
It doesn't look as clean as the INI file format that .editorconfig uses, but this is the only way I could imagine supporting it in a package.json file.
BTW – you should theoretically be able to have any number of package.json files throughout your project. I would imagine that if both package.json and .editorconfig files were in a directory that the .editorconfig file would take precedence, but I'm open to discussion.
I took a look at the multilevel-ini and other INI parsing packages, but none of them account for ordered settings. I think the example structure I provided above is the only structure that would support this.
Another alternative would be the following structure:
{
"editorConfig": [
["root", true],
["*", {
"indent_style": "space",
"indent_size": 4
}]
]
}
@jedmao, thanks for the fast reply!
I’m a fan of the first syntax you’ve shared, and I would expect, as you’ve said, that the .editorconfig file takes precedent when both it and a package.json are present. Would this support an extends property being added alongside root and the other rules?
@jonathantneal anything above existing functionality would be a separate ticket. Please open another issue for that feature request and detail how it might work.
BTW – I'm not at all suggesting I have any bandwidth to implement this package.json feature. I still have zero interest in the feature for my own use, so I won't be using it.
I would, however, consider merging in a PR, if it were implemented properly. That is, of course, the purpose of this discussion, to talk about what a proper implementation would be.
@jonathantneal See https://github.com/editorconfig/editorconfig/issues/245
Hey there. What can I do to help with moving this forward? Do we still need help defining the request more clearly? We have a year of sharable configs under our belt for most if-not-all linters. Does the configuration just need an outlined JSON version? Is this something we should be writing plugins for Atom / Sublime first for?
Example package.json with inline rules:
{
"root": true,
"rules": {
"*": {
"indent_style": "tab",
"indent_size": "tab",
"tab_width": "4",
"end_of_line": "lf",
"charset": "utf-8",
"trim_trailing_whitespace": true,
"insert_final_newline": true,
"max_line_length": "off"
}
}
}
Example package.json extending a local editor-config-jonathantneal package:
{
"root": true,
"extends": "jonathantneal"
}
I would love to contribute somehow on getting this thing moving! There's really no other way to re-use .editorconfig's across multiple repos.
Nope. No other way. And remember, this is just for the js core. Other cores would need some kind of implementation too. I think we should stay focused on the OP's request and just support configuration in a package.json file for now and then start worrying about how the "extends" feature would work.
@jedmao Every core has its own options parsing code duplicated? That is, .editorconfig is pretty much hardcoded in each of them, right?
Yes, it has to be duplicated because the cores are written in different languages. The only thing that's not duplicated are the tests, which are shared across cores.
I just did a pretty hefty rewrite of the source code into TypeScript. Anyone interested in taking this feature further? Been a bit of silence.
I'd love to hop in to help a bit but I'm not really able to get the local dev setup working. The local bin/editorconfig definitely doesn't get created after doing npm install; npm link. Is that something easily fixable?
Other than that, the implementation for supporting editorConfig entry in package.json seems quite doable to me.
@andreiglingeanu I think the issue you are experiencing is related to https://github.com/editorconfig/editorconfig-core-js/issues/55. Perhaps we should do it the other way and remove the ./bin folder from package.json and restore the ./bin/editorconfig.
Hey @jedmao, yes, that it is. The bin/editorconfig file did not get generated at all in my local setup.
@andreiglingeanu, aha! See #60. Now that the package.json file expects to be published in the ./dist folder, that's where the npm link command needs to be run. Make sense? Or npm link ./dist from the project root. Either way.
Maybe I'm late to the party, but would this adhere to the cosmiconfig configuration file spec?
One of the main reasons to avoid a mandatory "root": true would be that it
Stops at the first configuration found, instead of finding all that can be found up the directory tree and merging them automatically.
Secondly, it would make it easier to adapt the other (defacto) standard to support different types of configuration files.
Thirdly, priority of configuration files can also be configured (and therefore predictable).
Would Editorconfig be open for other configuration file formats? Or would it be easier to open a separate issue to discuss that?
@BtM909 I was looking at package-json myself, but it looks like cosmiconfig has a bit more popularity. Not sure the delta between them.
As for other configuration file formats. What did you have in mind?
Sorry, completely missed your update... My apologies!
As for other configuration file formats. What did you have in mind?
What formats are you specifically referring to? I was just references the fact that cosmiconfig supports multiple file formats by default, like:
- a package.json property
- a JSON or YAML, extensionless "rc file"
- an "rc file" with the extensions .json, .yaml, .yml, or .js.
- a .config.js CommonJS module
@andreiglingeanu - did you ever make the pull request for this? Thanks for your help.
