Skip to content
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

Change the webpack hook to use async tapPromises #9

Open
hekatonylomax opened this issue Sep 2, 2021 · 5 comments
Open

Change the webpack hook to use async tapPromises #9

hekatonylomax opened this issue Sep 2, 2021 · 5 comments

Comments

@hekatonylomax
Copy link
Contributor

Hey, thanks for producing this plugin. I've noticed that there was an issue with the unzipping of the tar file not finishing before we tried to access the remote components, as such the imports were failing.

I can create a PR to use a different async webpack hook that appears to solve the issue. We want to change
compiler.hooks.afterPlugins.tap to compiler.hooks.beforeRun.tapPromise

What do you think?

@denis-heka
Copy link

Just to add a bit more info to this issue. This snippet of code below doesn't await for the download & unzipping. We've noticed it recently since our webpack builds have been failing unreliably due to a lack of remote typing. This issue is coming up very often now, perhaps because our zipped file is getting larger.

compiler.hooks.afterPlugins.tap('WebpackRemoteTypesPlugin', () => {
            return downloadFederationTypes(this.options.remotes, path_1.default.resolve(cwd, this.options.outputDir), this.options.remoteFileName);
});

The afterPlugins hook doesn't appear to be able to handle async https://webpack.js.org/api/compiler-hooks/#afterplugins.
The earliest hook in the lifecycle that can appears to be beforeRun.

@denis-heka
Copy link

@ruanyl This PR fixed the webpack build process errors we were having. But the plugin no longer triggers when in development/using webpack devServer. Perhaps the beforeRun hook doesn't execute when in dev mode? It looks like this is the case based on this ticket.

It's not documented well, but I've tried quite a few hooks. I think we need to run the plugin on two hooks: "run" and "watchRun".
I've tested it locally and seems to work for both use cases.
I also tried using a single async hooks ( ones further downstream in the lifecycle), they ran multiple times, causing multiple downloads per build/devServer running.

Going to put a PR in now for a fix.

denis-heka added a commit to denis-heka/webpack-remote-types-plugin that referenced this issue Sep 3, 2021
@ruanyl
Copy link
Owner

ruanyl commented Sep 3, 2021

@denis-heka Thanks for investigating this. I'm a bit concern that if people want the download to be triggered on every rebuild when running with --watch mode or with dev server. Especially when there were multiple remotes, these downloads are probably too much.

@denis-heka
Copy link

denis-heka commented Sep 6, 2021

@ruanyl Yep fair point, I'll decline my PR. Right now, myself and team need to build locally to get the types, which is a bit unintuitive. I can only think of one way to properly move forward with this:

  • Instead of downloading it fresh every time, doing some kind of hashcheck. This would require updating dts-loader to create a hash of the remote-types. webpack-remote-types-plugin would then be able to version check before deciding to download.

Happy to have a crack at solving this if you think it is a decent solution?

Also, I'm new to webpack plugins & loaders. How do you test both of these libraries? I've been editing them in node_modules until they work, there must be a better way?

@JulianWielga
Copy link
Contributor

in my case most time I run projects with "start", in dev only, so I don't like do be forced to build before start. please take a look: #12

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants