Migrate to pnpm + turborepo

[webpro]

This monorepo is managed using Rush. The tool is opinionated and may work well
for certain projects and teams, yet it's not performing to our standards and
needs (which is also opinionated, lol). The main issue is that it's basically a
framework in front of everything. A framework works well, until it doesn't.

Let's follow widely used standards and the Unix philosophy a bit more: pick the
right tool for each job separately. So we can update and swap out tools
separately as the trend need arises.

Rush is also an extra unnecessary blocker/hurdle for using the latest versions of Node.js and pnpm.

What jobs?

• Build and test packages
• Format and lint source code
• Cache results of builds and tests to save time and resources
• Build and test packages, and only those affected in a pull request
• Publish packages
• Dependency management, e.g. to fixate versions of dependencies across packages

But how?

• pnpm does a lot out of the box already (with this PR we go from v6 to v8 btw!)
• turborepo seems great for caching and "affected packages" logic
• changesets seems great for changelogs and publishing

Guide

• Use more standards where possible, e.g. leverage "private": true for packages that should not be published.
• Use exit code to define results in CI (not stderr + warnings allowed). Also see Allow warnings in test and lint commands #442.
• Commands are run through the package manager (npm, pnpm, ...) based on the standardized package.json#scripts. When we replace a tool the commands don't change. You can run turbo build instead of pnpm build, but that's on you.
• The rush build job had linting included, such commands/actions should be separated (unless significant performance gain or something).

TODO

• Fix pactjs bin workarounds/issues e.g. in @kadena/client-examples
• Enforce fixed version across monorepo for certain/all dependencies
• Fix build of @kadena/client-examples
• Implement alternative to packageTable.ts
• Update docs
• Revisit ESLint rules (warning vs error) (Allow warnings in test and lint commands #442)

TODO in follow-up PRs

• Find out wat heft/rigs actually do for us
• Look into version policies (e.g. to "group" packages)
• Look into publishing with changesets
• Propose flat packages/* structure

Misc.

pnpm run test --filter @kadena/react-ui
pnpm run build --filter @kadena/client-examples
pnpm -r run "/^format:(md|pkg|src)/"

pnpm recursive list --json | jq --arg cwd "$PWD" '[ .[] | { name, version, private, path: (.path | sub("^" + $cwd + "/"; "")) } ]' > workspace.json

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1205075729086347

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

6 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
alpha-docs	⬜️ Ignored (Inspect)	Visit Preview		Aug 28, 2023 2:05pm
docs-storybook	⬜️ Ignored (Inspect)	Visit Preview		Aug 28, 2023 2:05pm
immutable-records	⬜️ Ignored (Inspect)	Visit Preview		Aug 28, 2023 2:05pm
react-ui	⬜️ Ignored (Inspect)	Visit Preview		Aug 28, 2023 2:05pm
tools	⬜️ Ignored (Inspect)	Visit Preview		Aug 28, 2023 2:05pm
transfer	⬜️ Ignored (Inspect)			Aug 28, 2023 2:05pm

[alber70g]

I'm missing a notion to add a changelog. How can a user add a changelog to the PR?

[webpro]

This is handled in another PR: #712

[alber70g]

This should be only node LTS versions

[alber70g]

Current LTS of node is 16 and 18.
Does this affect that?

https://github.com/nodejs/Release#nodejs-release-working-group

[webpro]

16 is EOL in a few weeks so I think we're good

[alber70g]

This is not a config file for the monorepo if I'm correct? Maybe to prevent wrong assumptions we can rename this, or cache it as a .workspace.json and regenerate when a packages is added (a simple ls ./packages/*/* would suffice)

[webpro]

I renamed it to packages.json and added a script to update it