Skip to content

fix: properly scope rules to file types#86

Open
saberzero1 wants to merge 1 commit into
obsidianmd:masterfrom
saberzero1:properly-scope-rules
Open

fix: properly scope rules to file types#86
saberzero1 wants to merge 1 commit into
obsidianmd:masterfrom
saberzero1:properly-scope-rules

Conversation

@saberzero1

@saberzero1 saberzero1 commented Nov 26, 2025

Copy link
Copy Markdown
Collaborator

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 obsidianmd rules uniformly. Rules that call getParserServices (like no-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

  • Split recommendedPluginRulesConfig into recommendedPluginRulesConfigBase (JS + TS) and recommendedPluginRulesConfigTypeChecked (TS only)
  • Separated package.json linting into its own packageJson config
  • Added stub configs for react and svelte
  • Regenerated documentation

@saberzero1 saberzero1 closed this Nov 26, 2025
@saberzero1 saberzero1 reopened this Nov 26, 2025
@github-actions github-actions Bot locked and limited conversation to collaborators Nov 26, 2025
@saberzero1 saberzero1 closed this Nov 26, 2025
@saberzero1 saberzero1 reopened this Nov 26, 2025
@joethei

joethei commented Dec 4, 2025

Copy link
Copy Markdown
Contributor

The approach looks good.

@obsidianmd obsidianmd unlocked this conversation Dec 4, 2025
@saberzero1

saberzero1 commented Dec 4, 2025

Copy link
Copy Markdown
Collaborator Author

The approach looks good.

Alright. Thanks for confirming. I'll tidy up this PR tomorrow.

@saberzero1

Copy link
Copy Markdown
Collaborator Author

@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.

@joethei

joethei commented Jan 2, 2026

Copy link
Copy Markdown
Contributor

we don't have any specific rules, stubs would be nice.

@saberzero1 saberzero1 marked this pull request as ready for review May 9, 2026 15:00
@saberzero1

Copy link
Copy Markdown
Collaborator Author

@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
@saberzero1 saberzero1 force-pushed the properly-scope-rules branch from 0b40674 to b432677 Compare June 2, 2026 18:49
Comment thread lib/index.ts
"obsidianmd/platform": "error",
"obsidianmd/prefer-get-language": "error",
"obsidianmd/prefer-abstract-input-suggest": "error",
"obsidianmd/prefer-active-window-timers": "error",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this exist? I think it should be prefer-window-timers.

Comment thread lib/index.ts
"obsidianmd/editor-drop-paste": "error",
"obsidianmd/hardcoded-config-path": "error",
"obsidianmd/no-forbidden-elements": "error",
"obsidianmd/no-global-this": "error",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no-global-this appears to have been dropped. Was that intentional?

Comment thread lib/index.ts
"obsidianmd/prefer-get-language": "error",
"obsidianmd/prefer-abstract-input-suggest": "error",
"obsidianmd/prefer-active-window-timers": "error",
"obsidianmd/prefer-active-doc": "off",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prefer-active-doc changed from warn to off. Is that intentional?

Comment thread lib/index.ts
"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 = {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread lib/index.ts
},
]);

const reactConfig: Config[] = defineConfig([

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment thread README.md

export default defineConfig([
...obsidianmd.configs.recommended,
...obsidianmd.configs.packageJson,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this related to #80?

Comment thread lib/index.ts
// [2] - TypeScript-specific recommended rules
...((() => {
const tsConfigs = tseslint.configs.recommendedTypeChecked as any[];
const tsPlugin = tsConfigs[0].plugins['@typescript-eslint'];

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels fragile. What if tseslint changes their config?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants