-
Notifications
You must be signed in to change notification settings - Fork 48
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 editorConfig properties to package.json? #30
Comments
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. |
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 |
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 BTW – you should theoretically be able to have any number of I took a look at the |
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 |
@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 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. |
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 {
"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 {
"root": true,
"extends": "jonathantneal"
} |
+1 |
I would love to contribute somehow on getting this thing moving! There's really no other way to re-use |
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, |
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. |
Seems reasonable enough, thanks. |
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 Other than that, the implementation for supporting |
@andreiglingeanu I think the issue you are experiencing is related to #55. Perhaps we should do it the other way and remove the |
Hey @jedmao, yes, that it is. The |
@andreiglingeanu, aha! See #60. Now that the |
We are good to go! Expect the pull request soon. |
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
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 As for other configuration file formats. What did you have in mind? |
Sorry, completely missed your update... My apologies!
What formats are you specifically referring to? I was just references the fact that cosmiconfig supports multiple file formats by default, like:
|
@andreiglingeanu - did you ever make the pull request for this? Thanks for your help. |
Is there any movement on this feature? |
Editorconfig and prettierignore are not supported. Further reading: prettier/prettier#3460 editorconfig/editorconfig-core-js#30
Editorconfig, tsconfig and prettierignore are not supported. Further reading: prettier/prettier#3460 editorconfig/editorconfig-core-js#30 microsoft/TypeScript#32830
bump |
Up! I hate small files cluttering my workspace. It could really be in the package.json. |
Its not hard to implement this feature, but the main problem is that this repo is long dead, it uses really old versions and heck even Even if the code itself would be easy to implement, I'd be stuck with version bumping, security issues and manual version testing to make sure it all works. Not even talking about the fact that the last pull requests were just version bumps and that activity dates to 2019. If you like the package you could fork it and create your own version. But i hightly suggest you use something like
for end of line you could just use your editors features or just edit it directly with git |
OK, we're back up and running. I'm looking through open issues before doing a release. Does anyone still want this? |
Yes please! |
OK, if this moves forward here is the proposed approach. For each {
"global": { "root": true, "otherProperty": 12 },
"rules": {
"*": { "indent_style": "tab" }
}
} This gets turned into a If both Note that many tools in the ecosystem will not be using the JS core, so any rules defined in Now is the time to bikeshed all of these details. |
Likewise, I will use this. |
We also have no rule order. I am not sure if this is important but I have this scenario in mind: {
"*": {"optionA": true},
"subfolder/*": {"optionA": false}
} |
Given that order needs to matter, ParseStringResult is probably the correct type. Its typescript definition is: export type SectionName = string | null
export interface SectionBody { [key: string]: string }
export type ParseStringResult = [SectionName, SectionBody][] |
Is there any way shareable configs could be added to this? (like: |
Shareable configs are a separate feature request that needs to change the specification. |
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: #31
The text was updated successfully, but these errors were encountered: