Awesome
Monorepo + TypeScript + Next.js: The Sane Way
This repo is an experiment to set-up a monorepo for a Next.js project using modules located in other directories. Everything is not perfect and "real-world" ready, but it should be a good first step.
- Strict TypeScript: potential bugs are not an option
Transpiled server-side code: needed if you are going to re-use modules for both client and server-sideNot anymore, Next.js is plenty powerful now and does not need it anymore in 99% of the cases- Jest
- TypeScript
- ESLint (now included in Next.js 10)
- Transpile local packages with Next.js on-demand + HMR
My approach completely changed after a couple of projects, I realised the previous approach of having common configuration files was a bad practice:
- Not a true monorepo where every subfolder is a separate app
- Difficult to deploy and test on CI
Now, configuration files are repeated in each sub-folders, which means you need to be more careful regarding config and dependencies versions, but things are much easier to manage for developers and text editors.
Todos
- GitHub actions sample
- ESLint + Jest everywhere
More in details
TypeScript
The config is at the root of each project: <root>/<sub-project>/tsconfig.json
.
Unit-tests
Jest is used for unit tests and all test files should be put in __tests__
folders to match the Jest philosophy and not pollute your directories too much.
The config is at the root of each project: <root>/<sub-project>/jest.config.js
and all the tests can be run with npm run test:unit
in each folder.
Linting
npm run test:lint
Root folder
Put everything you want there, a Next app, shared code, a react-native app, a CRA, even Wordpress if you want.
Next.js and local modules
Next.js will transpile modules thanks to the next-transpile-modules
package. Transpiled modules can be changed by editing the transpileModules
option in website/next.config.js
.
Since Next.js 13.1, we can now use next.config.js
's transpilePackages
option to achieve the same.
This setup works thanks to npm symlinking local dependencies in website/
's node_modules
folder. Yarn workspaces would work as well (though requiring some adaptation from this bolerplate).