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
Recommend using imported type for .eslintrc.js #2153
Comments
Additionally those types aren't always 100% correct, as they're maintained by whomever wants or needs something, and nobody is providing proper oversight (they're only correct right now because I updated them because I needed them for something). OTOH, our types are guaranteed to be correct for the version of ESLint we support, and are well documented. Unfortunately it's not as simple as adding the comment, the docs would also have to describe in sufficient detail how to enable checking of that file as well, which is a bit beyond the simple installation steps we want in the root readme. The feedback we've gotten from many users is that there are already too many steps required to setup linting, so I think adding in more isn't what we want. ESLint also provides runtime validation of your configuration using their schemas, so it's not a requirement for setting up linting. In the community we have been thinking and talking about this for a while now; see #1296 and the links in the description. There are solutions that can be worked on, but nobody has enough time to work on it. OOC how did you file this issue? You filed one without an issue template or automatic tagging, but that shouldn't be possible as I've disabled the empty template. |
I've found it to work perfectly fine in VS Code without having Regarding it not being as simple as adding the comment, it was seamless with my editor (VS Code) and required no additional configuration. Also, I was viewing this as being a recommendation, not a requirement to use. It is just intended to help with editing and validating the configuration file. Whatever configuration you're talking about should be clearly indicated as being optional if they want that added functionality. I would imagine that since it's a comment, it would just be ignored if the tool didn't already support it. I'm glad that the community is already working on solutions, and if one of those solutions can accomplish a better editing experience then I would be fine with that instead too. Regarding how the issue was filed, I did so using https://github.com/typescript-eslint/typescript-eslint/issues/new/. Since this is regarding a README and is rather meta, I'm not sure which of those issue templates would apply. |
That's probably vscode doing automatic type acquisition.
I'd be interested in hearing more about what other solutions there could be, aside from #1296 & my rejected eslint/rfcs#50 proposal (which I hope might be open to being revisited if eslint/rfcs#9 ever lands, as part of that has the config loading broken out into another package so it'd no longer be in the core), as I've not not really been able to come up with a better one than doing:
I did recently publish The primary problem I ran into when thinking of solutions is that IDEs & tools tend to look explicitly for |
#1296 is really the only solution that will work everywhere, I believe. |
I do like it as a solution; is there anything outstanding that still needs to be done before it can be landed? |
it needs someone to champion it - to take it, finish it, test it and make sure it's all working as intended. |
I am willing to provide the PR, but first wanted to know if this was something you'd be willing to accept. The recommended file starter doesn't include the import type hint
/** @type {import('eslint').Linter.Config} */
at the top. I think type checking JavaScript files should be recommended, even if it's just a configuration file. It would be especially useful with editor tools -- the issue at microsoft/vscode-eslint#124 demonstrates a desire for this and it wasn't clear to them what the solution would be but turned out to be this simple.The text was updated successfully, but these errors were encountered: