Doesn't work with moduleResolution: node

[lukemacauley]

Adding to a current project and getting errors because of my ts config. Can we not run this with node resolution?

    "module": "esnext",
    "moduleResolution": "node",

Errors:

[3] app/(payload)/admin/[[...segments]]/page.tsx(4,26): error TS2307: Cannot find module '@payloadcms/next/views' or its corresponding type declarations.
[3] app/(payload)/api/[...slug]/route.ts(4,76): error TS2307: Cannot find module '@payloadcms/next/routes' or its corresponding type declarations.
[3] app/(payload)/api/graphql-playground/route.ts(4,40): error TS2307: Cannot find module '@payloadcms/next/routes' or its corresponding type declarations.
[3] app/(payload)/api/graphql/route.ts(4,30): error TS2307: Cannot find module '@payloadcms/next/routes' or its corresponding type declarations.
[3] app/(payload)/layout.tsx(4,28): error TS2307: Cannot find module '@payloadcms/next/layouts' or its corresponding type declarations.
[3] collections/Users.ts(1,39): error TS2307: Cannot find module 'payload/types' or its corresponding type declarations.
[3] payload.config.ts(7,29): error TS2307: Cannot find module 'payload/config' or its corresponding type declarations.

[jmikrut]

Hey @luke-ae — we have indeed dropped support for moduleResolution: node because it's honestly super dirty to support as a package maintainer, and TypeScript itself suggests not to use it in most cases. In 3.x, we have moved fully to ESM and with that, we are kinda looking to the future. I have lots of feelings about ESM but it's kind of a "rip off the bandaid" type thing.

Can I ask about why you are using it? If we get enough people asking for its support, we will take that into consideration, but so far you're the first. Just let me know. Super interested to learn more about your use-case.

PS - I am going to convert this to a Discussion on the main Payload repo because I want others to be able to find this and weigh in on it.

[kaiobarb]

I'm running into an issue where my team's custom react ui package gets littered with typescript errors that otherwise wouldn't pop up if moduleResolution were set to node. I don't have any issue with changing it to bundler per se, but I would like to know what the implications are for our custom library so that I can address it with the team and open a PR for it. Currently that's the only thing blocking us from integrating our application with Payload 3.0

[AlessioGr]

You can totally keep using moduleResolution node for your ui package. You just have to make sure that the package which is importing from payload packages is using moduleResolution NodeNext or bundler.

If that's what your ui package does then yea, you will have to change it to bundler or nodenext. Migration to nodenext is painful, but migration to bundler is simple. Most stuff will work as usual. Some packages need hacky workarounds to be imported, especially if they only export default exports. These are probably the TypeScript errors you are experiencing

E.g. instead of

import something from 'dumbpkg'

you might have to write

import somethingImport from 'dumbpkg'
const something = 'default' in somethingImport ? somethingImport.default : somethingImport

or

import * as somethingImport from 'dumbpkg'
const something = 'default' in somethingImport ? somethingImport.default : somethingImport

Another implication is that your package will only be available to be consumed within bundlers like turbopack or webpack, or using our hacky loader pattern. Especially for ui packages this should be fine, as you usually don't access them outside a bundler anyways