Migrate to Turborepo
complete
Support
The next big step in the boilerplate is to use a monorepo like turborepo to manage multiple application domains.
Example structure
/apps
/api - public API
/app - web app
/web - marketing, blog
= multiple instances. For the public API I'm still debating what framework, likely Nest.js or Hono.js.
/packages
/config
/db
/emails
/types
/ui
= everything that can be shared between apps.
Support
complete
A
Alexandru Stefanescu
Do you know if there has been any progress so far? Have you decided which technology to choose?
Anton Stasyuk
Alexandru Stefanescu https://github.com/achromaticlabs/pro/tree/feat/v2
A
Alexandru Stefanescu
Anton Stasyuk Ok thanks, but there is no API is there going to be in the future?
Anton Stasyuk
Alexandru Stefanescu I don't think there's need for it right now 🤷♂
Anton Stasyuk
Any news on this one?
Support
Anton Stasyuk Hi, the work on this is still going on.
The slowdown was because of the multi-organization support which is now in the test phase: https://demo-v2.achromatic.dev
Turborepo will be released together with multi-org as v2 of the boilerplate since both are substantial and/or breaking changes.
Anton Stasyuk
Support
Hi, do you have any date in mind? 😅
I’m currently integrating this into a project based on a TurboRepo setup and want to ensure it’s as seamless and future-proof as possible, especially regarding updates.
By the way, I’m the one who previously mentioned the Perfectionist ESLint plugin (as a replacement for the organize-imports rule in Prettier). Would like to create a PR for that.
I’m eagerly awaiting the TurboRepo updates—holding off on certain tasks for now since the mono-repo structure is likely to change things.
P.S.: Just in case you missed it, there’s a comment from November 26 about having different UIs for each app. Would love to hear your thoughts on that too!
Support
Anton Stasyuk I could release it today, but would be better to wait until end of the week.
The setup works well, I tried to combine the best parts of other turborepos, like next-forge. For example we have distributed env keys, e.g. the auth package uses t3-env to define its keys and the web project just extends them. I also added react email previews.
There are two things I would like to have a look at:
1) Instead of exporting files in the package.json, find another solution. This is the recommended solution, but not so ergonomic.
2) Prisma code generation is not consistent and sometimes needs to restart VS Code or TS server after a full pnpm clean:workspaces. It is the behavior as in other Turborepo setups with Prisma. It's a problem with VS Code or the TS server, the prisma files get generated correctly.
Also I would add web-e2e and storybook apps, but this can be after the release. I kept marketing and dashboard in one app, but made it possible to easily split them. This is beginner friendly and also in line with other boilerplates with Turborepo setup.
As for the public API the problem is the Next.js cache invalidation. There are multiple solutions, but nothing that I can add to the boilerplate without making it complicated.
One aspect that gets forgotten are background jobs. Most apps end up actually needing them. With this turborepo setup they would be easy to add.
Regarding the perfectionist, three other turborepos are also using the @trivago/prettier-plugin-sort-imports - I keep for now, but open for PR.
Anton Stasyuk
Support fantastic. Excited to dive in and explore the setup. 😊
Thanks for the response—looking forward to the release! 🚀
Anton Stasyuk
Support, just curious—any particular reason you used
@workspace/
instead of the standard Turborepo convention @repo/
?Support
Anton Stasyuk Both are fine, @repo is in the turborepo docs and @workspace in the shadcn monorepo example https://github.com/shadcn-ui/ui/blob/main/templates/monorepo-next/packages/ui/package.json
P
Phat Tran
Hi Support
When do we plan to finish this? Have we decided on the BE framework?
Daniel Skov Jacobsen
NestJS is better choice for API than Hono.js. Hono.js is great and I love building with it, but if you want to use Hono.js then you can easily opt-in to that on Next.js API routes and even host them on Cloudflare.
Choosing NestJS will enable building truly enterprise grade projects in a microservice architecture with API-Gateway, Shared / common packages, queues systems with RabbitMQ (or other) etc.
NestJS is not slow at all - not if you build it right and you can easily replace Express framework with Fastify (or even Deno 2.0) to gain even more performance. Another aspects for choosing NestJS is also the rich ecosytstem of express (npm packages).
NestJS is also not cumbersome to host. It's straitforward and easy. Of course you dont deploy NestJS on Vercel, but the whole point of separating this in monorepo architecture with Turborepo is to enable enterprise grade applications, else you can just as well build your Next.js API with Hono.js already.
C
Codebird
When is the Turborepo going to be released? Also, kindly consider Hono for APIs.
L
Leonardo Marciano
NestJS is cumbersome to host and somewhat slow nowadays due to its dependency on Node. Hono, on the other hand, is more modern and barrier-free, making it possible to use Bun, which delivers incredible performance results.
Bun + Vine.js (Vine is much more performant than Zod).
Another option is Encore.ts. Despite being new, it allows hosting on your own infrastructure, enabling developers to avoid managing databases, API gateways, firewalls, object storage, and notifications across multiple clouds. It offers a well-configured (and secure) deployment, unlike the trend of VPS platforms gaining popularity on Twitter that disregard distribution, resilience, and other critical aspects.
By far, it’s the best option, as Encore’s runtime outperforms even Bun’s runtime.
It’s also open-source.
The only issue is its current lack of popularity.
Anton Stasyuk
I think it’s a good idea to keep the UI for the CRM (admin panel) separate from the rest of the app. Instead, I'd focus on extracting the common helpers and hooks that can be used across different platforms. In real-world scenarios, it’s rare to have the same style for front-end as for internal systems. Also, Shadcn is primarily designed for building dashboard-like UI.
Basil T
Anton Stasyuk Agree with this aswell
Support
Anton Stasyuk This is true and I also thought about it. But it has a couple of advantages:
1) You can create a storybook app to have a documentation of your UI components. That's not just for humans, but also for LLMs. The storybook app is separate from your web project.
2) The package.json in the web project becomes much smaller. It's a tiny aspect I know :)
3) When splitting web into marketing and dashboard you can have a shared component library. Yes you would overwrite some styles for marketing since everything is a bit larger for the landing page, but it is the same design language underneath.
4) Same is true if you decide to put components into individual packages. Some people like to have auth components under /packages/auth or split features into a /packages/features folder with sub packages - including components.
5) There is a strict divide between UI and application components, guiding developers that don't care as much as you do where to put a component.
Support
in progress