Tooling updates

[lauckhart]

• Use --isolatedModules as using a non-tsc transpiler is a little unsafe without it
• Use --skipLibCheck as type checking libraries is largely redundant
• Invoke typescript compiler via API to avoid warmup cost
• Fix type checking for tests which was inadvertently disabled by tsconfig restructure
• Stop using tsconfig entirely for command line builds except for type references
• Only emit types for libraries, just validate for applications
• New "graph" build command to display workspace dependency graph
• New "--workspaces" build option removes NPM and TSC overhead from workspace build
• On rebuild skip packages with no changes to source files or dependencies
• More robust bootstrapping for build & run
• Improved modularity of tooling code, mostly to support workspace builds
• Fix various relative path resolution issues when using --prefix
• Infrastructure is in place for parallel build but didn't bother as it'd require UI work

[Apollon77]

@vilic if you like ... be invited for review too ... you also seem to know a bit on Typescript and such :-)

[vilicvane]

@vilic if you like ... be invited for review too ... you also seem to know a bit on Typescript and such :-)

Thanks for the invitation. I looked through the changed files, but honestly this PR is both overwhelming and hard core to me. As the workflow doesn't seem familiar, and I never used many APIs appears in this PR.

But to the part I understand, it looks good to me. Actually I considered to replace all const enum to enum in my previous PR, but thought there would be too many changes. As they are now replaced, I suggest adding a lint rule banning the usage of const enum.

Some other suggestions/questions related:

1. Why not using .prettierignore instead of list of patterns? VSCode extension automatically formats everything that's not in the ignore list anyway. Which may result in some unnecessary changes in a PR polluting the line history.
2. skipLibCheck is good, but that also skips .d.ts in source code. Need a convention that bans .d.ts as source code.
3. I genuinely wonder how do you watch the build? Or you guys just don't do that, at least for now?

[Apollon77]

I can tell for 3.)
Because I most need to work with matter.js in general and matter-node or shell or such as a secondry target this is all not really making sense with watch (We still did not found out how to have a "sub project" (matter-node.js) also use the ts stuff and such ... so I do not use "watch" in this case here.

[Apollon77]

PS: Thank you very much for your time to check it. I totally agree to your first paragraph ;-)) "Black magic" :-)

[lauckhart]

Thanks @vilic You're right, .prettierignore seems like a better way to go. I'll make the change next time I have to touch the whitelist if nobody does it first. Also good point on .d.ts files, maybe a custom eslint rule is in order.

I don't really watch either, between large refactors and code gen I seem to have the world blown up a lot. I've used nodemon a couple of times but mostly just have esbuild and/or npm build pipelined before run/debug.

I considered adding a watch script to the root package.json using nodemon and our "build" but figured if we're going to maintain your tsconfig structure then tsc build/watch might be preferrable.

[vilicvane]

@lauckhart You may also consider that for eslint as well. BTW single quote (related pattern lists in package.json scripts) is not compatible on Windows (cmd) either.

[lauckhart]

BTW single quote (related pattern lists in package.json scripts) is not compatible on Windows (cmd) either.

Ah right, that raises the priority on moving to dotfiles. I opened #425 to track.