Skip to content

[Fix] importType: correctly classify aliases resolving outside package root#3228

Merged
ljharb merged 1 commit intoimport-js:mainfrom
DukeDeSouth:fix/496-aliases-extraneous-deps
Feb 19, 2026
Merged

[Fix] importType: correctly classify aliases resolving outside package root#3228
ljharb merged 1 commit intoimport-js:mainfrom
DukeDeSouth:fix/496-aliases-extraneous-deps

Conversation

@DukeDeSouth
Copy link
Contributor

@DukeDeSouth DukeDeSouth commented Feb 10, 2026

Summary

Fixes #496.

When a resolver (e.g., webpack, typescript) resolves an aliased import to a path outside the current package root but not in node_modules (e.g., a monorepo sibling package or a workspace alias target), isExternalPath previously classified it as 'external' because any path with a relative prefix of .. from the package root was treated as external. This caused no-extraneous-dependencies (and other rules using importType) to report false positives for these imports.

Root Cause

In src/core/importType.js, isExternalPath() had an overly aggressive first check:

if (relative(packagePath, path).startsWith('..')) {
    return true; // ← Any path outside package root = external
}

This correctly catches hoisted node_modules in monorepos, but incorrectly catches:

  • Monorepo sibling packages accessed via aliases
  • Alias targets pointing to code in parent/sibling directories
  • Workspace paths outside the current package boundary

Fix

The fix replaces the blanket "outside package root = external" check with a more targeted approach:

  1. Check if the path is under a configured external-module-folder relative to the package — preserves existing behavior for local node_modules
  2. For paths outside the package root, check if the external-module-folder appears as a path segment — catches hoisted deps (e.g., /monorepo/node_modules/lodash) but NOT sibling packages (e.g., /monorepo/packages/shared/src)

Also updates isInternalPath to be the logical complement of isExternalPath for resolved paths, so any successfully resolved path that is not in an external module folder is correctly classified as 'internal'.

Example scenario

/monorepo/
├── node_modules/           ← hoisted deps (still correctly external)
├── packages/
│   ├── app/                ← current package
│   │   ├── package.json
│   │   └── webpack.config.js  (alias: 'shared' → '../shared/src/')
│   └── shared/             ← sibling (now correctly internal)
│       └── src/
// In packages/app/src/index.js:
import { helper } from 'shared/utils'; // Was: 'external' (false positive) → Now: 'internal' ✓
import lodash from 'lodash';           // Still: 'external' ✓ (hoisted node_modules)

Test plan

  • Added new test fixture tests/files/alias-outside-package/package.json to create a sub-package boundary
  • Added importType test: alias that resolves outside the package root but not in node_modules'internal'
  • Added no-extraneous-dependencies valid test: aliased import from outside package root is not flagged
  • All 3009 existing tests pass (0 failures, 0 regressions)
  • Specifically: 35 importType tests passing, 128 no-extraneous-dependencies tests passing

…age root

Fixes import-js#496.

When a resolver (e.g., webpack, typescript) resolves an aliased import to a
path outside the current package root but NOT in node_modules (e.g., a monorepo
sibling package), `isExternalPath` previously classified it as 'external'
because any path with a relative prefix of '..' was treated as external. This
caused `no-extraneous-dependencies` to report false positives for these imports.

The fix replaces the blanket "outside package root = external" check in
`isExternalPath` with a more targeted approach:
1. Check if the path is under a configured external-module-folder relative to
   the package (preserves existing behavior for local node_modules)
2. For paths outside the package root, check if the external-module-folder
   appears as a path segment (catches hoisted deps in monorepos)

Also updates `isInternalPath` to be the logical complement of `isExternalPath`
for resolved paths, so any successfully resolved path that is not in an
external module folder is correctly classified as 'internal'.

Co-authored-by: Cursor <cursoragent@cursor.com>
@codecov
Copy link

codecov bot commented Feb 10, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.77%. Comparing base (eb6a828) to head (09f3c20).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3228      +/-   ##
==========================================
+ Coverage   90.69%   95.77%   +5.07%     
==========================================
  Files          83       83              
  Lines        3688     3688              
  Branches     1331     1331              
==========================================
+ Hits         3345     3532     +187     
+ Misses        343      156     -187     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

assuming the tests fail without the fix, and pass with, this looks great, thanks!

@ljharb ljharb merged commit 09f3c20 into import-js:main Feb 19, 2026
616 of 617 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

no-extraneous-dependencies: aliases are not considered "project"-level imports

2 participants