-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How typesafe can a remote be with Typescript? #20
Comments
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. |
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. |
Or have a monorepo of types |
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 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. |
@maraisr your approach sounds very interesting. Keep us posted if you open source it. |
ill raise this with Microsoft - they will have to support federation since they are going to be using it heavily |
Awesome! |
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. |
same issue and suggest like deno remote url type.d.ts |
I found some devs solving this by modifying TS loader. Specifically for module Federation |
how to fix it |
i think it should be solved by IDE, such as vscode. |
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 |
This remains a solution
|
@zhangwilling it's not a part of IDE, it's all about typechenking of typescript compiler itself |
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:
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. |
@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.👻 |
@maraisr |
@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 For now, i'm workaround this with by loads file by |
Depending on your use case/setup you could solve this by having a
I've setup a little prototype using this setup: https://github.com/rangle/federated-modules-typescript |
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. |
Thanks @maraisr , that is a very good point I had not considered. |
1.webpack provide a template for the "d.ts" module building |
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 |
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 It does that for local modules but does not collect types for modules that are exposed from Our {
"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
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. Here's a screen of the error we are experiencing: |
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 |
@module-federation/typescript creates types in The
Although it lists packages in Also it would be great if that file's purpose would be documented here |
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
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 @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 |
Also it suffers from the issue with dynamic imports Even though here are examples in advanced-api and the dynamic 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 |
I've changed the URL to be
|
Sorry for the numerous comments, I wish it can be hosted on Github, with Issues/Discussion tabs |
I want to contribute to the repo, is there any way I can join the work? Wait for your reply. @ScriptedAlchemy |
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/ |
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 |
@ScriptedAlchemy Any plan to add typescript support in federated modules? |
Already done. App.privjs.com search for module-federation/typescript We did this months ago |
I'm searching for a solution with Angular using the new typescript package. I tried to use it but with no success. |
The 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 |
If we can merge or open PRs to module-federation/typescript to improve the "official" plugin that would be great. |
@ScriptedAlchemy can you link the github repo? |
|
thats the one, PR's welcome |
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 |
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 |
Type Hint Support Tracking: module-federation/core#1943 |
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 aany
type.module-federation-examples/typescript/app1/src/app2.d.ts
Lines 3 to 7 in cf2d070
As the remote var does not have type, I don't see a way to benefit from the
app2
types inapp1
. Any idea on this?The text was updated successfully, but these errors were encountered: