Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package exports eg @/pkg/foo not resolved locally #19292

Open
7 tasks done
TeemuKoivisto opened this issue Jan 26, 2025 · 2 comments
Open
7 tasks done

Package exports eg @/pkg/foo not resolved locally #19292

TeemuKoivisto opened this issue Jan 26, 2025 · 2 comments
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)

Comments

@TeemuKoivisto
Copy link

Describe the bug

So I have a local package @/lib in pnpm monorepo which works and I'm able to use it correctly. However, the second I add another "exports" definition to its package.json, Vite (or more specifically it seems Rollup) fails to import it.

error during build:
[vite]: Rollup failed to resolve import "@/lib/schemas" from "/Users/teemu/git_projects/omat/vite-module-not-found-bug/packages/bug/src/index.ts".
This is most likely unintended because it can break your application at runtime.
If you do want to externalize this module explicitly add it to

Using just @/lib works fine. It's the subpathing @/lib/schemas that makes Rollup/Vite go haywire. If I externalize it, as the log suggests it, this doesn't work:

      external: [
        ...Object.keys(pkg.dependencies || {}),
      ],

Because, as you should realize, the @/lib value does not externalize @/lib/schemas. So what you should do is:

      external: [
         '@/lib/schemas'
      ],

But this is in many ways extremely awkward and, I think, undefined behavior. @/lib package names are absolutely valid locally as they are as global npm packages. And "exports" should work as intended no matter what the package name is, as long as it valid. The fact that this specific pattern blows up the build with a vague error that gives no clue what's going on is terrible.

I might have encountered this bug before but probably thought it was going to be fixed one day.

Using my-lib as the package name with my-lib/schema export works flawlessly, so it's the @/lib pattern at fault here.

Reproduction

https://github.com/TeemuKoivisto/vite-module-not-found-bug

Steps to reproduce

git clone https://github.com/TeemuKoivisto/vite-module-not-found-bug
pnpm i
pnpm pnpm --filter lib --filter my-lib build
pnpm --filter bug build

System Info

System:
    OS: macOS 15.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 84.16 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.11.0 - ~/.nvm/versions/node/v22.11.0/bin/node
    npm: 10.9.0 - ~/.nvm/versions/node/v22.11.0/bin/npm
    pnpm: 9.12.3 - ~/Library/pnpm/pnpm
    bun: 1.1.31 - /opt/homebrew/bin/bun
  Browsers:
    Chrome: 131.0.6778.265
    Safari: 18.1
  npmPackages:
    vite: ^6.0.11 => 6.0.11

Used Package Manager

pnpm

Logs

No response

Validations

@TeemuKoivisto
Copy link
Author

Hmm. Now that I tested it a bit again, apparently it's exactly the name @/lib that causes all of this misery. While it's valid as package name, Rollup(?) expects the organization to include at least one character after @. I previously gave up on giving org names locally since @/pkg works much better to indicate package is local and is much shorter. Also it does not conflict with anything in npm.

@hi-ogawa
Copy link
Collaborator

hi-ogawa commented Jan 27, 2025

This looks like a bug since Node handles @/pkg as packageName https://nodejs.org/docs/latest/api/esm.html#resolution-algorithm (it's mentioned as If packageSpecifier does not start with "@" ... Otherwise, ... in PACKAGE_RESOLVE).

@hi-ogawa hi-ogawa added p3-minor-bug An edge case that only affects very specific usage (priority) and removed pending triage labels Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
None yet
Development

No branches or pull requests

2 participants