Do the files in node_modules\@deepkit\type\dist\esm\src exist?

node_modules\@deepkit\type\dist\esm\src exists.

Can the layout of the monorepo be an issue?
There is only one node_modules and one package.json for the whole repo at the root level and Nx is supposed to detect the dependency used by each package.

├───apps
│   ├───kds
│   │   ├───src
│   │   │   ├───components
│   │   │   ├───core
│   │   │   │   ├───data
│   │   │   │   ├───orders
│   │   │   │   ├───transform
│   │   │   │   └───ui
│   │   │   ├───styles
│   │   │   ├───utils
│   │       └───views
├───libs
│   └───shared
│       └───src   
├───node_modules
│   ├───@deepkit
│   │   ├───core
│   │   │   ├───dist
│   │   │   │   ├───cjs
│   │   │   │   │   ├───src
│   │   │   │   │   └───tests
│   │   │   │   └───esm
│   │   │   │       ├───src
│   │   │   │       └───tests
│   │   │   ├───node_modules
│   │   │   │   └───to-fast-properties
│   │   │   ├───src
│   │   │   └───tests
│   │   └───type
│   │       ├───dist
│   │       │   ├───cjs
│   │       │   │   └───src
│   │       │   └───esm
│   │       │       └───src
│   │       └───node_modules
│    package.json   

Does your tree structure mean there are no files at all in it? It looks for a file node_modules\@deepkit\type\dist\esm\src\types.js. is this available?

Yes, the node_modules\@deepkit\type\dist\esm\src\types.js is present

What I tried to illustrate in the tree, is that there no separate node_modules for each "package".

That's fine. I use monorepos all the time, so that shouldn't be a problem. So the file exists but your build tool complains it does not exist. This is unfortunately not related to deepkit as the only thing we need to make sure is that the files are available and they correctly import each other. Anything else is up to the build tool.

Does node_modules\@deepkit\type\dist\esm\index.js have the correct import to the type file?

Nx calls nextjs build tool
So I get the same error using
npx next build

If I understood your question correctly

node_modules\@deepkit\type\dist\esm\index.js

export * from './src/types';

Ok, that code looks fine. So, it seems you installed all the packages correctly and the files are correct. At this point, I can't help further as I have no idea how next builds the stuff and how to debug that error using it. I'd probably try to modify the file node_modules\@deepkit\type\dist\esm\index.js a bit and check if that has any implication and if so which one (so to check if that is really the actual read/used file for example)

Thanks.
I really appreciate the pointers on how to fix the issue :) !

On a side note, I see this project is using Lerna.
Have you used others in the past or thinking of migrating to others?

I've seen Lerna isn't actively maintained anymore.
lerna/lerna#2703 (comment)

Have you used others in the past or thinking of migrating to others?

Yeah, was thinking about using Rush from Microsoft, but nothing concretely planned. Lerna works well for the moment still. :)

I posted the issue at vercel/next.js#31974

TL;DR: Fails with NextJS 12.x. Works with NextJS 11.x

Could you have a look at
vercel/next.js#31974 (comment)
for a possible explanation on the underlying issue.

"when available. node_modules are directly loaded by Node.js and not bundled, so the Node.js ESM guidelines apply."

TypeScript's compiler does not support Node's default ESM resolution algorithm. They have introduced it in version 4.5 beta https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#esm-nodejs, but dropped it in the final 4.5 due to issues. To enable the commonly used module resolution algorithm you have to pass to node --experimental-specifier-resolution=node. You can also configure that in your environment variable NODE_OPTIONS=--experimental-specifier-resolution=node. If nextjs supports passing custom node arguments, you can configure it there.

some problem next 12

and dont fixed -> NODE_OPTIONS=--experimental-specifier-resolution=node

I think it would help to add the .js file extension on all internal imports to fix the ESM packages, this should not break the CJS packages.

We added already a lot of .js file extension in our imports, not all are covered yet though

@marcj Okay, here a MR #302 to add the missing file extensions, too :)

if that means it will work with nuxt 3 as well ?

@productdevbook If nuxt / next uses ESM and the file extensions were the only problem, then yes, but I don't know if there are other problems, we will see once the PR is merged and a new release is released