Community dashboard reports mass unsafe-type false positives when dependencies are unresolved

[JeffSteinbok]

Summary

The Obsidian community plugin dashboard reports hundreds of @typescript-eslint/no-unsafe-* warnings for a plugin whose source passes eslint-plugin-obsidianmd locally and in GitHub Actions. The warning pattern indicates that the dashboard scanner is running type-checked rules without successfully resolving the plugin dependencies in node_modules.

If the dashboard scanner is maintained elsewhere, please redirect this issue to the appropriate repository.

Affected plugin

• Plugin: JeffSteinbok/obsidian-onedrive
• Tracking issue: Community dashboard validator false positives: scanner doesn't resolve node_modules types JeffSteinbok/obsidian-onedrive#149
• Clean CI run: https://github.com/JeffSteinbok/obsidian-onedrive/actions/runs/30728979130

Observed behavior

The dashboard reports mass warnings including:

• @typescript-eslint/no-unsafe-assignment
• @typescript-eslint/no-unsafe-call
• @typescript-eslint/no-unsafe-member-access
• @typescript-eslint/no-unsafe-argument
• @typescript-eslint/no-unsafe-return

Many messages specifically say the value has an error type or a type that could not be resolved. Most affected code is downstream of imports from obsidian and @microsoft/microsoft-graph-client.

Reproduction evidence

1. Install the repository dependencies.
2. Run eslint-plugin-obsidianmd v0.4.1 with its recommended type-checked configuration against src/: no unsafe-type errors are reported.
3. Remove or make node_modules/obsidian unavailable and rerun the same validation. The imported Obsidian APIs become TypeScript error types and approximately 1,594 unsafe-type diagnostics appear.
4. Making @microsoft/microsoft-graph-client unavailable similarly produces another 25 diagnostics.

This matches the dashboard report pattern.

Expected behavior

Before running type-aware TypeScript ESLint rules, the community scanner should install the submitted repository lockfile dependencies and confirm that the TypeScript program can resolve imports. If dependency installation or module resolution fails, it should report that setup failure directly rather than emitting downstream unsafe-type diagnostics as source warnings.

Related report

https://forum.obsidian.md/t/bug-plugin-scorecard-linter-cannot-resolve-internal-deps-in-monorepos/116176

[sandsaber]

Confirming this with a second plugin and an exact local reproducer.

Plugin: Grimoire (sandsaber/Grimoire), pre-release. We see the same mass @typescript-eslint/no-unsafe-* warnings on the community dashboard, while eslint-plugin-obsidianmd v0.4.1 recommended type-checked runs clean locally and in CI.

Scale: 12,886 warnings across 192 files — no-unsafe-call (5,524), no-unsafe-member-access (4,578), no-unsafe-assignment (2,008), plus the rest. Every single one cascades from imports the dashboard scanner cannot resolve.

Root cause reproduced locally: running the same recommendedTypeChecked rules with node_modules/obsidian and node_modules/@types/node removed yields the identical warning pattern (matching the dashboard counts within ~7%). Restoring both packages → 0 warnings. Our own review:source gate (same rules via --rule) is green precisely because it runs with a complete node_modules.

Two unresolved surfaces, not one: beyond obsidian (as @JeffSteinbok found), Node built-ins are also unresolved on the scanner. process.platform, fs.readFileSync, path.join, http/https, crypto all surface as no-unsafe-* because @types/node is absent too. This is consistent with #168 and the unresolved-dependency note in #178. A desktop-only plugin that legitimately uses Node APIs gets penalized for the scanner's missing type environment.

