nextjs-monorepo-example VS changesets

For info you can have a look to a setup in httpx (simple yarn 4 + workspaces) or nextjs-monorepo-example (yarn 4 workspaces + turbo + recipe for docker)

I like https://github.com/belgattitude/nextjs-monorepo-example/

It's pretty easy to setup renovate, the "update dependency XXX PR" comes with the upstream changelogs from which you can have an idea of the work to do if needed. Compared to some other similar tools: monorepo support (ie: workspace:"") + possibility to dedupe your lock file + an easy way to regroug packages (ie: "@vitest/ui" and "vitest" together). An example: https://github.com/belgattitude/nextjs-monorepo-example/blob/main/renovate.json5.

https://github.com/belgattitude/nextjs-monorepo-example Here is a very good example monorepo with a similiar usecase

Until the “flat” eslint config file becomes the standard, Here’s a nice example of how to do it.

PS: You can see there: https://github.com/belgattitude/nextjs-monorepo-example (bunch of recipes but definitely needs a cleanup) and this question https://github.com/belgattitude/nextjs-monorepo-example/discussions/2220

There is one moderately complex example monorepo that includes a Next.js project and shared lib projects here: https://github.com/belgattitude/nextjs-monorepo-example

I sometimes put some examples in https://github.com/belgattitude/nextjs-monorepo-example. It's bare-bone and offer few pros/cons (no nx, no turbo.., but you can upgrade along the way).

But if you have time, you can have a look to this https://github.com/belgattitude/nextjs-monorepo-example/blob/main/apps/web-app/src/features/demo/demo.config.ts.

- If you're using yarn 1, go yarn 3+ with "node_linker: node_modules", eventually "nmMode: hardlinks-local" and yarn workspace plugin (example of .yarnrc.yml config). You'll get some speed up and the update should not be too long to do. Note: this gives comparable speed of pnpm in my experience (whatever benchmark I read).

In my circles, this is the go-to for release automation / changelogs: https://github.com/changesets/changesets

🦋 Publicando com changesets

Open source libraries and frameworks share a common necessity: the need to develop multiple packages cohesively and efficiently while managing their versioning and publishing to NPM. Nx has emerged as a go-to choice for handling such open source monorepos (as we'll explore further in the next section of this blog post). Until recently, one area Nx did not address directly was versioning and release management. Traditionally, this gap has been filled with tools like release-it, changesets, or custom Node scripts, similar to our approach in the Nx repository.

Doing these tasks by hand can quickly become a hassle. If you're open to receiving contributions from others, it can be an even bigger headache. In this post we'll cover how to use changesets to automate all of these steps.

For versioning we use changeset, but with fixed-packages. We have found that the user thinks updating and managing our dependencies much easier if they can just bump each package to the same version. (storybook, sanity follows this appoach). While it feels unintuitive that each package gets a major if just the CSS has breaking changes, the user don't really care. They just want to finish the chore of updating their dependencies fast, without having to understand the system that deeply. This also makes documenting the changes much easier!

Thanks for sharing this. Why should I choose that instead of Changesets that work like a charm?

You’re right this information would be better suited for for commit trailers. A lot more information can be put there as well. For the purpose of changelog generation, what it’s commonly used for, it could just as well be put in the trailers and not crammed into the subject. I personally prefer changesets though.