Skip to content

fix: extract package.json rules into separate config - #80

Open
mnaoumov wants to merge 1 commit into
obsidianmd:masterfrom
mnaoumov:package-json
Open

mnaoumov wants to merge 1 commit into
obsidianmd:masterfrom
mnaoumov:package-json

Conversation

@mnaoumov

@mnaoumov mnaoumov commented Nov 19, 2025 •

Copy link
Copy Markdown
Collaborator

recommended includes a files: ['package.json'] config object. Once any config object matches package.json, ESLint lints that file, and every config object in the user's config that has no files applies to it too. If you layer a type-checked config after recommended, for example tseslint.configs.strictTypeChecked, ESLint throws on package.json:

Error while loading rule '@typescript-eslint/await-thenable': You have used a rule which requires type information, but don't have parserOptions set to generate type information for this file.
Occurred while linting .../package.json

ESLint declined to add isolated configs (eslint/eslint#20354), so this PR moves the package.json rules into their own packageJson config. recommended no longer lints package.json. To keep depend/ban-dependencies, spread the new config last:

export default defineConfig([
  ...obsidianmd.configs.recommended,
  // ...your own config objects
  ...obsidianmd.configs.packageJson,
]);

packageJson turns the type-checked rules off for package.json, which is why it must come last.

Changes:

  • lib/index.ts: move the package.json config object from recommended into configs.packageJson
  • index.d.ts: add the packageJson config type
  • README and docs/configuration.md: document the new config and why it comes last
  • tests/recommendedConfig.test.ts: recommended alone does not lint package.json, a type-checked config without files no longer throws on it, and packageJson spread last reports banned dependencies

@mnaoumov

Copy link
Copy Markdown
Collaborator Author

I believe this is needed because of eslint/eslint#20352

@mnaoumov

Copy link
Copy Markdown
Collaborator Author

The bug was closed. Reopened as a change request: eslint/eslint#20354

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot review overview

🟡 Changes recommended

Type-aware configuration can fail for untyped or excluded JavaScript files, and root discovery can hang on Windows.

Review effort: Balanced
Findings: 2 High severity

Open (2)
What changed in this PR

Separates package.json linting from the recommended source-code configuration.

Changes:

  • Adds a dedicated packageJson config.
  • Updates recommended JS/TS patterns and type-aware parsing.
  • Documents isolated configuration usage.
File Description
README.md Documents scoped source and package configurations.
lib/​index.ts Separates package rules and updates parser configuration.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread lib/index.ts Outdated
Comment thread lib/index.ts Outdated

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot review overview

🟡 Changes recommended

The new preset’s ambient declaration describes a single config rather than the exported array.

Review effort: Balanced
Findings: None

Resolved since last review (2)

The recommended config carried a `files: ['package.json']` block. Once
any config object matches package.json, ESLint lints it, and every
config object without `files` in the user's config applies to it too.
A type-checked config layered after `recommended`, such as
`tseslint.configs.strictTypeChecked`, then throws "You have used a rule
which requires type information" on package.json. ESLint declined to
add isolated configs (eslint/eslint#20354), so the block moves to its
own `packageJson` config, which users spread last.
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.

2 participants