fix: properly scope rules to file types#86
Conversation
|
The approach looks good. |
Alright. Thanks for confirming. I'll tidy up this PR tomorrow. |
|
@joethei do we currently have any React/Svelte-specific rules? If not, do you want me to add stubs for those? Considering Obsidian's plugin tutorial has examples for both React and Svelte. |
|
we don't have any specific rules, stubs would be nice. |
|
@joethei apologies for the delay. Finally got around to addressing this. |
- Split rule configurations into base (JS/TS) and type-checked (TS-only) - Separate package.json checks from main configuration - Add stubs for react and svelte configs - Regenerated documentation
0b40674 to
b432677
Compare
| "obsidianmd/platform": "error", | ||
| "obsidianmd/prefer-get-language": "error", | ||
| "obsidianmd/prefer-abstract-input-suggest": "error", | ||
| "obsidianmd/prefer-active-window-timers": "error", |
There was a problem hiding this comment.
Does this exist? I think it should be prefer-window-timers.
| "obsidianmd/editor-drop-paste": "error", | ||
| "obsidianmd/hardcoded-config-path": "error", | ||
| "obsidianmd/no-forbidden-elements": "error", | ||
| "obsidianmd/no-global-this": "error", |
There was a problem hiding this comment.
no-global-this appears to have been dropped. Was that intentional?
| "obsidianmd/prefer-get-language": "error", | ||
| "obsidianmd/prefer-abstract-input-suggest": "error", | ||
| "obsidianmd/prefer-active-window-timers": "error", | ||
| "obsidianmd/prefer-active-doc": "off", |
There was a problem hiding this comment.
prefer-active-doc changed from warn to off. Is that intentional?
| "obsidianmd/prefer-file-manager-trash-file": "warn", | ||
| "obsidianmd/prefer-instanceof": "error", | ||
| // Rules that don't require TypeScript type information (can apply to JS and TS files) | ||
| const recommendedPluginRulesConfigBase: RulesConfig = { |
There was a problem hiding this comment.
Care must be taken when rebasing this branch on master to make sure that any new/changed rules on master are not reverted or lost.
| }, | ||
| ]); | ||
|
|
||
| const reactConfig: Config[] = defineConfig([ |
There was a problem hiding this comment.
Why are these being added if they don't do anything different? Maybe we should hold off on adding these until there are specific rules we need to add in them.
I'm also wondering if they are actually required at all. When there comes a time when we need to add a rule that is React or Svelte specific, is there a way we can write that rule to detect if the code base uses those frameworks and disable it if not?
|
|
||
| export default defineConfig([ | ||
| ...obsidianmd.configs.recommended, | ||
| ...obsidianmd.configs.packageJson, |
There was a problem hiding this comment.
This is going to silently remove these rules from users that already have this plugin configured.
Why is this change being made? It doesn't seem like this is a technical requirement for the typed rule split.
| // [2] - TypeScript-specific recommended rules | ||
| ...((() => { | ||
| const tsConfigs = tseslint.configs.recommendedTypeChecked as any[]; | ||
| const tsPlugin = tsConfigs[0].plugins['@typescript-eslint']; |
There was a problem hiding this comment.
This feels fragile. What if tseslint changes their config?
Summary
Splits the recommended config's rule sets so that rules requiring TypeScript type information only run on TypeScript files, while rules that don't need type info apply to both JS and TS files.
Problem
The recommended config applied all
obsidianmdrules uniformly. Rules that callgetParserServices(likeno-plugin-as-component,no-view-references-in-plugin,prefer-file-manager-trash-file,prefer-instanceof,no-unsupported-api) would crash or produce misleading errors when run on plain JavaScript files that aren't parsed by@typescript-eslint/parser.Changes
recommendedPluginRulesConfigintorecommendedPluginRulesConfigBase(JS + TS) andrecommendedPluginRulesConfigTypeChecked(TS only)package.jsonlinting into its ownpackageJsonconfigreactandsvelte