Note on timing: this started appearing in dashboard reports after the "Community scanners ruleset" change (#173, released in v0.4.1, ~July 2) aligned the recommended config with recommendedTypeChecked.

What would help: like @JeffSteinbok suggests, either the scanner installs the repo's lockfile dependencies before type-checked linting, or it reports a setup/resolution failure rather than emitting thousands of downstream no-unsafe-* diagnostics. At minimum, flagging unresolved imports as a distinct category (rather than error-typed any) would make the scorecard actionable instead of noisy.

Happy to share the full per-rule/per-file breakdown or the reproducer script if useful.

[vcarus]

Third confirmation, plus a consequence I think raises the priority of this issue.

Confirmation. Explorer Order Editor (vcarus/obsidian-explorer-order-editor), listed, Health Excellent / Review Caution, 560 findings — 559 of them these six rules: no-unsafe-call (217), no-unsafe-member-access (181), no-unsafe-assignment (76), no-unsafe-argument (52), no-redundant-type-constituents (25), no-unsafe-return (8). npm run lint in the repo is 0 errors / 0 warnings with v0.4.1 recommended. mv node_modules/obsidian aside and rerun: 559, same distribution. Move it back: zero. Same picture as @JeffSteinbok and @sandsaber — nothing new, just a third data point, and note the ratio: the artifact is 99.8% of my scorecard.

The consequence: the badge is suppressible, and a listed plugin already suppresses it.

While comparing plugins in my niche I found one listed on 2026-08-07 that scores Review: Passed with 2 findings (both "missing GitHub artifact attestations"). Its code is not cleaner. Every one of its source files opens with a file-wide directive naming exactly the six rules above, no more and no fewer, with the justification "Obsidian's public API contains intentionally untyped internals; the plugin narrows them at its boundaries."

Two things establish that this only ever acts on the scanner:

• That repository has no ESLint configuration and no ESLint dependency at all — no eslint.config.*, no .eslintrc.*, no eslint in devDependencies, no lint script. Nothing in its own workflow reads those directives.
• Linting its source with v0.4.1 recommended myself: with dependencies installed, 10 findings, 7 of which are "unused eslint-disable directive" — i.e. in a resolvable checkout the directives are provably dead code. With obsidian hidden the way the scanner hides it: still only 4.

I am deliberately not naming the plugin and not attributing intent — the comment may well have come from a code assistant, and its stated justification is reasonable on its face. Nobody needs to be accused for the structural problem to be real: a file-wide eslint-disable of the six reported rules turns Caution into Passed, and it is verifiable from the outside in an afternoon.

This is also not the only route. The forum thread linked in the original report (116176) already documents another one: naming type declaration files *.test.d.ts so the scanner skips them, with the aside that this works to exclude any file from linting. That was offered in good faith as a workaround for exactly the resolution failure this issue is about — which is rather the point. When the only way to get a usable scorecard is to hide files from the scanner, suppression stops being a fringe behaviour, and the lint dimension of the badge becomes advisory in practice.

Why this makes the false positive worth fixing rather than tolerating. As long as unresolved types generate thousands of findings, the rational response for a plugin author is to suppress the six rules — and the authors who don't are exactly the ones running type-aware linting seriously. My repo runs eslint-plugin-obsidianmd with projectService on every commit and is clean; that is precisely why the scanner has 559 things to say about it. A repo with no linter configured has nothing to report. Right now the badge ranks a project below an otherwise identical project that runs no linter at all, and the cheapest way for me to improve my score is to add six lines my own tooling would immediately flag as useless. I'd rather that incentive not exist, so I haven't done it.

Beyond the fixes already proposed here (install lockfile deps, or fail the setup loudly), one cheap option specific to this ecosystem: obsidian's package is a single .d.ts with no install scripts and no runtime, so fetching just that file — or vendoring a copy per minAppVersion — removes the whole class without executing any third-party code. And whatever the fix, it would help if a file-wide disable of the rules being reported were treated as a signal rather than a pass.

Happy to share the reproducer, the full per-rule breakdown, or the repo name from the second section privately.

[saberzero1]

@JeffSteinbok your plugin seems to pass the latest release scan.

@sandsaber npm ci --ignore-scripts fails immediately on your plugin, likely because of these:

  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2",
    // ...
  }

@vcarus your lockfile doesn't have the binaries for @esbuild/openharmony-x64, only @esbuild/openharmony-arm64. The scanner runs on x64, which is why your dependencies don't resolve. Please run npm install --include=dev and check whether the package is added to your lockfile.

[vcarus]

@saberzero1 Thank you — you were right that it was my lockfile, and the latest scan is clean.

