-
Notifications
You must be signed in to change notification settings - Fork 17
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
Spellchecker and "extends" #16
Comments
Hmm... What if the spellchecker searched for some known file in the project's root dir, just like eslint does itself with BTW this issue might be a special case of a wider problem, which is about using a combination of different dictionaries that either sit in different npm modules or in the project itself. |
+1: I ran into a similar issue with two eslint config files in the same project - I wanted the plugin config found in |
@kachkaev Did you ever find a solution or workaround to this? |
👋 @waynehaffenden, I haven’t been using this plugin for years. Just using CSpell in VSCode, nothing in CI/CD. |
I'm planning to to use the same eslint rules in a few projects and I would like to extract them into a separate node module (just like airbnb has done). The idea is to link to these "master" rules from each project and to have them synchronized:
cd dependent-project npm install eslint-config-my-super-rules
dependent-project/.eslintrc
:I would like the spellchecker to be configured inside
my-super-rules
:node_modules/eslint-config-my-super-rules/.eslintrc
:It seems reasonable to make all
skipWords
that are likely to be used in all the dependent projects a part ofmy-super-rules
.The problem starts when I decide to add a few more
skipWords
right in the project. Since"spellcheck/spell-checker"
is a single rule from.eslint
's point of view, the only thing I can do is to overwrite everything that was defined innode_modules/eslint-config-my-super-rules/.eslintrc
. This will mean that I will have to pollute my shared.eslint
with lots of rare special cases to have the plugin's config shared. The workflow for adding new project-specific words becomes complex as well: it is necessary to open another repo, modif it, change the version ofeslint-config-my-super-rules
, publish the package, go back to my project's repo and thennpm update
(this is a reasonable workflow for common words, because those change not so often and there is an additional gain in return: the result is shared).I can't see a clear solution to this issue at the moment but I imagine the problem raising again and again as the popularity of your useful plugin grows. What would you recommend?
The text was updated successfully, but these errors were encountered: