How typesafe can a remote be with Typescript? #20

echarles · 2020-05-04T17:48:03Z

Update from @ScriptedAlchemy - https://www.npmjs.com/package/@module-federation/typescript has been released

I can see a disadvantage using remotes libraries vs the classical libraries where e.g. typescript can be used to enforce strong types. The current typescript example defines a generic app2/Button which is similar defining a any type.

module-federation-examples/typescript/app1/src/app2.d.ts

Lines 3 to 7 in cf2d070

    
           declare module "app2/Button" { 
        
             const Button: React.ComponentType; 
        
             export default Button; 
        
           }

As the remote var does not have type, I don't see a way to benefit from the app2 types in app1. Any idea on this?

The text was updated successfully, but these errors were encountered:

echarles · 2020-05-04T19:34:50Z

@ScriptedAlchemy

saulshanabrook · 2020-05-05T11:45:57Z

I believe, in our case, we should be able to be fine with not having type checking for remote libraries. We can use shared libraries for extension authors import core libraries, so they don't need to be remote and dynamically imported.

echarles · 2020-05-05T15:59:45Z

I have tried a hacky way to benefit from type-safety importing the definition of the remote project (app2, here widgets) in the host project (app1). As shown on the below image, lazy returns the correct type and non acceptable props are underlined in red. I guess a solution would be to publish the types separately and a 3rd party could depend on those types.

ScriptedAlchemy · 2020-05-07T18:39:24Z

Or have a monorepo of types

maraisr · 2020-05-08T02:44:56Z

What I have done is use node to generate a .d.ts file, that are loaded by our global.d.ts file.

So each Remote outputs a .d.ts file that go declare module "dlaWidgets/Widets" {}, with using the ts.createProgram you can tap into the typeChecker stuff that i use to print its public api. Kinda like getting tsc to ouput definition files, but instead spit them into a single file.

Then each of my hosts import this .d.ts file, which I have registered in a global.d.ts, that all of my projectReferenced monorepo apps include.

So there is a small disconnect between a webpack config, and the types. But any exposed things, are automagically available with types in my entire app. So ts might say its a valid import, but just need to actially configure it with webpack also.

Working on open sourcing this generative thing - just gotta make sure it works in all use cases.

echarles · 2020-05-13T07:25:27Z

@maraisr your approach sounds very interesting. Keep us posted if you open source it.

ScriptedAlchemy · 2020-05-20T12:19:57Z

ill raise this with Microsoft - they will have to support federation since they are going to be using it heavily

echarles · 2020-05-20T12:54:48Z

ill raise this with Microsoft - they will have to support federation since they are going to be using it heavily

Awesome!

zhangwilling · 2020-05-21T07:43:37Z

mono repo is not recomended when our app is very large，independent repo is better.

💡We can watch and output independent repo's d.ts, then start a server which can make d.ts could be downloaded. When other apps need d.ts，just download it to your project from local server.

ckken · 2020-05-31T10:24:59Z

same issue and suggest like deno remote url type.d.ts

ScriptedAlchemy · 2020-05-31T12:23:32Z

I found some devs solving this by modifying TS loader. Specifically for module Federation

ckken · 2020-06-10T14:45:23Z

how to fix it

zhangwilling · 2020-06-11T02:38:58Z

i think it should be solved by IDE, such as vscode.

ScriptedAlchemy · 2020-06-11T23:50:49Z

yeah IDE can solve it, assuming it supports that. Meeting with Microsoft in august - seeking changes to TS to support MF, in doing so IDEs will have to follow the spec

ScriptedAlchemy · 2020-06-11T23:51:30Z

This remains a solution

What I have done is use node to generate a .d.ts file, that are loaded by our global.d.ts file.

So each Remote outputs a .d.ts file that go declare module "dlaWidgets/Widets" {}, with using the ts.createProgram you can tap into the typeChecker stuff that i use to print its public api. Kinda like getting tsc to ouput definition files, but instead spit them into a single file.

Then each of my hosts import this .d.ts file, which I have registered in a global.d.ts, that all of my projectReferenced monorepo apps include.

So there is a small disconnect between a webpack config, and the types. But any exposed things, are automagically available with types in my entire app. So ts might say its a valid import, but just need to actially configure it with webpack also.

Working on open sourcing this generative thing - just gotta make sure it works in all use cases.

glebmachine · 2020-06-14T14:53:29Z

@zhangwilling it's not a part of IDE, it's all about typechenking of typescript compiler itself

maraisr · 2020-06-14T23:54:40Z

I like the IDE idea @zhangwilling, but that will be more about aiding the development flow. However... I think this should still remain in the compiler itself, or a definition file that the compiler reads in. Personally feel its the latter.

If you solve to get the compiler to be aware of the remotes, then you don't have to worry about IDE, and specific IDE support as all IDE's will get this knowledge for free.

My solution outlined above still holds true. Its not terribly bad to implement. I'm hoping to get something open sourced soon.

Just wanting to get an idea from the community:

Are you using a monorepo?
Are your exposes objects exposed as standard javascript/typescript files? (Rather than inline in your webpack.config.js)
Are the request's standard node-esk requests, ie no @svgr/webpack!./icon.svg, where the request would firsts require a loader?

I've taken some assumptions to how I build software, but just wanting to get more scope so that this tool when released would solve issues for the majority.

zhangwilling · 2020-06-15T01:55:08Z

@zhangwilling it's not a part of IDE, it's all about typechenking of typescript compiler itself

@glebmachine yes, it is not part of IDE. Maybe TS can provide extra typing file config, but IDE plugin can do this, it could be improved much by IDE. Same as maven in IDEA, maven is not part of IDEA, but it does. Because it's a very important infrastrure.👻

zhangwilling · 2020-06-15T02:09:40Z

I like the IDE idea @zhangwilling, but that will be more about aiding the development flow. However... I think this should still remain in the compiler itself, or a definition file that the compiler reads in. Personally feel its the latter.

If you solve to get the compiler to be aware of the remotes, then you don't have to worry about IDE, and specific IDE support as all IDE's will get this knowledge for free.

My solution outlined above still holds true. Its not terribly bad to implement. I'm hoping to get something open sourced soon.

Just wanting to get an idea from the community:

Are you using a monorepo?

Are your exposes objects exposed as standard javascript/typescript files? (Rather than inline in your webpack.config.js)

Are the request's standard node-esk requests, ie no @svgr/webpack!./icon.svg, where the request would firsts require a loader?

I've taken some assumptions to how I build software, but just wanting to get more scope so that this tool when released would solve issues for the majority.

@maraisr
monorepo is not recommend when facing large project. so a large project would be seprated to many litttle repos by domain or module. But, we usually would put them together into same parent directory or we use worksapce in VSCode to oragnize them together logically 😈.

glebmachine · 2020-06-15T11:07:39Z

@zhangwilling yeah

But, typescript are trying to resolve imports. And fails when facing federation module import declaration. It looks like we have to be able to declare special federation modules right into tsconfig.json file or similar way.

For now, i'm workaround this with by loads file by document.createElement('script').

micmro · 2020-06-16T18:20:21Z

Depending on your use case/setup you could solve this by having a tsconfig.json in the project root and leverage path-mapping to resolve the apps entry points (Remote Name + Exposed module):

/tsconfig.json:

...
"paths": {
      "app1/Remote": ["./packages/app1/src/app"],
      "app2/Remote": ["./packages/app2/src/app"]
}
...

/packages/app1/tsconfig.json & /packages/app2/tsconfig.json:

{
  "extends": "../../tsconfig.json"
}

I've setup a little prototype using this setup: https://github.com/rangle/federated-modules-typescript

maraisr · 2020-06-17T01:09:23Z

You got to be careful with that approach though. It does mean that you cannot also use path mappings for other things in your app, because if you are you're probably also using tsconfig paths webpack resolver, in which case module federation plugin can't "remote" those. You can but you'd have to have a special build-time tsconfig that excludes the MF mappings.

micmro · 2020-06-17T01:34:44Z

Thanks @maraisr , that is a very good point I had not considered.
I suppose then it is a trade-off of manual remote interface vs potential manual MF path-mapping overwrites.

doerme · 2020-06-29T07:54:29Z

1.webpack provide a template for the "d.ts" module building
2.webpack config decare the use of remote "d.ts" module
3.IDE support using static inspection for the second point

ScriptedAlchemy · 2022-05-09T05:47:10Z

We have released a Federated Types Plugin beta.

Theres some gaps in the type def bundling, we are aware of it and working on improvements.

https://app.privjs.com/buy/packageDetail?pkg=@module-federation/typescript

malopgrics · 2022-05-09T12:19:14Z

We have released a Federated Types Plugin beta.

Theres some gaps in the type def bundling, we are aware of it and working on improvements.

https://app.privjs.com/buy/packageDetail?pkg=@module-federation/typescript

It looks promising. Is there a plan to open source it in regular npm ?

ScriptedAlchemy · 2022-05-27T06:15:07Z

We have released a Federated Types Plugin beta.

Theres some gaps in the type def bundling, we are aware of it and working on improvements.

https://app.privjs.com/buy/packageDetail?pkg=@module-federation/typescript

It looks promising. Is there a plan to open source it in regular npm ?

Not currently, I generally only publish OSS to npm. Closed source, even if it's free, usually stays on priv

Perhaps in the future depending on data & feedback during beta & RC phases

steven-prybylynskyi · 2022-06-12T10:51:59Z

Hey @ScriptedAlchemy, I'm glad there's finally a solution emerging to share Typescript definitions among microfrontends from the author, despite of saying that I'm not a TS user so I'm no help here.!

I was trying other solutions like @touk/federated-types that reads a federation.config.json and generates types in node_modules@types__federated_types

It does that for local modules but does not collect types for modules that are exposed from node_modules.

Our federation.config.json config looks like this:

{
  "name": "commonLibs",
  "exposes": {
    "./AxiosHttp": "./src/api-services/axios-client/index",
    ...
    "./@cloudbeds/ui-library": "@cloudbeds/ui-library",
    "./react": "react",
    "./react-dom": "react-dom",
    "./react-query": "react-query",
    "./react-router-dom": "react-router-dom"
  }
}

Everything after ... is from node_modules and we want that to be part of commonLibs microfrontend so that will consume a single version of these without even installing react in consuming app's package.json, e.g.

import react from 'commonLibs/react';

Coupled with webpack-remote-types-plugin we could have updated types without uploading them to S3 or publishing to NPM. Unfortunately that doesn’t work with Dynamic remotes - it needs an actual URL from which the remote is served from. We use external-remotes-plugin and uses a dynamic variable name, e.g. [window.commonLibs] instead of localhost:4242

Here's a screen of the error we are experiencing:

steven-prybylynskyi · 2022-06-12T10:52:11Z

Now we are trying to achieve that with Federated Types Plugin beta.

It would be really great if the closed source plugin would have an official place to open issues. Probably this thread is currently serves this purpose

steven-prybylynskyi · 2022-06-12T10:54:42Z

@module-federation/typescript creates types in dist/@mf-typescript

The __types_index.json file contains list of type definition files for all exposed modules, here it's:

[
  "index.d.ts",
  "index.d.ts",
  "index.d.ts",
  "index.d.ts",
  "ui-library.d.ts",
  "react.d.ts",
  "react-dom.d.ts",
  "react-query.d.ts",
  "react-router-dom.d.ts"
]

Although it lists packages in node_modules, e.g. react.d.ts and ui-library.d.ts they are not included in dist/@mf-typescript

Also it would be great if that file's purpose would be documented here

steven-prybylynskyi · 2022-06-12T11:10:37Z

Compared to @touk/federated-types, instead of a single file with all types, @module-federation/typescript recreates the directory structure which is neat.

There's one serious issue with @module-federation/typescript plugin is that the types cannot be used for microfrontends that are served from production environment (unless we don't know something). E.g. imagine there are 10 federated apps

shell - served with webpack-dev-server from localhost:4242
commonLibs - from localhost:4243
wmf3 - from https://production.com/wmf3
wmf4 - from https://production.com/wmf4
...

