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
pnpm workspaces 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/rollup@4.30.1/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", "**/.*/"],
}
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:
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.Let's say for example we have a shared pnpm workspace with the name
@local/pkgand we're trying to import a constant calledSOME_VARfrom there in a file on the frontend located atsrc/file.ts. When we try to do that, we get this error:Through some debugging I managed to figure out that the source of this issue appears to be the way that
@local/pkgexports its values. Here is whatindex.tslooks like within@local/pkg: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 constantSOME_VAR. I confirmed this is the issue because if I re-exportSOME_VARas a named constant withinindex.tslike this:...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.tson the frontend:package.jsonin@local/pkg:tsconfig.jsonin@local/pkg: