mirror of
https://github.com/sotashimozono/obsidian-remote-ssh.git
synced 2026-07-22 06:52:07 +00:00
7d1830d549
* build(workspaces): root npm-workspaces so the validator resolves plugin types ObsidianReviewBot scans from the repo ROOT (getManifest reads cwd/manifest.json), installs at the root, and type-checks plugin/src via ./tsconfig.json with @typescript-eslint/no-unsafe-member-access. The plugin lives in plugin/ with deps in plugin/node_modules, so a root install resolved nothing -> @types/node + obsidian unresolved -> false "unsafe member access" warnings. #392 (typeRoots) couldn't help because plugin/node_modules doesn't exist in the validator's root-only install. Declare the root as an npm workspace ({ workspaces: ["plugin"] }). A root install now hoists the plugin's deps into root/node_modules; the root tsconfig's typeRoots picks them up. Verified by simulating the validator (rm plugin/node_modules; install at root only): @types/node + obsidian hoisted, eslint from cwd=root -> 0 unsafe-member-access. CI unaffected: cd plugin; npm ci still works (plugin/package-lock.json retained, 439 packages, 0 vuln) -- no workflow changes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * build(deps): pin obsidian to ~1.12.3 so the validator type-checks deprecation-free With the workspace root now resolving types, a root install pulled obsidian "latest" = 1.13.0, which deprecates SettingTab.display() and ButtonComponent.setWarning(). The validator's @typescript-eslint/no-deprecated then flagged 9 errors in SettingsTab.ts that the plugin's own CI never saw (plugin lock pinned 1.12.3). "obsidian": "latest" is a non-reproducible anti-pattern regardless. Pin to ~1.12.3 (the last release before those APIs were deprecated). Verified by simulating the validator (root install -> obsidian 1.12.3; eslint from cwd=root): 0 no-deprecated, 0 unsafe-member-access, EXIT 0. The declarative getSettingDefinitions()/setDestructive() migration is deferred until we intentionally raise the obsidian floor. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * build: plain root devDeps instead of workspaces (keeps CI green) The workspaces approach broke CI: npm hoists the plugin's deps into root/node_modules, but the plugin's CI invokes binaries by direct path (`node node_modules/typescript/bin/tsc`, `node node_modules/vitest/...`), which are then absent from plugin/node_modules. Hoisting is intrinsic to workspaces, so any workspaces setup would require workflow changes. Instead, make the root package.json a plain (non-workspace) manifest that declares only the deps the validator needs to type-check plugin/src from the repo root. A root `npm install` populates root/node_modules and the root tsconfig resolves types there. The plugin's own `cd plugin; npm ci` is untouched (no hoisting) -> CI stays green with zero workflow changes. Verified: move plugin/node_modules aside, eslint from cwd=root with root deps only -> 0 unsafe-member-access, 0 no-deprecated, 0 cannot-be-resolved. Trade-off: type-dep versions are duplicated between root and plugin and must be kept in sync (noted in the root package.json description). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
10 lines
263 B
JSON
10 lines
263 B
JSON
{
|
|
"extends": "./plugin/tsconfig.json",
|
|
"compilerOptions": {
|
|
"module": "commonjs",
|
|
"moduleResolution": "node",
|
|
"typeRoots": ["./node_modules/@types", "./plugin/node_modules/@types"],
|
|
"types": ["node"]
|
|
},
|
|
"include": ["plugin/src/**/*.ts"]
|
|
}
|