Compile to CJS and ESM

[NullVoxPopuli]

very wip

at the time of pushing, I've run in to:

 ERROR  run failed: Invalid package dependency graph: cyclic dependency detected:
	@embroider/macros,@embroider/core
Turbo error: Invalid package dependency graph: cyclic dependency detected:
	@embroider/macros,@embroider/core

which may require untangling the package cycle

Why turbo?

When moving from a one-build-across-the-whole-repo to a build per package, we need to build packages in the "correct order", for example, @embroider/core needs to be built before @embroider/addon-dev. Turbo is really good at this.

We only need turbo for script order orchestration, and we don't really care about anything else.

Why build-per-package

the way we've used tsc, transpiles each file co-located to the original source location. tsc does not provide a way to build to multiple targets at once -- additionally, tsc does not provide a way to change the file extension depending on target -- rollup is really good at this.

the way people have used tsc for multi-target projects outside of embroider is to have a tsc build per project, where they can specify a separate output directory (dist/cjs and dist/esm, for example) -- but this breaks the ability to typecheck the whole repo at once.

Build types can happen with tsc still with some "clever CLI args". I want to keep the ts setup mostly the same in this PR, and we can iterate on doing other things with tsc later, but this would allow us to keep monorepo-wide type-checking (pnpm tsc --watch --noEmit, for example)

Why test packages?

when determinining the package graph, we must ignore cycles. Because devDependencies are no different from dependencies when it comes to "what must be built in what order", we have to untangle the graph. Extracting a test package for relevant packages is one way to untangling cycles in the graph.

What do we lose with this approach?

simplicity
the single tsc strategy is very simple, and easy to maintain -- with one build per project we have a lot more files / configs to maintain.

• package.json#exports
• rollup.config.mjs's -- though most of this is extracted to @embroider/build (a new private/internal package)

What we keep

the ability to code anywhere, and see errors everywhere