-
Notifications
You must be signed in to change notification settings - Fork 21
Description
This is a bit of a weird one, and I am like... 80% sure it's a bug and not something I'm just doing wrong. Been pulling my hair out for days trying to make it work to no avail.
Here's the setup:
- We use
pnpmworkspaces to organize our monorepo. We have several "shared" workspaces which have to be built as CommonJS modules for legacy reasons. These are shared between our backend and the frontend. - We're migrating the frontend from CRA to Vite, and to utilize these shared packages we followed the instructions here for Monorepos and linked dependencies and made sure to install the Vite CommonJS plugin.
Let's say for example we have a shared pnpm workspace with the name @local/pkg and we're trying to import a constant called SOME_VAR from there in a file on the frontend located at src/file.ts. When we try to do that, we get this error:
error during build:
src/file.ts (2:2): "SOME_VAR" is not exported by "../../local/pkg/dist/js/index.js", imported by "src/file.ts".
file: /.../frontend/app/src/file.ts:2:2
1: import {
2: SOME_VAR,
^
at getRollupError (file:///.../node_modules/.pnpm/[email protected]/node_modules/rollup/dist/es/shared/parseAst.js:396:41)
Through some debugging I managed to figure out that the source of this issue appears to be the way that @local/pkg exports its values. Here is what index.ts looks like within @local/pkg:
export * from './some-nested-modules';
export * from './some-other-nested-module';
...
So it is re-exporting all of its nested modules' exports with export *. And one of these nested modules is what directly exports the named constant SOME_VAR. I confirmed this is the issue because if I re-export SOME_VAR as a named constant within index.ts like this:
export { SOME_VAR } from './some-nested-module';
...
...then the build error disappears. Unfortunately, it's just not possible for us to re-export all of our nested exports as named exports like this, so while in theory this is a workaround for smaller or simple projects, it's not an option for us.
Nonetheless, it seems like there shouldn't be any problem with exporting in this way. So this seems like a bug to me. If it's helpful, here is some more information:
vite.config.ts on the frontend:
export default defineConfig({
plugins: [react(), viteTSConfigPaths(), commonjs(), svgr()],
optimizeDeps: {
force: true,
include: [
'@local/pkg',
],
},
build: {
commonjsOptions: {
include: [
/node_modules/,
/@local\/pkg/,
],
transformMixedEsModules: true,
},
},
});
package.json in @local/pkg:
{
"name": "@local/pkg",
"version": "1.0.0",
"main": "dist/js/index",
"typings": "dist/js/index",
...
tsconfig.json in @local/pkg:
{
"compilerOptions": {
"outDir": "dist/js",
"rootDir": "src",
"lib": ["ES2022", "DOM"],
"module": "NodeNext",
"target": "ES2022",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true,
"moduleResolution": "NodeNext",
"composite": true,
"declaration": true,
"declarationMap": true
},
"include": ["src"],
"exclude": ["node_modules", "**/node_modules", ".vscode", "**/.*/"],
}