Some are served with webpack-dev-server, others from production (e.g. CDN, AWS Cloudfront, etc.). For these we would like to publish an npm package with types.

It doesn't look like @module-federation/typescript has any configuration.

@ScriptedAlchemy are there any hidden options that we could provide to generate types that are usable when published as an NPM package and includes types for modules that expose node_modules? If not, would it be possible to extend the plugin to accommodate for those use-cases?

steven-prybylynskyi · 2022-06-12T11:30:29Z

Also it suffers from the issue with dynamic imports

Even though here are examples in advanced-api and the dynamic System Host. So it's not something unusual to do.

We use the module-federation/external-remotes-plugin to achieve this

Also the Practical Module Federation has an example of Dynamically Loading Federated Modules for Webpack 4 and 5.

@ScriptedAlchemy how we can use the plugin in such environment?

Looks like module-federation/external-remotes-plugin and @module-federation/typescript are currently incompatible

steven-prybylynskyi · 2022-06-12T11:40:24Z

I've changed the URL to be localhost in remotes section and now we're getting this 404 error for exposed npm package

\node_modules\got\index.js:482
     proxy.emit('error', new got.HTTPError(statusCode, res.statusMessage, res.headers, opts), null, res);
    ^
GotError [HTTPError]: Response code 404 (Not Found)

  path: '/@mf-typescript/ui-library.d.ts',
  protocol: 'http:',
  url: 'http://localhost:9082/@mf-typescript/ui-library.d.ts',
  statusCode: 404,
  statusMessage: 'Not Found',

steven-prybylynskyi · 2022-06-12T11:43:32Z

Sorry for the numerous comments, I wish it can be hosted on Github, with Issues/Discussion tabs
It can be an empty repo with a README only.

MR-BH · 2022-07-08T02:42:48Z

We have released a Federated Types Plugin beta.

Theres some gaps in the type def bundling, we are aware of it and working on improvements.

https://app.privjs.com/buy/packageDetail?pkg=@module-federation/typescript

I want to contribute to the repo, is there any way I can join the work? Wait for your reply. @ScriptedAlchemy

anthonycaron · 2022-08-12T08:57:40Z

I don't know if this was already mentioned in this thread but there are some nice solutions exposed in this blog post: https://spin.atomicobject.com/2022/07/19/typescript-federated-modules/

steven-prybylynskyi · 2022-08-17T11:16:59Z

For anyone interested, at Cloudbeds, we've released a public NPM package that was built on top of existing solutions

https://www.npmjs.com/package/@cloudbeds/webpack-module-federation-types-plugin

It's also planned to open source it on Github

gauravmakkar · 2022-08-22T12:29:05Z

@ScriptedAlchemy Any plan to add typescript support in federated modules?

ScriptedAlchemy · 2022-08-27T04:31:10Z

Already done. App.privjs.com search for module-federation/typescript

We did this months ago

ScriptedAlchemy · 2022-08-29T02:22:43Z

https://www.npmjs.com/package/@module-federation/typescript

vmagalhaes · 2022-08-29T16:33:30Z

I'm searching for a solution with Angular using the new typescript package. I tried to use it but with no success.
But great initiative @ScriptedAlchemy

steven-prybylynskyi · 2022-08-29T20:38:34Z

The @cloudbeds/webpack-module-federation-types-plugin is now available on Github. Feel free to use Issues or Discussions tabs.

And let me thank @ScriptedAlchemy for the awesome Module Federation plugin upon which a lot of projects nowadays started to rely on. I hope that some day there won't be a need for a 3rd party plugin to deal with types and there'll be a standard documented way built into Webpack.next

ScriptedAlchemy · 2022-08-29T20:59:03Z

If we can merge or open PRs to module-federation/typescript to improve the "official" plugin that would be great.
We open-sourced it to try and get more input and help since i dont write TS
I just know webpack very well haha

stefan-toubia · 2022-08-29T21:19:41Z

@ScriptedAlchemy can you link the github repo?

