-
Notifications
You must be signed in to change notification settings - Fork 29
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
Proposal: merge into eslint-plugin-jsonc
#85
Comments
What does "correct" mean in this context? |
A passer parses json content into estree compatible AST without preprocess hacking like eslint-plugin-json/src/index.js Line 115 in 6fc5651
See also https://github.com/ota-meshi/jsonc-eslint-parser/blob/master/docs/AST.md |
Cool, thanks for the explanation! In my opinion, this is not as much about correctness as it is about tradeoffs. The problem is that we don't want eslint to apply JavaScript rules to the JSON. This plugin does it by passing in an empty AST and jsonc plugin does it by passing in an AST where the nodes are named so that they don't conflict with the JS equivalents. What would help this discussion is if someone can provide the cost/benefit of these options. For example, I would love to know:
I see that the jsonc plugin gets a million monthly downloads so that does give me confidence that it is battle-tested. I just want to fully understand the trade-offs before moving further. |
See also https://github.com/JoshuaKGoldberg/eslint-plugin-package-json which already uses that parser for a long time. The approach used by current plugin conflicts with cc @ota-meshi My two cents, |
I know that I think the advantage of using AST is that someone can create another plugin that uses that AST. I think that if we remove the code in the processor, other plugins will not be able to know the original JSON contents. |
Thanks for the link to the RFC! It is particularly helpful since @ota-meshi If we wanted One possible idea would be for I personally don't mind giving up control of |
Sorry, I haven't thought about that strategy yet 😅
Does one plugin have dependencies on the other and share the code? If so, that strategy sounds good to me 😄 One thing I'm concerned about is that a JSON linter might be created in the ESLint core org 🤔 |
My two cents, we should keep only one brand
Ideally we should parse in loose mode, but report syntax errors in strict mode. On the merge strategy, if @azeemba agree to abandon/deprecate the current project, we can check is there any rule missing in current
That won't affect us because we're making json linting working on eslint |
Besides, I think we should move the final project to be a part of @eslint-community. |
Openbmc repo CI uses `eslint-plugin-json` package[1] for JSON linting, and it appears that its broken for eslint@latest versions that mandated the use of flat config. There is some on-going work on fixing the plugin to add flat configuration support[2], but its still a work in progress. This commits also removed `eslint-plugin-json` package and leverages `eslint-plugin-jsonc` package[3], which is better maintained & also uses the same AST as Javascript for linting.Since the plugin could provide AST & source code text back to the eslint engine, we can now use eslint directives such as `/*eslint-disable <checks>*/` in json files. Also it does seem like there are plans to merge[4] `eslint-plugin-json` into `eslint-plugin-jsonc`. Flat configuration model deprecates the use of `.eslintrc.json` and also `.eslintignore`. Instead eslint now relies on just one java script based configuration file `eslint.config.mjs` for everything. So we had to now add some logic into the configuration file to append the repo specific ignores to the global ignores, which forced us to bring yet another node js package `fs`. Since latest versions of eslint flags a warning if there is a presence of deprecated `.eslintignore` file in repositories,I renamed it from `.eslintignore` to `.eslintIgnore`. [1]: https://www.npmjs.com/package/eslint-plugin-json [2]: azeemba/eslint-plugin-json#82 [3]: https://www.npmjs.com/package/eslint-plugin-jsonc [4]: azeemba/eslint-plugin-json#85 Change-Id: I0fa8c928a7449e08d761022dde1f1da3ee48cf62 Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
Openbmc repo CI uses `eslint-plugin-json` package[1] for JSON linting, and it appears that its broken for eslint@latest versions that mandated the use of flat config. There is some on-going work on fixing the plugin to add flat configuration support[2], but its still a work in progress. This commits also removed `eslint-plugin-json` package and leverages `eslint-plugin-jsonc` package[3], which is better maintained & also uses the same AST as Javascript for linting.Since the plugin could provide AST & source code text back to the eslint engine, we can now use eslint directives such as `/*eslint-disable <checks>*/` in json files. Also it does seem like there are plans to merge[4] `eslint-plugin-json` into `eslint-plugin-jsonc`. Flat configuration model deprecates the use of `.eslintrc.json` and also `.eslintignore`. Instead eslint now relies on just one java script based configuration file `eslint.config.mjs` for everything. So we had to now add some logic into the configuration file to append the repo specific ignores to the global ignores, which forced us to bring yet another node js package `fs`. Since latest versions of eslint flags a warning if there is a presence of deprecated `.eslintignore` file in repositories,I renamed it from `.eslintignore` to `.eslintIgnore`. [1]: https://www.npmjs.com/package/eslint-plugin-json [2]: azeemba/eslint-plugin-json#82 [3]: https://www.npmjs.com/package/eslint-plugin-jsonc [4]: azeemba/eslint-plugin-json#85 Change-Id: I0fa8c928a7449e08d761022dde1f1da3ee48cf62 Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>
In case you are not aware, there is a https://github.com/ota-meshi/eslint-plugin-jsonc built with correct
jsonc-eslint-parser
, I think we should work together to benefit to the whole community.cc @ota-meshi
The text was updated successfully, but these errors were encountered: