fix(plugin): follow aliased/tsconfig-path imports into the MT worklet graph

[KealanAU]

Fixes #191.

Summary

MT worklets imported through aliases, tsconfig paths, or package specifiers were dropped from the main-thread graph, so their registrations never ran.

• Makes worklet-loader-mt async and resolves non-relative imports with this.getResolve(...).
• Follows project/aliased source outside node_modules and re-emits the original specifier for bundler resolution.
• Adds opt-in includeWorkletPackages (string or RegExp) for packages that intentionally ship MT worklets.
• Keeps relative imports and shared/runtime/vue sub-module skips unchanged.

Allowlist matching (addresses review)

Both decision points now reduce their input to a package root before matching, so a specifier and a resolved path always compare as the same thing.

• packageRootFromSpecifier reduces an import specifier (@org/foo/dist/x → @org/foo).
• packageNameFromNodeModulesPath reduces a resolved path (…/node_modules/@org/foo/dist/index.js → @org/foo), using the last node_modules segment so nested deps and pnpm layouts resolve.
• Both feed the single isWorkletPackage matcher, so /^@org\// matches at the follow checkpoint AND the loader carve-out — no more silent misses for RegExp users.

Safety

• Unresolvable specifiers are skipped instead of failing the build.
• Imports inside comments and string/template literals are masked before extraction, so doc examples and code-building worklets aren't followed as real edges.
• Backward compatible: this only adds followed graph edges.

Verification

• worklet-loader-imports.test.ts: 46 tests, including a path-vs-specifier RegExp parity test and end-to-end RegExp/subpath cases through the real loader.
• Full testing-library suite green in CI; plugin build passes; Biome clean.

[vercel]

@KealanAU is attempting to deploy a commit to the huxpro's projects Team on Vercel.

A member of the Team first needs to authorize it.

[KealanAU]

Follow-up: CI Dev Smoke caught a build failure exposed by this change.

• Following aliased imports into vue-lynx's own source now pulls in runtime/src/index.ts.
• Its import-extractor matched a JSDoc example (* import App from './App.vue';) as a real edge
  and re-emitted it, which can't resolve → build failed.
• Fix: stripComments (preserving string/template literals) runs before specifier extraction in
  extractImportSpecifiers and extractSharedImports.
• Added tests for imports in line/block comments and for comment delimiters inside string
  literals.

Parser-level fix rather than deleting the docblock — comment imports shouldn't be load-bearing
for the build regardless of which followed module they live in.

[Huxpro]

Blocking from my side: includeWorkletPackages now documents/tests RegExp support, but the matching model is still inconsistent across the code path this PR is fixing.

At one decision point the regex is matched against the original import specifier/package name, but when the traversal logic decides whether to keep following into the resolved node_modules target, the effective input is the resolved absolute path. That means a documented pattern like /^@my-org\// will match @my-org/foo but can never match something like /project/node_modules/@my-org/foo/dist/index.js, so RegExp users can still silently miss worklets here.

I think this needs one stable matching input at both checkpoints, ideally the original package specifier/package root rather than a filesystem path.

[KealanAU]

Addressed — both checkpoints now match one stable input.

I added packageRootFromSpecifier (specifier → package root) and packageNameFromNodeModulesPath (resolved path → package root, via the last node_modules segment for nested/pnpm layouts). Both checkpoints reduce to that root and route through a single isWorkletPackage matcher, so the allowlist always compares against a package specifier, never a filesystem path.

Concretely, /^@my-org\// now matches at the import-follow checkpoint AND the node_modules loader carve-out for /project/node_modules/@my-org/foo/dist/index.js — the divergence you flagged is gone.

Pinned by tests:

• packageNameFromNodeModulesPath path-derived name matches the same RegExp allowlist as a specifier.
• A RegExp allowlist entry followed end-to-end through the real loader (allowed vs. dropped).
• A subpath import (@org/motion/extras) matched against the package-root allowlist (@org/motion).

Commits: 980f3f1 (route both checkpoints through isWorkletPackage) and b485625 (reduce both inputs to the package root so subpath-sensitive patterns can't diverge).

[Huxpro]

Thanks for the thorough follow-through here. The matching model is now consistent across both checkpoints — reducing specifiers and resolved paths to a package root and running both through a single isWorkletPackage matcher fully addresses my earlier concern, and the path-vs-specifier RegExp parity test plus the end-to-end subpath case make it hard to regress. The comment/literal masking is a clean parser-level fix for the JSDoc-import build failure rather than a one-off patch. Behavior stays backward-compatible (only additive graph edges; unresolvable specifiers are skipped), CI is green, and the 46 tests cover the fragile surfaces well. LGTM.

(The red Vercel status is just the external-contributor deploy-authorization gate, not a code failure.)

---

Generated by Claude Code

[Huxpro]

Second-pass review complete. Fixed the stateful RegExp allowlist edge case by testing against a cloned expression, added regression coverage for both global and sticky flags (including preserving caller lastIndex), and reran the focused suite (48/48), lint, and the full monorepo build locally. All six repository CI checks are green on 3c01812; the remaining Vercel status is the known fork authorization failure rather than a code failure.