-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
Webpack 5 support #166
Comments
I wrote the Webpack 3 and 4 versions of the plugin but unfortunately I don't have time to upgrade it to 5 at the moment. I might do it later on when I'm less stressed, although if someone wants to submit a PR that fixes APIs that have changed in Webpack 4 you're welcome. A few things that come to my mind right now:
|
That's mostly correct. Conventions do rely on a thin layer of tooling, but without conventions you don't have to do anything and Aurelia 2 will indeed work OOTB with any bundler including webpack 5. However, since conventions in au2 is just a simple pre-processing step that adds decorators, I don't imagine much (if any) difficulty at all in supporting that. On the note of au2, we are getting close to alpha. Is upgrading to au2 something you'd be interested in on the short to mid term as an alternative, or are there strong reasons to stick to au1 for some time to come? |
Yeah this could be a simple webpack loader. Au1 needed complex stuff to inform webpack of the dependency graph + ensuring everything would be properly available to
I'm assuming this question was for OP. |
Thanks for your responses! For our Micro Frontends we could (and should) definitively go for au2 right away if its production ready. When it comes to our monolith au1 apps I cant really say. Some of our teams might upgrade right away and others move more slowly. Perhaps we can find a way to make Module Federation work nicely between Micro Frontends even if they are hosted in an au1 app bundled with webpack 4. Got any examples of an au2 app bundled with webpack? |
As one of the core maintainers of webpack and the creator of module federation. I'm willing to work with project authors if you need me |
Happy to hear that @ScriptedAlchemy, and great job on the Module Federation. We're very excited about it! The compatibility issue in a nutshell: Aurelia version 1 is built on top of a requirejs-based loader architecture that stems from before ES Modules were standardized. Unless you're aware of any specific concerns off the top of your head, I think we're mostly looking at simply try to upgrade to webpack 5 and see what breaking changes we need to address and take it from there. If @jods4 is too busy I can have a crack at it later this week.
Scattered around at the moment. I would recommend to wait for alpha announcement (within a few weeks), which will come with significantly more docs and examples than we currently have. |
It doesn't work at the syntax level.
|
I see, that sounds like it might be a bit more work then.
But those are AST transforms right? Or at least that's what they are in the au2 conventions plugin, so if they currently aren't, maybe we can simplify things a bit by doing so, if that makes sense? |
Not really. Because the "things" are not loaded directly in code with an This was one of the main driver for design changes in Au2, I'm afraid we did the best we could to retrofit Au1 design into the webpack era. |
What about dynamic import era? AFAIK this plugin was implemented way before that was available, but now it so happens to be that interface LoaderPlugin {
fetch(address: string): Promise<any>;
} Dynamic imports is something webpack understands OOTB. Has that by any chance been looked into? |
If you do everything with dynamic imports you probably won't need this plugin and can go with vanilla Webpack (it was the goal at least). We can't expect all our users to migrate their codebase to that new syntax. I know I won't. |
I think I wasn't clear in what I meant, sorry. I mean that we use the new syntax on our side in some fashion. For example, by doing an AST transform from |
I see. Let's say I have this module in my project: export const route = { name: 'home', module: moduleName('./home.ts') };
export class HomeViewModel { } You'd need to figure out in what Aurelia API the
|
You're right. The transform suggestion must have been a brainfart moment on my part, for some reason I thought of it as a string-to-promise function but of course it's just string-to-string and has nothing to do with imports. My bad. My original thought was an implementation of So to come back to the complexity problem of doing the transformation that you thought I meant just now - we might be able to do what with v2's AOT once it's done, because that's built as a more or less fully fledged ESNext runtime that evaluates everything that's reachable (it bails only at things like In the mean time, the quickest way for us to achieve this webpack interop is probably to add If that's acceptable then we don't need to touch the v1 webpack plugin beyond ensuring general v5 api compatibility. Of course we can try to look at module federation specifically, but I'm worried we might be opening a can of worms of something that seems fine in the beginning but issues keep popping up. Going native-compatible really feels like the safer bet. Eventually we can pull v1 along with the more advanced AOT tooling of v2, but again, that's at least several months away. It's all about what we can offer in the mean time and make the right trade-offs. |
For our sake there's no rush to make this work with v1. If we can be rest assured there will be support for webpack 5 and module federation for v2 we can continue evaluating the technology to see if it's a good fit for our micro frontend challanges. |
I'm a little busy right now but I want to bring the plugin to Webpack 5. @fkleuver A key goal of v2 should be to get rid of aurelia-loader and instead rely on |
@jods4 Yes, v2 has been aurelia-loader-free from the get-go. We only have a thin (optional) transform layer to apply conventions, and all that does is add the The AOT I'm talking about is primarily for build-time optimizations and a few minor quality-of-life improvements, such as making autoinject work with interfaces as well instead of just classes. No crazy hacks there in order to make v2 work in the first place, just optional stuff to further improve things. |
Implementation of MF has been pretty easy with other OSS upgrades so far. So I’d imagine leveraging it will be fine as long as you can run WP5 :) |
Hi there, |
@luboid I don't think externals require support from this plugin.
|
It will be something needed in the Micro Frontend world. When you have a shell (Aurelia app) that loads different modules (Micro Frontends) as Web Components (Aurelia), here can be used also IFrame to load the standalone app (for isolation and unload code). This is one of the possible ways to achieve the Micro Frontend pattern. And you want to share resources between them with browser cache. Shareable resources (like Aurelia runtime, etc) can be placed JS Libs, by this you can easily fix bugs in vendor's things and vise versa. The application can be left only with the module (App) domain logic code. We now have around 26 modules on DurandalJS, every one of them comprises one bundle for Durandal itself, one bundle for the module (App) and other major libs are loaded on demand by RequireJS, when a module needs them. And that is wrapped around with Shell. |
@luboid I think what you want can be achieved by a combination of Webpack exposing Aurelia core modules & provide plugin to alias to those globals in the micro apps |
@bigopon yes, I think that is the point of WebPack Externals to alias global libs (umd, etc), more interesting is that they have some experimental feature to load them async, however. "Webpack exposing Aurelia" I think this needs to be a most likely builder which to pack Aurelia core modules or to inspect some projects and to build intersect between them, I don't know. |
@luboid Bundling "other major libs" as externals should work without problems. Some alternative APIs that are more bundler-friendly were introduced at some point, which may help getting this to work if you tweak your app to use the new APIs. I am not sure if this was properly documented, @bigopon do you have any pointers? Given the current focus on Aurelia 2, which is built from the scratch to be bundler-friendly, I think it's unlikely that the runtime capabilities of Aurelia 1 change significantly at this point. |
@jods4 Then I will be waiting to see what will come with Aurelia 2 I'm not sure that I'm clear, because of that I will post one link, go and see Step 6: Sharing Libraries Between Micro Frontends |
When should Aurelia v2 come? |
PR: #169 |
@bigopon Not to rush you, but do you have enough info to make a rough estimation of when this could be ready? |
Cant really give any update yet atm. Im atively looking into it. Maybe in a few days ill give an update of what the changes could be. Also will publish something that can be tested as soon as I can Update 1: I'm reading the webpack v5 source code & debugging the webpack v4 with our plugin to see what changes are needed. Have been able to understand more but still not enough to refactor the plugin. I'm positive still 🤞 |
@bigopon, again, we really appreciate this. Could you give any insights into your findings, and if we can help in any way? Cheers |
I'm swapping pieces of our impl with the equivalence in v5. Will come to |
Here is my current draft for the needed changes: #170. I've listed work needed for all the plugins in 3 simple parts for now: typings & code & comments. Overtime, more details will be filled in. Will update my progress there as I continue the refactoring. |
An update: With fdae3aa, it now can build correctly with normal usages.
What left to be tested:
cc @jods4 |
The work can be tested by installing the plugin from the branch in that PR, the dist files have been built, can be used directly. |
Nice work! I ran a quick test with fdae3aa and webpack 5 on one of our smaller apps (routing but no chunks) and got everything working fine. Will give it a go with a more complex app soon. |
@mlassbo thanks. With the latest commit. It should be able to cover all range of usages now, at least I hope so. Will merge and do a beta release soon. |
Thanks for your great work, @bigopon! Looks like the aurelia-bootstrapper package is not yet compatible with webpack 5:
If I analyzed correctly, "process.browser" is no longer available in webpack 5, that's why aurelia-pal-nodejs is tried to be loaded instead of aurelia-pal-browser. :( |
@elitastic did you get this issue on a plain new project, or an existing one? |
I’ve had the same error when tried to remove aurelia plugin completely. Webpack recognises “.require()” string suddenly and tries to bundle nodejs package |
It's an existing project. Two further, perhaps relevant disclosures:
Could this be a problem? |
@elitastic the reason is webpack trying to bundle nodejs package. Olds aurelia plug-in does something to suppress that |
Thank you for your quick and good help! I could solve it by explicitly providing "target: 'web'" in webpack config. (I call webpack over gulp, perhaps that leads into some confusion between node and web...) It builds successfully now, unfortunately I get the following runtime error now:
This is for my root component, which is wrapped withing a template tag (was working with previous aurelia webpack plugin). Do you have an idea? Sorry for bothering you! :/ |
@elitastic no problem at all. Thanks for the issue, it helps fix the error in advance, before others hit it 👍
|
Also, I think we should open a new issue, so that we can avoid spamming others, as the support for v5 is already in. This is more like a bug. |
Are we far away from a 5.0.0-beta1 or 5.0.0-rc1 release here? |
@bigopon Thank you very much for your hard work! This enables us to upgrade our dependencies again! I hope Aurelia will be around for a very long time in the future! |
@bigopon Great to see the progress here - it's much appreciated! |
@thomas-darling it's been fixed. |
Is there a RC or Beta version? |
@EisenbergEffect will do a release soon. Please use master for now if possible |
@bigopon You're the best! Thanks a million! |
When can we expect a release (alpha, beta, rc)? |
I'm submitting a feature request
Add support for Webpack 5.
We (at Hogia Group) need to start preparing our Aurelia apps for Webpack 5. It is in beta but Webpack reccommends to use it for production. Also, Webpack 5 comes with Module Federation that might become an important part of building micro frontends using Aurelia and we need aurelia-webpack-plugin to support webpack 5 to be able to evaluate this properly. I've been in contact with webpack core member Zack Jackson @ScriptedAlchemy, the creator of Module Federation, about this and he has offered his help with the upgrade if needed.
aurelia-webpack-plugin 4.0.0
Please tell us about your environment:
Operating System:
Windows 10
Node Version:
12.16.0
NPM Version:
6.13.4
JSPM OR Webpack AND Version
webpack 5.0.0-beta.17
Browser:
all
Language:
all
Current behavior:
When upgrading to webpack 5 beta 17 build fails with the following error:
Error: Cannot find module 'webpack/lib/BasicEvaluatedExpression'
Require stack:
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:981:15)
at Function.Module._load (internal/modules/cjs/loader.js:863:27)
at Module.require (internal/modules/cjs/loader.js:1043:19)
at require (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:161:20)
at Object. (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\aurelia-webpack-plugin\dist\AureliaDependenciesPlugin.js:4:34)
at Module._compile (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:192:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1177:10)
at Module.load (internal/modules/cjs/loader.js:1001:32)
at Function.Module._load (internal/modules/cjs/loader.js:900:14)
at Module.require (internal/modules/cjs/loader.js:1043:19)
at require (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:161:20)
at Object. (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\aurelia-webpack-plugin\dist\AureliaPlugin.js:4:37)
at Module._compile (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:192:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1177:10)
at Module.load (internal/modules/cjs/loader.js:1001:32)
at Function.Module._load (internal/modules/cjs/loader.js:900:14)
at Module.require (internal/modules/cjs/loader.js:1043:19)
at require (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:161:20)
at Object. (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\aurelia-webpack-plugin\dist\index.js:6:10)
at Module._compile (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:192:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1177:10)
at Module.load (internal/modules/cjs/loader.js:1001:32)
at Function.Module._load (internal/modules/cjs/loader.js:900:14)
at Module.require (internal/modules/cjs/loader.js:1043:19)
at require (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:161:20)
at Object. (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\webpack.config.js:2:27)
at Module._compile (C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\v8-compile-cache\v8-compile-cache.js:192:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1177:10)
at Module.load (internal/modules/cjs/loader.js:1001:32)
at Function.Module._load (internal/modules/cjs/loader.js:900:14) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\aurelia-webpack-plugin\dist\AureliaDependenciesPlugin.js',
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\aurelia-webpack-plugin\dist\AureliaPlugin.js',
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\aurelia-webpack-plugin\dist\index.js',
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\webpack.config.js',
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\webpack-cli\bin\utils\convert-argv.js',
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\webpack-cli\bin\cli.js',
'C:\repos\TEMPLATE_WebComponent_InProgress\Api\Web\App\node_modules\webpack\bin\webpack.js'
]
}
Expected/desired behavior:
Build runs without errors
We (at Hogia Group) need to start preparing our Aurelia apps for Webpack 5. It is in beta but Webpack reccommends to use it for production. Also, Webpack 5 comes with Module Federation that might become an important part of building micro frontends using Aurelia and we need aurelia-webpack-plugin to support webpack 5 to be able to evaluate this properly. I've been in contact with webpack core member Zack Jackson @ScriptedAlchemy, the creator of Module Federation, about this and he has offered his help with the upgrade if needed.
The text was updated successfully, but these errors were encountered: