Conversation
Instead of only looking for manifest.json in the current working directory, walk up the directory tree until a valid Obsidian plugin manifest is found (identified by having an `id` field). This fixes noisy console.error output in monorepo setups where ESLint runs from a workspace root or sub-package that doesn't contain manifest.json directly. The plugin now silently returns null when no manifest is found, which preserves the existing fallback behavior (Node.js imports are disallowed, no Node globals added). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
|
I don't like how this walks up the directory tree indefinitely, there should be a limit. |
|
@joethei what would be reasonable limit? if we consider monorepo package structure I would say 2 or 3 would suffice? Or should it be configurable? |
| cachedManifest = null; | ||
| return cachedManifest; | ||
| } | ||
| cachedManifest = findManifest(process.cwd()); |
There was a problem hiding this comment.
| cachedManifest = findManifest(process.cwd()); | |
| return findManifest(process.cwd()); |
| return parsed as PluginManifest; | ||
| } | ||
| } catch { | ||
| // File doesn't exist or isn't valid JSON — keep walking. |
There was a problem hiding this comment.
I think this is ignoring too many errors. We should distinguish between when the file doesn't exist and when a manifest file is invalid JSON. Let's maintain the existing behavior when the JSON manifest file we find is invalid.
| } | ||
|
|
||
| const parent = path.dirname(dir); | ||
| if (parent === dir) { |
There was a problem hiding this comment.
We should likely not traverse outside of a Git repo either. Check if the directory is a git root and if so stop traversing.
| // Obsidian plugin manifests always have an `id` field — | ||
| // skip unrelated manifest.json files (e.g. Chrome extensions). | ||
| if (parsed && typeof parsed === "object" && typeof parsed.id === "string") { | ||
| return parsed as PluginManifest; |
There was a problem hiding this comment.
I wonder if we should warn if we find a valid manifest.json that does not include a valid ID. Otherwise that becomes unexpectedly invisible.
3 participants
Summary
manifest.jsoninprocess.cwd(), walk up the directory tree until a valid Obsidian plugin manifest is found (identified by having anidfield)nullwhen no manifest is found, removing theconsole.errorthat fires in monorepo setupsisDesktopOnlyrules default to the safer option (Node.js imports disallowed, no Node globals)Motivation
In monorepo setups (e.g., pnpm workspaces with Turborepo), ESLint often runs from the workspace root or a sub-package directory — neither of which contains
manifest.json. The current code logs a noisyconsole.error("Failed to load JSON file:", err)every time, even though this is expected and harmless.The walk-up approach mirrors how tools like ESLint itself find config files — start at cwd and check each parent directory. The
idfield check ensures we only match actual Obsidian plugin manifests, not unrelatedmanifest.jsonfiles (e.g., Chrome extensions).Test plan
manifest.jsonis in a parent directory🤖 Generated with Claude Code