Clean setup with Next11

[Duckinm]

How can I integrate with Next11?

I already watched the boilerplates youtube videos and try them in many ways, but it seems not to work.

[bjorntheart]

This should get you started https://github.com/payloadcms/nextjs-custom-server

[jmikrut]

Hi all,

I absolutely love the depth of this conversation. As someone who has tried to do these same things with Payload, I think that the conversation has built up to reach the same conclusion that my team and I have come to independently.

The conclusion is....to set aliases up properly in a TypeScript / Webpack project, you need to set up the same aliases in at least two places:

1. webpack aliases, as @Duckinm has shown above
2. tsconfig paths, as @Ontopic has shown above

If you use ESLint, you should also set them up there as well. So that's possibly three locations that all need aliases set up in exactly the same way. Yikes. That's the world we live in, at least for now! Payload can do little in the way of optimizing that, unfortunately.

Also - @Ontopic:

Trust me, even though those examples are not here yet, you’ll see it’s just a matter of time for more docs and examples will show up

You are 100% correct. Many more examples and guides are on their way. We are actively planning to significantly ramp up efforts like this as I write this. On behalf of everyone at Payload, we REALLY appreciate your interaction and your support!

[Ontopic]

As said, tsconfig.json is for me just an "extra", merging NextJS and Payload's babel.config.js is what I use to get shared module aliases.

It goes something like this (contrived example, definitely worth a revisit when the babel.config.js pull is released for a cleaner example).

babel.config.js

const nextjsPreset = require('next/babel')

/*
TODO 😇
const payloadPreset = require('payload/babel')
*/

const moduleResolverPlugin = [
  require.resolve('babel-plugin-module-resolver'),
  {
    root: ['./'], // will make import from 'server/...' or 'client/...' workd
    alias: {
      server: './server/*',

      // pro-tip: add directory-named-webpack-plugin in next.config.js and payload.config.js to webpack step for super human imports without having a million index.js files
      library: './library/library.js',
      hooks: './hooks/hooks.js',
       ...
   },
   extensions: ['.js', '.jsx', '.tsx'],
]

const extraPlugins = [
  require.resolve('@babel/plugin-proposal-nullish-coalescing-operator'),
  require.resolve('@babel/plugin-proposal-do-expressions'),
  require.resolve('babel-plugin-inline-react-svg'),

  [require.resolve('babel-plugin-styled-components'),  {
     ssr: true,
     displayName: true,
     preprocess: false
  }],
]
...

const payloadConfig = {
  presets: [
    require.resolve('@babel/preset-typescript'),
    [
      ...copyPaste from payload/babel.config.js, //  turn into require when ready
    ]
  ],
  plugins: [
    ...copyPaste from payload/babel.config.js, // turn into require when ready

    ...extraPlugins,

    moduleResolverPlugin,
  ],
}

...

module.exports = api => {
   api.cache(true)
   

   // below is just meant for my setup, where my devops guys requested still being able to tear apart payload from the same container as nextjs, in case it turns out that local reads (which I love too much for dev) in production act up, so we can split things without breaking
   if (process.env['SERVICE_TO_START'] === 'server')
      ...
   else if   if (process.env['SERVICE_TO_START'] === 'client)
      ...

   const nextjsConfig = nextjsPreset.default(api)

   const config = {
      ...nextjsConfig,
      plugins: [
        ...nextjsConfig?.plugins,

        ...extraPlugins,

        moduleResolverPlugin,
      ],
    }

    ...

    return config
  }
}

[Ontopic]

Just not sure about eslint, I pretend that I don't need it 👻 , apart from that this works without duplicating configs anywhere, although type annotations may also not be as good in certain IDE's if you use Typescript for project level files and alias them in babel.config.js (I personally love Typescript for libraries / open source stuff, but for actual implementation for clientsI think it is often not worth the investment)

I started with the Babel setup because I also really like my do expressions and styled components, organising module aliases then for me felt like a "two for the price of one" solution.

@Duckinm definitely gonna play around with your solution as well, nice you figured it out! I feel with a combo of all the different solutions there's enough possibilities to cure the hatred of ../../../.. .... in anybody's preferred flavour

[henrituan]

Hi @Duckinm, thanks for your code snippets. I want to ask if you have any trouble building the app for production ?

For me, absolute imports work perfectly on dev (nodemon), but not with build commands such as payload build or payload generate:types.

For more info: I do have tsconfig-paths in my nodemon.json:

{
  "ext": "ts",
  "exec": "node -r tsconfig-paths/register -r ts-node/register src/server.ts"
}

However, I don't know how to configure tsconfig-paths for payload build command. I've tried this one but no luck:
cross-env PAYLOAD_CONFIG_PATH=src/payload.config.ts payload -r ts-node/register -r tsconfig-paths/register build.

Do you have any idea what did I miss ?

Thanks a lots

[Duckinm]

I successfully make it work in production without any issues. Honestly, the way I setup was too far from my brain memory!

Btw, you can see my old repository to figure this out yourself.
https://github.com/Duckinm/payload-next/