aurelia / webpack-plugin

A plugin for webpack that enables bundling Aurelia applications.
MIT License
90 stars 36 forks source link

Support Webpack Prefetch #163

Open namelos opened 5 years ago

namelos commented 5 years ago

I'm submitting a feature request

We're porting a reasonably sized repo (the Aurelia app takes 100k sloc) from AureliaCLI (vanilla RequireJS / Gulp) to Webpack with this Plugin, I made everything works already (Many thanks for the plugin itself and the helpful yet brief wiki!).

We had some hand-rolled solutions that would prefetch with RequireJS bundles before because the loading speed is kind of essential to us, and Webpack support this already:

import(/* webpackPrefetch: true */ 'LoginModal');

The approach is just a dynamic import with magical comments. However, with Aurelia, I could only import modules with PLATFORM.moduleName('./foo-module', 'foo-chunk').

I tried to figure out if there's a straightforward way to do it. But if I get it right, It seems the IncludeDependency only support two arguments: the module name and the chunk it belongs to.

Is there any way to achieve this? Furthermore, there seem to be some other useful options like preload could be expressed with the magical comment, is it possible to support those with PLATFORM.moduleName? Could the behavior and lazy loading share with the<require></require> in templates?

Thank again for the great plugin.

Expected/desired behavior:

jods4 commented 5 years ago

That's a good suggestion. I think there are 2 issues that need to be sorted out for this to happen:

  1. Is this really supported by Webpack? From what I gather in Webpack source, webpackPrefetch maps to an option in ContextDependency. Yet, dependencies created by Aurelia are subclasses of Webpack ModuleDependency, which is a direct subclass of Dependency. So... even if we wanted to, I'm not sure we could add this option. Does it need a change in webpack? Would duck-typing (just adding a new options property) work? Should we change our dependency base class? (This needs to be thoroughly investigated has it might have very deep implications).

  2. Designs and goals for PLATFORM.moduleName were to create a bundler-agnostic API that could be used by different bundlers. Core idea here was to be able to share code, especially for libraries. Write your code once, and it could be consumed by different bundlers (Webpack of course, but maybe Rollup, Fusebox, and co. assuming there is a matching plugin). AFAIK this was never fulfilled as the only plugin that consumes PLATFORM.moduleName is this one for webpack. @EisenbergEffect what do you think about that? Would it be ok to add plugin-specific options to moduleName? Like moduleName('./foo-module', { chunk: 'foo-chunk', webpackPrefetch: 0 }). Or at this point, can we consider moduleName is a webpack-only thing? Given Aurelia roadmap I doubt there will ever be another plugin that consumes it.

EisenbergEffect commented 5 years ago

For vNext, we don’t need this plugin, so likely this is a vCurrent only plugin…and likely only for Webpack as other scenarios have not yet come up. We could add a generic options property to support this. I’ve got no problem with that. We’re definitely open to PRs.

ghost commented 4 years ago

Hi @namelos Maybe the preload-webpack-plugin can help you, and also check the "alternative tools" section in the readme.md

If you are using webpack 4+, use vnext (check these issues here and there)