For apps they are fine. (Unless it's a public microfrontend?)

On release, if a package has a bin with the same name as the package (the common usecase), the shim entry in the packageJson is also replaced with a version number.

Running pnpm i after a release should not modify any package.json files.

This would allow for a better and faster setup where all distributor scripts can run together, not worrig about race conditions

Simple, single file tsconfigs work okay now.

The main purpose of a composite setup would be to overlay two ts compilation scopes over eachother. One for the actual source code and the other for tests. The test ones can include some extra globals, and the source code can compile itself without the tests.

But when you don't use tsc for compilation this doesn't matter anymore. And vitest is perfecly fine to use with explicit imports instead of global describe, it etc functions.

The only downside is that vite-plugin-dts will use the scope defined in tsconfig, and that includes everything, meaning you will also export types for all the tests. Which won't be used and is unnecessary to compile.

But does this worth having a much more complicated tsconfig setup? Is there any more benefit?

https://typescript-eslint.io/blog/announcing-typescript-eslint-v6/

check prelink step for bins

postinstall bins are not found

support pnpm-workspace like the workspaces option in package.json

https://eslint.org/docs/latest/use/configure/migration-guide#typescript-types-for-flat-config-files

https://vitejs.dev/guide/migration.html

https://rollupjs.org/guide/en/#migration

https://twitter.com/whizzaf/status/1675849331528663041

Same with cjs bundles, do only esm

files.readonlyInclude

remcohaszing/unified-prettier#1

idea: https://www.peterbe.com/plog/programmatically-control-the-matrix-in-a-github-action-workflow

Collect all non-private packages in the workspace