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

Vite >=3.0.1 fails to resolve projects in monorepo #9202

Closed
7 tasks done
lukashroch opened this issue Jul 18, 2022 · 12 comments · Fixed by #10254
Closed
7 tasks done

Vite >=3.0.1 fails to resolve projects in monorepo #9202

lukashroch opened this issue Jul 18, 2022 · 12 comments · Fixed by #10254
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)

Comments

@lukashroch
Copy link

lukashroch commented Jul 18, 2022

Describe the bug

Vite 3.0.1 and higher does not seem to resolve projects within the monorepo.

E.g. we got structure:

├─ apps
│  └─ app1
          └─ vite.config.ts
│  └─ app2
└─ packages
   └─ package1
   └─ package2

Since vite@3.0.1., I'm getting the error below:

Error: Cannot find module 'C:\Apps\repo\packages\common\src\types'
Require stack:
- C:\Apps\repo\apps\admin\vite.config.ts
- C:\Apps\repo\node_modules\.pnpm\vite@3.0.2_sass@1.32.13\node_modules\vite\dist\node\chunks\dep-1513d487.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (C:\Apps\repo\apps\admin\vite.config.ts:117:20)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object._require.extensions.<computed> [as .js] (file:///C:/Apps/repo/node_modules/.pnpm/vite@3.0.2_sass@1.32.13/node_modules/vite/dist/node/chunks/dep-1513d487.js:62817:24)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)

This was working fine up till vite@3.0.0 and breaks in vite@3.0.1 and up.

Vite now fails on relative import in vite.config.ts

import { something } from '../../packages/common/src/types';

Is there a more proper way to do this in vite?

Reproduction

https://stackblitz.com/edit/vitejs-vite-wg28sd?file=apps/app/vite.config.ts

cd apps/app
npm install
npm run build

System Info

System:
    OS: Windows 10 10.0.22000
    CPU: (4) x64 Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
    Memory: 3.85 GB / 15.86 GB
  Binaries:
    Node: 16.13.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.1.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 103.0.5060.114
    Edge: Spartan (44.22000.120.0), Chromium (102.0.1245.44)
    Internet Explorer: 11.0.22000.120

pnpm@v6.33.1

Used Package Manager

pnpm (own project) / npm (stackblitz)

Logs

Error: Cannot find module 'C:\Apps\repo\packages\common\src\types'
Require stack:
- C:\Apps\repo\apps\admin\vite.config.ts
- C:\Apps\repo\node_modules\.pnpm\vite@3.0.2_sass@1.32.13\node_modules\vite\dist\node\chunks\dep-1513d487.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (C:\Apps\repo\apps\admin\vite.config.ts:117:20)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object._require.extensions.<computed> [as .js] (file:///C:/Apps/repo/node_modules/.pnpm/vite@3.0.2_sass@1.32.13/node_modules/vite/dist/node/chunks/dep-1513d487.js:62817:24)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)

Validations

@bluwy
Copy link
Member

bluwy commented Jul 19, 2022

Likely a regression from #9140. We're bundling the Vite config and all the related files, but because the relative imports point to a file from a package that could have it's own node_modules, we can't bundle that file. So what happens is that node is trying to load the file in runtime, which doesn't work as it doesn't handle TS.

The original issue looks like a workaround for #5370, which doesn't work in the first place. Given this had worked in Vite 3.0.0, maybe it's worth finding a reasonable fix at the meantime, but the better solution overall is to compile the package as JS first.

lukashroch added a commit to MRC-Epid-it24/intake24 that referenced this issue Jul 19, 2022
@lukashroch
Copy link
Author

@bluwy thanks for your reply, I see that now!

It doesn't make much sense for me to build it in this particular case as it's mostly various shared code being pulled in to apps that take care of the build, whatever if pulled in. Also I had couple of reusable fragments for vite.config.ts in that place as we have multiple vue apps, so wanted to share same pieces. And that's when I started to have issues with vite@>=3.0.1.

For now, I ended up extracting fragments for vite build out of package with package.json / node_modules, which works OK as expected. But if this could be fix, that would be great.

@bluwy
Copy link
Member

bluwy commented Jul 21, 2022

I've been thinking about this and it's quite tricky in general to support this. It's either:

  1. We rewrite the import paths for files in a different package.
  2. Or bundle the file's dependencies.

And both aren't really good choices. The logic for bundling config files is also quite complex now since we had recent issues after Vite 3, and I'm hoping to not touch it anymore.

We might have to intentionally break this in 3.0.1 (even though I hate to break semver), but given that it's a workaround before, and it's only 1 patch away. Maybe that's still acceptable.

@KubaJastrz
Copy link

KubaJastrz commented Jul 26, 2022

Same thing happens with vitest@^0.17, as it uses the same mechanism for compiling TS config file.

the better solution overall is to compile the package as JS first

What if you don't have a compilation step? I'm using a shared package for defining config like so: https://stackblitz.com/edit/vitejs-vite-esn1xa?file=app%2Fvite.config.ts

It worked with vite@=<3.0.0.

Edit: interestingly enough, when you remove common/package.json, Vite compiles...

@danielrozenberg
Copy link

We found a workaround that works for our project, it might work for others (ymmv):

We figured out that we can run Vite through tsx (previously esno). i.e., instead of calling vite we call tsx node_modules/.bin/vite

@o-alexandrov
Copy link

We found a workaround that works for our project, it might work for others (ymmv):

We figured out that we can run Vite through tsx (previously esno). i.e., instead of calling vite we call tsx node_modules/.bin/vite

In a project w/ package.json "type": "module", using tsx on the vite's executable fails with:

Click to expand
{
  errors: [
    {
      detail: undefined,
      id: '',
      location: {
        column: 18,
        file: '../node_modules/.bin/vite.js',
        length: 9,
        line: 2,
        lineText: `basedir=$(dirname "$(echo "$0" | sed -e 's,\\\\,/,g')")`,
        namespace: '',
        suggestion: ')'
      },
      notes: [],
      pluginName: '',
      text: 'Expected ")" but found "\\"$(echo \\""'
    }
  ],
  warnings: []
}

@Dreamacro
Copy link

Is there any workaround? I also need to import a common vite.config.ts in monorepo.

@bluwy
Copy link
Member

bluwy commented Aug 15, 2022

@Dreamacro a workaround is to move the common config out from a workspace package so it doesn't have it's own node_modules. For example, moving the file to <root-monorepo>/scripts/common-config.js, and import the file via relative paths.

@cutsin
Copy link

cutsin commented Aug 18, 2022

@bluwy thanks for your reply, I see that now!

It doesn't make much sense for me to build it in this particular case as it's mostly various shared code being pulled in to apps that take care of the build, whatever if pulled in. Also I had couple of reusable fragments for vite.config.ts in that place as we have multiple vue apps, so wanted to share same pieces. And that's when I started to have issues with vite@>=3.0.1.

For now, I ended up extracting fragments for vite build out of package with package.json / node_modules, which works OK as expected. But if this could be fix, that would be great.

But actually its a breaking change.

@edikdeisling
Copy link
Contributor

This issue makes really hard to use common Vite configs because usually common configs use npm packages. Hope the solution would be found.

For now, here is my workaround:
Before:

"scripts": {
    "build": "vite build",
}

After:

"scripts": {
    "build": "ts-node node_modules/vite/bin/vite.js build",
}

@AkiraX2
Copy link

AkiraX2 commented Sep 24, 2022

This issue makes really hard to use common Vite configs because usually common configs use npm packages. Hope the solution would be found.

For now, here is my workaround: Before:

"scripts": {
    "build": "vite build",
}

After:

"scripts": {
    "build": "ts-node node_modules/vite/bin/vite.js build",
}

still got Error: Cannot find module '@shared/xxxx'

any other configs needed?

@edikdeisling
Copy link
Contributor

@maketa521 I think no. One more thing - I use pnpm. Maybe this matters. Also, my node version is v16.16.0
Here is a repo for reproducing it
https://github.com/edikdeisling/issue-vite-node-resolution

@antfu antfu added bug pending triage p3-minor-bug An edge case that only affects very specific usage (priority) and removed pending triage labels Sep 26, 2022
antfu added a commit to vueuse/vueuse that referenced this issue Sep 26, 2022
antfu added a commit to vueuse/vueuse that referenced this issue Sep 26, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Oct 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
p3-minor-bug An edge case that only affects very specific usage (priority)
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

10 participants