Reconsider usefulness of flatModuleOutFile

[bgotink]

Which @angular/* package(s) are relevant/related to the feature request?

compiler-cli

Description

The APF currently prescribes using the flatModuleOutFile to "generate a flattened ES Module index file". That file is just a re-export (cf code below) and it causes problems for projects trying to use Node16 as module/moduleResolution option in order to get typescript to understand package exports (#46181).

angular/packages/compiler-cli/src/ngtsc/entry_point/src/generator.ts

Lines 30 to 35 in c62b2da

	const contents = `/**
	* Generated bundle index. Do not edit.
	*/
	export * from '${relativeEntryPoint}';
	`;

The only benefit that I could find to adding flatModuleOutFile is that it triggers the compiler-cli package to check whether everything that is exposed from the package is exported from the package.

I want to streamline angular library compilation. We've got a proprietary library builder at work, and packages with multiple entry points currently require pretty annoying boilerplate and building is a slow process because every entry point is in its own source folder with its own (ng-)package.json file being built by its own typescript program.
Using exports this could be simplified quite a bit. Here's an example of where I'd like to end up:

{
  "name": "some-package",
  "exports": {
    ".": "./src/index.ts",
    "./sub": "./src/sub.ts"
  }
}

-> Compiler detects entry points automatically based on the exports, builds the entire package in a single typecript run, generates the FESM files and voilà, done.

I've created a proof-of-concept compiler implementation and plugged it into a small project I was working on, in case you're interested. Building this compiler required removing the flatModuleOutFile from the typescript config in order to allow multiple rootNames in the project.

Proposed solution

Support the "is everything that's exposed also exported?" check if there are multiple rootNames in the typescript project.
Remove the "use flatModuleOutFile" prescription in the APF document.

Alternatives considered

• Keep the situation as is
• We could stop using multiple entry points.
  We're actually moving in the opposite direction. We have over 100 packages in our biggest library and we want to scale this down. Entry points are the smallest unit the application javascript can be split at, so we are looking at merging smaller packages into bigger packages with multiple entry points.