Not that package, though: esbuild publishes no @esbuild/openharmony-x64, only arm64. What was there: 27 extraneous @esbuild/* platform packages at 0.28.1, marked neither optional nor dev, which npm 9/10 treat as required → EBADPLATFORM; and behind them an esbuild pin at 0.25.5, outside the ^0.27.0 || ^0.28.0 optional peer that vite declares — npm 11 skips an absent optional peer, npm 9/10 demand a nested copy the lockfile lacks. Moving the pin into vite's range leaves one copy tree-wide, and npm ci --ignore-scripts now exits 0 on npm 7 through 11. My CI missed all of it by running npm 11, the only npm that tolerates both.

Worth saying, since it cuts against my earlier comment here: the scanner wasn't wrong in my case, my lockfile really was broken. What the report cost me was direction — hundreds of type findings pointing at my source instead of at the install.

[saberzero1]

@saberzero1 Thank you — you were right that it was my lockfile, and the latest scan is clean.

Not that package, though: esbuild publishes no @esbuild/openharmony-x64, only arm64. What was there: 27 extraneous @esbuild/* platform packages at 0.28.1, marked neither optional nor dev, which npm 9/10 treat as required → EBADPLATFORM; and behind them an esbuild pin at 0.25.5, outside the ^0.27.0 || ^0.28.0 optional peer that vite declares — npm 11 skips an absent optional peer, npm 9/10 demand a nested copy the lockfile lacks. Moving the pin into vite's range leaves one copy tree-wide, and npm ci --ignore-scripts now exits 0 on npm 7 through 11. My CI missed all of it by running npm 11, the only npm that tolerates both.

Worth saying, since it cuts against my earlier comment here: the scanner wasn't wrong in my case, my lockfile really was broken. What the report cost me was direction — hundreds of type findings pointing at my source instead of at the install.

npm/node/yarn/pnpm etc. version mismatching is something we're aware of and working on in the community scanners end.

[sandsaber]

@saberzero1 Thanks, npm ci --ignore-scripts was indeed failing, but the TypeScript aliases weren’t the cause.

The repo had engine-strict=true in .npmrc, while package.json requires npm >=12.0.2 <13. With npm 10.9.2 this makes the install fail immediately with EBADENGINE. Removing engine-strict lets the same command install all 726 packages.

I restored the original dependency setup from main, including both TypeScript aliases and obsidian / @types/node in devDependencies, then ran the community scan again. It passed and all 12,886 no-unsafe-* findings disappeared.

The final fix is f13a6c1: remove engine-strict and add a regression test.

So the install failure was on our side. The misleading part was reporting it as thousands of source warnings instead of the underlying EBADENGINE. Good to hear npm/Node version mismatches are already being worked on in the scanner.

[zinverno]

Confirming this with Vault Audit AI, with an end-to-end hosted Preview result.

Repository: https://github.com/zinverno/vault-audit-AI

We had the same mass @typescript-eslint/no-unsafe-* pattern in the Community Preview while local type-aware lint was clean.

The important part in our case turned out to be a real dependency-install compatibility problem.

On the affected revision:

• npm 11.11.0: npm ci and npm ci --ignore-scripts succeeded.
• npm 10.9.2: both commands failed with EUSAGE.
• local lint with a complete install: 0 errors / 4 intentional advisories.
• making the Obsidian declarations unavailable reproduced the unsafe-type cascade.

The npm 10 failure came from the lockfile around the Vitest 4.1.10 -> Vite 8.1.5 dependency chain. Vite has an optional esbuild peer requiring ^0.27.0 || ^0.28.0, while the project also has root esbuild 0.19.11.

During npm ci, npm 10 expected esbuild 0.28.2 and its optional platform packages to be present in the lockfile and rejected the lock when they were absent. npm 11 accepted the same lock.

I repaired the lockfile using npm 10.9.2 without changing package.json or any dependency versions, and added CI coverage for both npm 10.9.2 and npm 11.11.0 scanner-style installs.

After the repair:

• npm 10.9.2 npm ci: PASS
• npm 10.9.2 npm ci --ignore-scripts: PASS
• npm 11.11.0 npm ci: PASS
• npm 11.11.0 npm ci --ignore-scripts: PASS
• TypeScript resolves obsidian correctly under both installs
• all no-unsafe-* / redundant-error-type counts are 0 locally
• production main.js is byte-identical to the pre-fix build

Most importantly, I then submitted the repaired branch to a new Community Preview.

The mass unsafe-type findings disappeared completely.

The Preview now reports only four normal/actionable findings:

• one intentional streaming fetch
• two configuration-directory checks
• one settings-search advisory

So in our case the unsafe-type scorecard explosion was caused by the dependency installation failure, not by the source code.

This also reinforces one UX problem mentioned in this issue: when dependency installation fails, reporting thousands of downstream no-unsafe-* findings makes the root cause very difficult to identify. Surfacing the install/module-resolution failure directly would have made this immediately actionable.

The compatibility fix is:
zinverno/veynrel#23

Thanks for documenting this issue — it was what led us to test the scanner-style install separately.