Add Lerna example

[christianjuth]

Overview

This PR adds a Lerna example with TypeScript, SWC, Jest, and Nodemon already configured.

I'm already using all of these together in my Lerna monorepo, and this example takes the configuration I use and strips it down to just what you need to get started.

I'm sure the example will need a few improvements, but I can't stress how much this toolchain has improved my Lerna workflow. I would love to see this merged so others can try it themselves!

A couple of things I'm not sure about:

Checkbox indicates the decision I went with: check=agree, no check=disagree

• We be responsible for building before publishing (via yarn run release)
• We handle cleaning the build dir before building the TypeScript files (cleans old deleted files via npx rimraf...)
• When publishing, we should fail early before building if the Git working tree isn't clean
• We should include a place for packages that are outside the Lerna package repo in case you want shared code that doesn't get published to NPM/other package manager (see @dakshshah96 's comment below)

These are all things I do in my own Lerna + TS + Turborepo, but they are more opinionated, so I'm not sure if I should include them.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/vercel/turbo-site/7mw7AChP5HZj7EaSTPN2PjXHTCy2
✅ Preview: https://turbo-site-git-fork-christianjuth-main.vercel.sh

[dakshshah96]

@christianjuth Thanks, I was looking for something like this so I could get started with Turborepo.

A question—how would you go about adding a common folder here which consists of files that any of the packages could include in their code?

[christianjuth]

@dakshshah96 for my repo, I have packages that depend on other packages. For example, I have a Tic Tac Toe solver that depends on a minimax package I wrote. But if you don't want to make everything a package that gets published to npm, I would create a second packages folder for packages that don't get published (this naming is confusing since everything is a package).  Let's call this second packages folder common.

Basically, your root repo would have something like this:

• turborepo (root folder)
  • packages
    • npm-package-a
    • npm-package-b
  • common
    • math-package
  • package.json (see blow)

The package.json specified above would look something like this:

{
  "name": "root",
  "private": true,
  "workspaces": [
    "packages/*",
    "common/*", // add this to my example
  ]
}

This would allow you to import math-package from npm-package-a or npm-package-b. Keep in mind the name of these packages does not come from the folder name, but the name field in math-packag/package.json, npm-package-a/package.json, and npm-package-b/package.json.

Don't forget to add math-package as a dependency to math-packag/package.json and whatever other packages use it.

Building

For packages under common, you can choose to give them a build step or not. Say that math-package was written in TypeScript and you were only importing it from other TS packages, then I would say let those other packages build them imported code. If however, you wanted math-package to export both TS and plain JavaScript code, then maybe it would make sense for it to have its own build step.

[jaredpalmer]

Closing in favor of #269 as this is going to be more widely applicable for the use case. Appreciate this as a starting point! Thank you!