Webpack configuration at runtime #1522

New Issue

fergalmoran · 2025-08-09T17:20:27Z

fergalmoran commented

2025-08-09 17:20:27 +00:00

Originally created by @dazinator on 7/13/2016

The workflow that the webpack middleware enables looks amazing. However the application I am working on is extensible. An extension can be installed into the application at runtime. This means its not possible to know what all the assets are at build / dev time. However when the application starts / runs, it discovers all.of the "installed" extensions¡ and therefore only at runtime does it know what all of the assets actually are. These assets are accessed via a Composite IFileProvider and so they may or may not live physically on the file system and asp.net core can see them none the less.

The asp.net team seemed to have decided pretty early on, when it comes to.bundling and minification, this is not a scenario they really care about, despite that being a feature in previous versions of asp.net. Luckily smidge popped up which has helped.to fill this gap in thus area - so it could be worse.

So now, with javascriptservices, some incredible features here, but again, unless I am mistaken, webpack (which basically drives all of the cool workflow features) is currently only useful at dev / build time - because:-

You have to configure the assets up front via a config file (You cant supply configuration / the assets in code at runtime).
Even if your application configured webpack by dynamically producing a webpack config file on startup, unless webpack can integrate with IFileProvider it can not see all.the files that your application can at runtime.

Is there any potential for asdressing this in the future?

*Originally created by @dazinator on 7/13/2016* The workflow that the webpack middleware enables looks amazing. However the application I am working on is extensible. An extension can be installed into the application at runtime. This means its not possible to know what all the assets are at build / dev time. However when the application starts / runs, it discovers all.of the "installed" extensions¡ and therefore only at runtime does it know what all of the assets actually are. These assets are accessed via a Composite IFileProvider and so they may or may not live physically on the file system and asp.net core can see them none the less. The asp.net team seemed to have decided pretty early on, when it comes to.bundling and minification, this is not a scenario they really care about, despite that being a feature in previous versions of asp.net. Luckily smidge popped up which has helped.to fill this gap in thus area - so it could be worse. So now, with javascriptservices, some incredible features here, but again, unless I am mistaken, webpack (which basically drives all of the cool workflow features) is currently only useful at dev / build time - because:- 1. You have to configure the assets up front via a config file (You cant supply configuration / the assets in code at runtime). 2. Even if your application configured webpack by dynamically producing a webpack config file on startup, unless webpack can integrate with `IFileProvider` it can not see all.the files that your application can at runtime. Is there any potential for asdressing this in the future?

fergalmoran closed this issue

2025-08-09 17:20:27 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#1522