This repository is managed with Nx. The tool allows you to easily manage monorepos and have multiple apps running in the same repo, with a shared set of libs, and a common package.json to maintain consistent versions across packages.
Video explaining the problem: https://youtu.be/7AGjUiXmkzg
The Next.JS app is in apps/frontend
To build it: yarn build frontend --> output is in dist/apps/frontend
To serve it locally: yarn serve frontend
! Important: apps/frontend/pages/index.tsx depends on libs/custom-utilities (why this is important explained below)
Goal: deploy the frontend app to now.sh.
-
We could either deploy the whole monorepo, and tell
now.shto look indist/apps/frontend. -
Or
cdtoapps/frontendand deploy just the app.
Problems with above:
-
We can't deploy the whole monorepo because dozens of other libraries/projects might be part of it. We only want to deploy the files necessary for the
frontendapp to run correctly. -
Because we're in a monorepo, we only have a root
package.jsonto ensure dependency versions are in sync. We can copy the rootpackage.jsonto the frontend project just before pushing it Now.sh, but we don't know which of the dependencies in are needed just forfrontend(the risk of installing to many unnecessary deps) -
frontendmight depend on some locallibs/(which it does!) We don't know which ones, so we'd have to deploy the wholelibsfolder - which might be very big!
now.sh works incredibly well (and I apologize in advance if I get any of this wrong) if you push the sources for a Next.JS project and you allow it to:
- do the build
- configure its serverless functions to allow SSR
However, if you'd allow developers to:
- do the build part locally
- push the built artifacts to
now.sh--> which then does only the second part: create serveless functions for SSR and serve it.
If we build locally, where we have all the dependencies necessary, and we deploy the built artifacts, which contains just the code needed for frontend, it would solve all the above problems.