Relationships
↔ sibling #3630#3782 extension push finds no local modules when a folder above the repo is named node_modules
Opened by skunk-ape · 10/22/2026· Shipped 10/22/2026
Summary
Extension push fails when any folder above the repo is named node_modules (for example a repo checked out at /home/[REDACTED]/node_modules/myrepo/). isLocalModuleSpecifier in src/domain/extensions/bare_import_resolution.ts decides whether a file: module is an installed npm package by checking every segment of the module's absolute path for node_modules. So it does not limit the check to the path below the extension or project root. Under such an ancestor, every local module of the extension counts as an npm package file.
Effect
The same check drives the local-module classification in parseDenoInfoGraph (src/infrastructure/.../deno_info_module_graph_reader.ts, around lines 130 and 149). With a node_modules ancestor the module graph has no local modules, and push fails with "deno info listed no local module". This happens in both deno.json and package.json bundling modes. It predates the package.json-mode bundling work (swamp-club#3630).
Fix direction
Classify a module as an installed package only when a node_modules segment lies below the extension or project root: compare relative(root, fromFileUrl(specifier)) split on both separators. That means passing the root through parseDenoInfoGraph, bareImportsFromDenoInfo, and readBareImports in src/domain/models/bundle.ts, for every mode. The installedPackageDir helper added in #3630 takes the last node_modules segment and is correct once the classification is fixed.
Tests
Unit tests with a temp root under a node_modules ancestor, for isLocalModuleSpecifier and for parseDenoInfoGraph; check on Windows paths too.
Found while fixing swamp-club#3780 (the same absolute-path mistake in the extension source content pre-scan).
Shipped
Click a lifecycle step above to view its details.
Sign in to post a ripple.