RFC: Unify apps and ESM views

[cristiano-belloni]

This is a discussion about the differences and similarities between the upcoming ESM views and regular modular apps. ESM views are a breaking change which shifts the concept of "modular view" from "plain package with a React dependency" to "ESM micro-frontend that deduplicate dependencies via an external CDN". The question is if we can see views as just another type of app (or vice-versa), in light of the fact that apps and ESM views share almost the same build configuration - and if it makes sense, at this point, to merge the two modular types into one.

Differences

functionality	app	esm view
JS	Everything is bundled in the dist result (local files + external dependencies). App has a main entrypoint which explicitly renders a React tree in a root DOM element.	local files are bundled in the dist result but imports from external dependencies are rewritten to point to a configurable CDN (save for a configurable list of dependencies that is empty by default). The view has a main entrypoint whose default export is a React component. Actual React rendering is done either by a synthetic trampoline file that takes the main entrypoint and renders its default export to a DOM node (standalone mode) or by an external host application which discovers the main entrypoint via the package manifest and renders it wherever it's needed.
index	index.html must be provided by developer and a public directory can be provided + will be linked in index if needed (like CRA)	custom index.html can't be specified. A synthetic index.html is generated for iframe compatibility
Styles	All imported CSS is bundled to a separate file and referenced in the app's index.html	Imported local CSS is built in a separate file and referenced in the style field of the output package manifest, for an host to load it. Imported external CSS can be rewritten to be loaded from CDN and possibly sandboxed or deduplicated (see CSS module scripts and constructable stylesheets).

Unify apps and ESM views

This RFC exists to see if it is feasible to unify upcoming ESM views and apps into a single modular type (exact type is TBD). Modular could decide to build an app as an ESM module if a particular environment variable is defined to a particular value (ie MODULAR_ESM_BUILD="true") or to a "regular", fully-bundled app otherwise. The biggest problem would be that existing apps can't be interchangeably built as ESM views and viceversa: while regular apps expose an entrypoint that renders a React component onto a DOM element, ESM views just expose a React component that can be imported at runtime and rendered as part of an existing React tree. This means that, as it stands now, it's not possible to build a regular app as an ESM view and viceversa: they're structurally different, unless the user somehow can select the entrypoint to build or we decide a fixed filename schema to differentiate between entry points. In more detail:

• JS: Both modes (ESM and regular) will work as expected when started or served statically. The main difference is that an app built in ESM mode will expose a dynamically loadable entrypoint with a default React component export, whose name is referenced in the module field of its dependency manifest, while a regular application won't have that. An external host application can look at the dependency manifest and decide whether to load an app as an ESM module or as an iframe by looking at the module field in dependency manifest (if empty -> must load as an iframe. If present, can import dynamically and add it to the react tree). We can also decide that all apps only export a React component and that a synthetic index.html + trampoline code is generated to ensure that regular and esm apps can be built from the same code, but that would change how regular apps are built and will need code changes from users (remove index.js, remove index.html). Other avenues to interchangeability are: letting the user specify which entrypoint to build or have a fixed filename schema (eg index.js is always the file that renders a component into a DOM element, while app.js is always the file which exports the root React component)
• Index: We can use the index.html where provided and generate a synthetic one when not provided. Obviously, regular apps that do things in their custom index (ie loading fonts) won't be interchangeable with ESM apps loaded dynamically.
• Styles: We can continue doing what we plan to do in both modes. CSS will work as expected when an app is served standalone, no matter in which mode it's built. ESM apps will additionally load external CSS from the CDN (instead of bundling it) and generate a style field in the output package manifest for an host application to import it at runtime, similar to what it does for the js entrypoint. We don't need any special measure because CSS is always bundled separately.