vadym-oliinyk · 2022-08-30T08:24:59Z

@ScriptedAlchemy can you link the github repo?

I suppose https://github.com/module-federation/typescript

ScriptedAlchemy · 2022-09-09T05:54:02Z

thats the one, PR's welcome

sudheerkumar-golla · 2023-06-26T19:20:21Z

Hey @ScriptedAlchemy, I'm glad there's finally a solution emerging to share Typescript definitions among microfrontends from the author, despite of saying that I'm not a TS user so I'm no help here.!

I was trying other solutions like @touk/federated-types that reads a federation.config.json and generates types in node_modules@types__federated_types

It does that for local modules but does not collect types for modules that are exposed from node_modules.

Our federation.config.json config looks like this:
{
  "name": "commonLibs",
  "exposes": {
    "./AxiosHttp": "./src/api-services/axios-client/index",
    ...
    "./@cloudbeds/ui-library": "@cloudbeds/ui-library",
    "./react": "react",
    "./react-dom": "react-dom",
    "./react-query": "react-query",
    "./react-router-dom": "react-router-dom"
  }
}
Everything after ... is from node_modules and we want that to be part of commonLibs microfrontend so that will consume a single version of these without even installing react in consuming app's package.json, e.g.
import react from 'commonLibs/react';
Coupled with webpack-remote-types-plugin we could have updated types without uploading them to S3 or publishing to NPM. Unfortunately that doesn’t work with Dynamic remotes - it needs an actual URL from which the remote is served from. We use external-remotes-plugin and uses a dynamic variable name, e.g. [window.commonLibs] instead of localhost:4242

Here's a screen of the error we are experiencing:

Hi @steven-prybylynskyi , Could you please suggest me the package you have used to build types for modules exposed from node_modules(eg: react).

ilteoood · 2023-06-26T20:58:26Z

Hey @ScriptedAlchemy, I'm glad there's finally a solution emerging to share Typescript definitions among microfrontends from the author, despite of saying that I'm not a TS user so I'm no help here.!
I was trying other solutions like @touk/federated-types that reads a federation.config.json and generates types in node_modules@types__federated_types
It does that for local modules but does not collect types for modules that are exposed from node_modules.
Our federation.config.json config looks like this:
{
  "name": "commonLibs",
  "exposes": {
    "./AxiosHttp": "./src/api-services/axios-client/index",
    ...
    "./@cloudbeds/ui-library": "@cloudbeds/ui-library",
    "./react": "react",
    "./react-dom": "react-dom",
    "./react-query": "react-query",
    "./react-router-dom": "react-router-dom"
  }
}
Everything after ... is from node_modules and we want that to be part of commonLibs microfrontend so that will consume a single version of these without even installing react in consuming app's package.json, e.g.
import react from 'commonLibs/react';
Coupled with webpack-remote-types-plugin we could have updated types without uploading them to S3 or publishing to NPM. Unfortunately that doesn’t work with Dynamic remotes - it needs an actual URL from which the remote is served from. We use external-remotes-plugin and uses a dynamic variable name, e.g. [window.commonLibs] instead of localhost:4242
Here's a screen of the error we are experiencing:
Hi @steven-prybylynskyi , Could you please suggest me the package you have used to build types for modules exposed from node_modules(eg: react).

https://github.com/module-federation/universe/tree/main/packages/native-federation-typescript

ScriptedAlchemy · 2023-08-26T08:24:42Z

Typescript support will be implemented as a built-in capability in the coming iteration of module federation. Colloquially known as "v1.5"

You will see this in https://modernjs.dev as well

ScriptedAlchemy · 2024-01-10T23:10:57Z

Type Hint Support Tracking: module-federation/core#1943

saulshanabrook mentioned this issue May 5, 2020

Extension Development Wishlist jupyterlab/jupyterlab#7468

Closed

echarles changed the title ~~How typesafe can a remote be?~~ How typesafe can a remote be with Typescript? May 5, 2020

ScriptedAlchemy pinned this issue May 12, 2020

maraisr self-assigned this May 14, 2020

ScriptedAlchemy added the question Further information is requested label May 20, 2020

zhangwilling mentioned this issue Jun 22, 2020

Merge Proposal: Module federation and code sharing between bundles. Many builds act as one webpack/webpack#10352

Closed

velvetkevorkian mentioned this issue Apr 20, 2022

Define correct type for federated components Ensono/Amido.Ecommerce.UI.Federated#91

Open

kahboom mentioned this issue Jul 29, 2022

Sharing state outside of monorepo jherr/module-federation-state-management#1

Closed

ScriptedAlchemy closed this as completed Sep 9, 2022

YoujeongPark mentioned this issue Mar 12, 2023

13 feature state management recoil 14-team13/acoe-frontend#25

Merged

How typesafe can a remote be with Typescript? #20

How typesafe can a remote be with Typescript? #20

Comments

echarles commented May 4, 2020 • edited by ScriptedAlchemy

echarles commented May 4, 2020

saulshanabrook commented May 5, 2020 • edited

echarles commented May 5, 2020

ScriptedAlchemy commented May 7, 2020

maraisr commented May 8, 2020

echarles commented May 13, 2020

ScriptedAlchemy commented May 20, 2020

echarles commented May 20, 2020

zhangwilling commented May 21, 2020 • edited

ckken commented May 31, 2020

ScriptedAlchemy commented May 31, 2020

ckken commented Jun 10, 2020

zhangwilling commented Jun 11, 2020

ScriptedAlchemy commented Jun 11, 2020

ScriptedAlchemy commented Jun 11, 2020

glebmachine commented Jun 14, 2020

maraisr commented Jun 14, 2020 • edited

zhangwilling commented Jun 15, 2020 • edited

zhangwilling commented Jun 15, 2020

glebmachine commented Jun 15, 2020

micmro commented Jun 16, 2020

maraisr commented Jun 17, 2020

micmro commented Jun 17, 2020

doerme commented Jun 29, 2020

ScriptedAlchemy commented May 9, 2022 • edited

malopgrics commented May 9, 2022

ScriptedAlchemy commented May 27, 2022

steven-prybylynskyi commented Jun 12, 2022 • edited

steven-prybylynskyi commented Jun 12, 2022

steven-prybylynskyi commented Jun 12, 2022

steven-prybylynskyi commented Jun 12, 2022

steven-prybylynskyi commented Jun 12, 2022 • edited

steven-prybylynskyi commented Jun 12, 2022 • edited

steven-prybylynskyi commented Jun 12, 2022 • edited

MR-BH commented Jul 8, 2022

anthonycaron commented Aug 12, 2022

steven-prybylynskyi commented Aug 17, 2022

gauravmakkar commented Aug 22, 2022

ScriptedAlchemy commented Aug 27, 2022

ScriptedAlchemy commented Aug 29, 2022

vmagalhaes commented Aug 29, 2022 • edited

steven-prybylynskyi commented Aug 29, 2022

ScriptedAlchemy commented Aug 29, 2022

stefan-toubia commented Aug 29, 2022

vadym-oliinyk commented Aug 30, 2022

ScriptedAlchemy commented Sep 9, 2022

sudheerkumar-golla commented Jun 26, 2023

ilteoood commented Jun 26, 2023

ScriptedAlchemy commented Aug 26, 2023 • edited

ScriptedAlchemy commented Jan 10, 2024

echarles commented May 4, 2020 •

edited by ScriptedAlchemy

saulshanabrook commented May 5, 2020 •

edited

zhangwilling commented May 21, 2020 •

edited

maraisr commented Jun 14, 2020 •

edited

zhangwilling commented Jun 15, 2020 •

edited

ScriptedAlchemy commented May 9, 2022 •

edited

steven-prybylynskyi commented Jun 12, 2022 •

edited

steven-prybylynskyi commented Jun 12, 2022 •

edited

steven-prybylynskyi commented Jun 12, 2022 •

edited

steven-prybylynskyi commented Jun 12, 2022 •

edited

vmagalhaes commented Aug 29, 2022 •

edited

ScriptedAlchemy commented Aug 26, 2023 •

edited