[RFC][Proposal] Add an optional field for type definitions

[ruanyl]

Summary

This proposals intent is to provide a field called types to hold the URL to the Typescript type definitions of the micro-frontend modules/applications to enable further integrations with various tools to offer type safety at different stages of the software development.

Motivation

A micro-frontend(MF) module/application could expose interface for 3rd parties to consume, such as component interface, module exports, etc. Introducing breaking changes to the interfaces could be a big challenge if the MF modules/applications are shared by different teams/organizations. It requires extra communication and testing efforts.

Design

An optional field types will be added to the current schema which is the URL to the generated type definitions of the MF modules/applications.

Example:

{
  "schema": "https://mfewg.org/schema/v1-pre.json",
  "microFrontends": {
    "@my-project/myaccount": [
      {
        "url": "https://static.website.com/my-account-1.2.2.js",
        "fallbackUrl": "https://alt-cdn.com/my-account-1.2.2.js",
+       "types": "https://static.website.com/my-account-types.1.2.2.tgz",
        "metadata": {
          "integrity": "e0d123e5f316bef78bfdf5a008837577",
          "version": "1.2.2"
        },
        "deployment": {
          "traffic": 30,
          "default": false
        }
      },
      {
        "url": "https://static.website.com/my-account-2.0.0.js",
        "fallbackUrl": "https://alt-cdn.com/my-account-2.0.0.js",
+       "types": "https://static.website.com/my-account-types.2.0.0.tgz",
        "metadata": {
          "integrity": "e0d123e5f316bef78bfdf5a008837577",
          "version": "2.0.0"
        },
        "deployment": {
          "traffic": 70,
          "default": true
        }
      }
    ]
  }
}

Use cases

Used by code editor plugins

With such plugin, code editor will download the type definition automatically. This offers a better developer experience on MF modules/applications, such as code completion, type checking at development time.

Used by build tools

Build tools such as webpack, esbuild can download the type definition with plugins and type-checking it before bundling and publishing the application. This makes it easy to reveal problems at build time instead of runtime.

[lucamezzalira]

Hi @ruanyl thanks for taking the time and opening a RFC :)

Considering the schema would be available not only for typescript but also for vanilla javascript, do you think that having the types field in the extras field that currently is available inside the first version of the schema would be enough?

...
"extras": {
    "types": "https://static.website.com/my-account-types.2.0.0.tgz",
}
...

what do you think?

[ruanyl]

@lucamezzalira Thanks for the feedback! Right, your suggestion is the same as what I initial thought. But do you think if it makes sense to make it more "standardized"?

Because for extras, user can put arbitrary contents, and they will decide how to use it. For example, for use cases such as code editor plugins and build tool plugins, a universally applicable schema configuration for types maybe easier for the community to embrace the schema.