css files fail to load when loaded from html files

[patroza]

From aurelia-dialog htmls:

Error: Failed loading required CSS file: aurelia-dialog/dialog.css

From my own globalResource card-view.html:

Failed loading required CSS file: resources/card-view.css

Probably related to #8 and #9

[adriatic]

Please check https://github.com/aurelia-ui-toolkits/aurelia-kendoui-bridge/issues/437 which is the same issue with a longer history and interesting comments

[martijnboland]

Figured out the problem. Aurelia's css resource loader needs the css as string, but webpack automatically converts css into js objects with the style and css loaders -> error. We need to find a way so that css resources that are loaded with the aurelia loader (cssresource) don't use the style and css loaders, but use the raw loader instead.

You could do that in the webpack config, but that'll get cumbersome very soon:

  plugins: [
    new AureliaWebpackPlugin({
      includeSubModules: [
        { moduleId: 'aurelia-auth' },
        { moduleId: 'aurelia-dialog' }
      ]
    })
  ],
  module: {
    loaders: [
      { test: /\.js$/, loader: 'babel', exclude: /node_modules/, query: { presets: ['es2015-loose', 'stage-1'], plugins: ['transform-decorators-legacy'] } },
->    { test: /\.css?$/, loader: 'style!css', exclude: /aurelia-dialog/ },
->    { test: /\.css?$/, loader: 'raw', include: /aurelia-dialog/ },
      { test: /\.html$/, loader: 'html' },
      { test: /\.(png|gif|jpg)$/, loader: 'url?limit=8192' },
      { test: /\.woff2(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: 'url?limit=10000&minetype=application/font-woff2' },
      { test: /\.woff(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: 'url?limit=10000&minetype=application/font-woff' },
      { test: /\.(ttf|eot|svg)(\?v=[0-9]\.[0-9]\.[0-9])?$/, loader: 'file' }
    ]
  }

[martijnboland]

@adriatic issue https://github.com/aurelia-ui-toolkits/aurelia-kendoui-bridge/issues/437 is a little bit different because the kendoui css files over there aren't even included in the bundle.

[adriatic]

btw, issue aurelia-ui-toolkits/aurelia-kendoui-bridge#437 is a little bit different because ...

This is somewhat worrisome, if the conclusion from your remark means how Telerik's css files should be fetched by the application "directly", as it is the case when using jspm / systemjs and no bundling.

Also, why do you include aurelia-auth and aurelia-dialog as submodules -and then you specifically exclude them in the list of loaders?

[martijnboland]

This is somewhat worrisome, if the conclusion from your remark means how Telerik's css files should be fetched by the application "directly", as it is the case when using jspm / systemjs and no bundling.

You might want to consider that. The other option is to import Telerik's css files from app.js.

Also, why do you include aurelia-auth and aurelia-dialog as submodules -and then you specifically exclude them in the list of loaders?

Excluded with the 'style|css' loader, but included with the 'raw' loader.

[Thanood]

import Telerik's css files from app.js

How do you do that and stay independent of which loader is used? It's not a big concern for apps because usually you decide to use one loader and use that throughout.

But libraries should be independent of which loader the end user (developing an app) decides to use.

An oversimplified example :smile:

import 'bootstrap.css';

works with webpack but does not work with SystemJS (bootstrap.css.js is being loaded, depending on default extensions). On the other hand, one of:

import 'bootstrap.css!';
import 'bootstrap.css!css';

works with SystemJS but seems not to work with webpack. Maybe there is a webpack configuration which enables this (I've tried { test: /\.css\!$/, loader: 'style!css' },).

I hope I'm not too much off topic.

[martijnboland]

I think libraries should at least be able to load their own css etc. via aurelia's loader abstraction. This doesn't work properly at this moment and needs to be fixed.

But when it comes to bundling external files like bootstrap's or kendoui's css files, I have truly no idea what the best option would be.

[adriatic]

@Thanood Thanks Daniel for discussing this - you are right on topic because the rule you stated

But libraries should be independent of which loader the end user (developing an app) decides to use

is the most important one in this discussion.

---

@martijnboland, allow me to comment on each of your statements:

I think libraries should at least be able to load their own css etc. via aurelia's loader abstraction. This doesn't work properly at this moment and needs to be fixed.

Cannot agree more - and cannot wait to get my hands on the fix (which I am sure you will create).

But when it comes to bundling external files like bootstrap's or kendoui's css files, I have truly no idea what the best option would be.

I do not see this case different from the first one above, because I am looking at this from the application developer's view point. Everything else than the code I wrote myself is external - and I should not be required to differentiate between KendoUI bridge loading stylesheets that are part of bridge's own code or stylesheets that are part of KendoUI modules, that are referenced as bridge dependencies. There is just one extra level of indirection and all that information is precisely specified in the package.json document.

jspm handles this problem by creating (or updating, if it already exists) the file config.js - which is subsequently used by systemjs loader as the "official" definition of the application's configuration. Note that there is a section called paths in config.js that is not created / managed by jspm and which is expected to exist by systemjs loader:

paths: {
    "*": "dist/*",
    "github:*": "jspm_packages/github/*",
    "npm:*": "jspm_packages/npm/*",
    "kendo-ui/*": "vendors/*",
    "kendo.*": "vendors/js/kendo.*.js"
  },

I believe that we need to do something similar for webpack -- and if you (Martijn) come to a conclusion that you do not know enough about jspm and I (Nik) do not know enough about webpack, please let me know and I will learn enough about webpack to be of assistance to you to get Aurelia / webpack "in order"

[seesharper]

Being able to load css from the require tag in html is a crucial feature in order to create truly self -contained and reusable components. If WebPack is going to be presented as an alternative to JSPM, it should work without needing to hack config files. Don't get me wrong, I love Aurelia and all its goodness, but the story around loading and bundling seriously needs some TLC. I have spent more time trying to get the build/deployment environment working than I have spent coding :) I am also a little confused whether WebPack is the preferred approach or if the Aurelia team plans to remove this dependency as well and implement something on their own. Maybe @EisenbergEffect could shed some light on this :)

[EisenbergEffect]

@seesharper Unfortunately, the entire modern JS world is at the mercy of package managers, bundlers and loaders, all of which are not in the greatest of state, to make an understatement. Every major framework is suffering from this now. We are trying to provide some new options but it will take some time. You have to realize that some of these 3rd party technologies have been in development for years.

As it stands, there are differences between loaders. SystemJS just doesn't work the same as Webpack (which isn't really a loader). As a result, depending on which option you take, you will have to do different configuration and you will have to make tradeoffs.

As I said, we are working on solutions, but it takes time.

[seesharper]

@EisenbergEffect Thanks a lot for your quick response. The case is that we have this relatively simple application that uses JSPM/SystemJS and I was trying to make it work using WebPack as I got the impression that it might be a better fit. Less technologies to learn and so on. Given the small size of the application we could live with WebPack workarounds for now although it would be great if the most of the basic stuff, such as loading css worked without too much trouble. I totally understand that Rome wasn't built in one day and we really appreciate the work being put into Aurelia. It is going to be a game changer!

[EisenbergEffect]

Thanks for the encouragement! The Webpack kit was initially contributed by @martijnboland who actually isn't an Aurelia user. So, we we are really thankful for his work seeding the project. However, there's probably a lot more that needs to be done to make it handle all the same scenarios. To that end, we are looking for some community members that would be interested in picking up where @martijnboland left off to help us find standard solutions to these common issues or at least to help us write the documentation that guides developers through the process of configuration Aurelia+Webpack for their project.

[adriatic]

SystemJS just doesn't work the same as Webpack (which isn't really a loader)

@EisenbergEffect points out to the real issue (assuming that he meant to use the word "linker" instead of "loader"). More precisely webpack lacks the ability to resolve dependencies automatically, unlike the [jspm / systemjs] duo, where the first acts as a linker and the second as the loader. This shared functionality is facilitated by the file config.js written by jspm and consumed by systemjs

[stoffeastrom]

More precisely webpack lacks the ability to resolve dependencies automatically

What do you mean? How do you think it works? I'm not a webpack expert but I think the whole point with webpack is that it can resolve it's dependencies automatically as long as you referenced them in your .js files ootb (there are a lot of different plugins adding functionality also). It will not automatically know that you have a dependency if you dynamically reference modules though which is a culprit in this case. For webpack 2 there seems to be coming support for dynamic loading with System.import which would be interesting to see how it could work with Aurelia.

[istrau2]

+1 I am having this same problem.

[adriatic]

I'm not a webpack expert but I think ...

You seem to be pretty aggressive in sharing your opinions, while not being an expert on the subject.

[EisenbergEffect]

Let's be cordial please.

[adriatic]

Let's be cordial please.

Good advice, so let me rephrase my own aggressive response :-)

I believe that webpack lacks several relevant properties of jspm like

• Full support for ES6 circular references and live bindings.
• Includes paths implementation.

[stoffeastrom]

I took some time to look into this a bit more. It looks like we could force webpack to use the raw loader dynamically. However we need to know when to ensure the raw loader. I'm not sure where the best place would be. I hacked the webpack loader

WebpackLoader.prototype.loadText = function loadText(url) {
    if( url.split(".").pop() === "css" ) {
      url = "!!raw!" + url; //Force webpack to use the `raw` loader
    };
    return this._import(url);
  };

However that doesn't seem to be a long term solution. We need to know that we are calling loadText from the CSSResource. If that would be pluggable we could add an css-resource-webpack that adds the enforcement...

@EisenbergEffect thoughts?

[adriatic]

@stoffeastrom is your description different from what @martijnboland suggested 10 days ago?

We need to find a way so that css resources that are loaded with the aurelia loader (cssresource) don't use the style and css loaders, but use the raw loader instead.

[stoffeastrom]

Yes.... it's dynamic not by configuration..?

[adriatic]

... Ah, yes, you hacked the loader, so no changes would be needed in configuration file. Sorry to miss that (important) distinction.

Let's see what Rob thinks about it

[EisenbergEffect]

@stoffeastrom It's possible to just replace the CSSResource that's "built in" with a version that works better with Webpack. None of it is really "built it". I just uses an Aurelia extension point that you can leverage as well. If there's some way we can improve our provided resources implementation to better support both scenarios, do let me know. I'm happy to make those improvements. As I'm sure you are away the implementation and installation of the CSSResource is in the templating-resources library.

[stoffeastrom]

@EisenbergEffect If we don't want to duplicate code we might want to export the classes in css-resources. Checking this and I found another place we could check that it's coming from the right place. In the webpack loaders _import function we could add

          if (loaderPlugin === "css-resource-plugin") {
            path = "!!raw!" + path;
          }
          resolve(_this.loaderPlugins[loaderPlugin].fetch(path));

[stoffeastrom]

PR

@sickboy and others, Can you verify that the PR is working for you guys?

[EisenbergEffect]

Yes, checking the loader plugin would be a reasonable solution. Great idea!

[martijnboland]

@stoffeastrom did the PR work for you? I can't seem to get it to work. It's still using webpack's css|style loader. I have the feeling that explicitly adding a loader for certain types (!!raw!) doesn't work for dynamically resolved files.

[adriatic]

@martijnboland @stoffeastrom

This fix

does not address my problem which manifests itself as

dev-server.js:60 [HMR] Waiting for update signal from WDS...
aurelia-logging-console.js:50 DEBUG [aurelia] Loading plugin aurelia-templating-binding.
aurelia-logging-console.js:50 DEBUG [aurelia] Configured plugin aurelia-templating-binding.
aurelia-logging-console.js:50 DEBUG [aurelia] Loading plugin aurelia-templating-resources.
aurelia-logging-console.js:50 DEBUG [aurelia] Configured plugin aurelia-templating-resources.
aurelia-logging-console.js:50 DEBUG [aurelia] Loading plugin aurelia-history-browser.
aurelia-logging-console.js:50 DEBUG [aurelia] Configured plugin aurelia-history-browser.
aurelia-logging-console.js:50 DEBUG [aurelia] Loading plugin aurelia-templating-router.
aurelia-logging-console.js:50 DEBUG [aurelia] Configured plugin aurelia-templating-router.
aurelia-logging-console.js:50 DEBUG [aurelia] Loading plugin aurelia-event-aggregator.
aurelia-logging-console.js:50 DEBUG [aurelia] Configured plugin aurelia-event-aggregator.
aurelia-logging-console.js:50 DEBUG [aurelia] Loading plugin aurelia-kendoui-bridge.
aurelia-logging-console.js:50 DEBUG [aurelia] Configured plugin aurelia-kendoui-bridge.
aurelia-logging-console.js:50 DEBUG [templating] importing resources for aurelia-kendoui-bridge/autocomplete/autocomplete.html []
aurelia-logging-console.js:60 INFO [aurelia] Aurelia Started
aurelia-logging-console.js:50 DEBUG [templating] importing resources for app.html ["nav-bar.html", "bootstrap/dist/css/bootstrap.css!", "kendo-ui/styles/kendo.common.min.css!", "kendo-ui/styles/kendo.bootstrap.min.css!"]
aurelia-loader-webpack.js:87 Uncaught (in promise) TypeError: Cannot read property 'fetch' of undefined
    at eval (webpack:///./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js?:87:52)
    at WebpackLoader._import (webpack:///./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js?:84:12)
    at eval (webpack:///./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js?:140:16)
    at WebpackLoader.loadModule (webpack:///./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js?:138:12)
    at WebpackLoader.loadAllModules (webpack:///./~/aurelia-loader-webpack/dist/commonjs/aurelia-loader-webpack.js?:124:23)
    at ViewEngine.importViewResources (webpack:///./~/aurelia-templating/dist/commonjs/aurelia-templating.js?:2650:24)
    at ViewEngine.loadTemplateResources (webpack:///./~/aurelia-templating/dist/commonjs/aurelia-templating.js?:2620:17)
    at eval (webpack:///./~/aurelia-templating/dist/commonjs/aurelia-templating.js?:2589:38)(anonymous function) @ aurelia-loader-webpack.js:87_import @ aurelia-loader-webpack.js:84(anonymous function) @ aurelia-loader-webpack.js:140loadModule @ aurelia-loader-webpack.js:138loadAllModules @ aurelia-loader-webpack.js:124importViewResources @ aurelia-templating.js:2650loadTemplateResources @ aurelia-templating.js:2620(anonymous function) @ aurelia-templating.js:2589
aurelia-loader-webpack.js:87 Uncaught (in promise) TypeError: Cannot read property 'fetch' of undefined(…)(anonymous function) @ aurelia-loader-webpack.js:87_import @ aurelia-loader-webpack.js:84(anonymous function) @ aurelia-loader-webpack.js:140loadModule @ aurelia-loader-webpack.js:138loadAllModules @ aurelia-loader-webpack.js:124importViewResources @ aurelia-templating.js:2650loadTemplateResources @ aurelia-templating.js:2620(anonymous function) @ aurelia-templating.js:2589
aurelia-loader-webpack.js:87 Uncaught (in promise) TypeError: Cannot read property 'fetch' of undefined(…)

probably meaning that my issues that I previously discussed with @martijnboland is included in this thread by mistake (my apologies if this is indeed the case)

Just to be sure that my issues gets @martijnboland's assessment - here is the zipped project

[stoffeastrom]

@martijnboland Yes it worked for me but the only thing I tested was to to do a require in a html file of an css file that I know was added in the bundle. According to the webpack docs it works

You can also override the configuration loader order in the module request to suit special cases.

adding ! to a request will disable configured preLoaders require("!raw!./script.coffee") adding !! to a request will disable all loaders specified in the configuration require("!!raw!./script.coffee") adding -! to a request will disable configured preLoaders and loaders but not the postLoaders require("-!raw!./script.coffee")

@adriatic Yes, that seems to be another problem

[stoffeastrom]

@adriatic There was a lot of weird stuff with the attached example.zip but after some fixing I could get it running. I had to move the aurelia-bootstrapper-webpack from dependencies to devDependencies. The aurelia-kendoui-bridge hasn't declared it's npm dependencies and those were not declared in the sample app either. After that I could reproduce the issue you are mentioning. And was under the impression that you didn't want to change in the .html file to move between jspm and webpack which is the case here

 <require from="bootstrap/css/bootstrap.css"></require>

vs

 <require from="bootstrap/css/bootstrap.css!"></require>

removing the ! and it tries to load

css-resource.js:28 Uncaught (in promise) Error: Failed loading required CSS file: !!raw!bootstrap/dist/css/bootstrap.css(…)

which is what my fix is adding. However the bootstrap.css is not added in the bundle so it can't load it which is another problem. I only tested with adding a "local" css file and

<require from="./test1.css"></require>

So if the boostrap.css was added in the bundle I guess it would have worked..... @martijnboland Is there a good way to adding external css files to the bundle that is implicitly required? I guess we could parse all the .html files in the webpack-plugin sniffing for the require attributes and make sure they get added???

[stoffeastrom]

bootstrap was missing in npm dependencies and I added it in the includeSubModules but it doesn't seem to pick up any bootstrap.css but it picks up other files under bootstrap

[173] ./~/bootstrap/dist/js/npm.js 484 bytes {1} [built]
  [174] ./~/bootstrap/js/transition.js 1.83 kB {1} [built]
  [175] ./~/bootstrap/js/alert.js 2.26 kB {1} [built]
  [176] ./~/bootstrap/js/button.js 3.55 kB {1} [built]
  [177] ./~/bootstrap/js/carousel.js 7.14 kB {1} [built]
  [178] ./~/bootstrap/js/collapse.js 5.96 kB {1} [built]
  [179] ./~/bootstrap/js/dropdown.js 4.74 kB {1} [built]
  [180] ./~/bootstrap/js/modal.js 9.94 kB {1} [built]
  [181] ./~/bootstrap/js/tooltip.js 16.3 kB {1} [built]
  [182] ./~/bootstrap/js/popover.js 3.16 kB {1} [built]
  [183] ./~/bootstrap/js/scrollspy.js 4.71 kB {1} [built]
  [184] ./~/bootstrap/js/tab.js 3.9 kB {1} [built]
  [185] ./~/bootstrap/js/affix.js 4.84 kB {1} [built]

[stoffeastrom]

The bootstrap main file points to "main": "./dist/js/npm", and the webpack-plugin does path.direname so it doesn't go outside of the js folder so I guess it needs to be added in another way somehow..

[seesharper]

Maybe you need to specify what to include in the submodule?

include: /[^\.]\.(js|css)$/

[adriatic]

@stoffeastrom - thank you for digging into my stuff since I believe that it is important to get this few problems with webpack ironed out. The sample in my zip file shows both issues that I found (inability to find all needed modules and inability to load css files), so we might have a "common ground" to continue this exercise.

The bootstrap main file points to "main": "./dist/js/npm", and the webpack-plugin does path.direname so it doesn't go outside of the js folder so I guess it needs to be added in another way somehow..

This problem is solved in jspm / systmjs case by manual adding this section

paths: {
    "github:*": "jspm_packages/github/*",
    "npm:*": "jspm_packages/npm/*",
    "kendo-ui/*": "vendors/*",
    "kendo.*": "vendors/js/kendo.*.js"
  },

To the (jspm generated) config.js file - which as you know is used as the "input" to systemJS loader. Note that support for wildcards, which eliminates the need for specific details that webpack "seem to be needing".

[stoffeastrom]

@martijnboland After some more investigation it seems like you are saying that it doesn't use the raw loader. It loads the css but it's webpack that adds it and the error got swallowed :pensive: I tried different approaches but whatever in require(...) after require.ensure it errors out.

require.ensure([], function (require) {
  var result = require('aurelia-loader-context/' + path);
  if (typeof result === 'function') {
    result(function (res) {
      return resolve(res);
    });
  } else {
    resolve(result);
  }
});

[martijnboland]

@stoffeastrom that's too bad. I was hoping that I was wrong. My idea now is that we could maybe work with two webpack context's for aurelia. The one we have right now (aurelia-loader-context, created by the plugin) and a new one for files that need to be loaded as text and bypasses the loaders. Not sure if that will work, but I don't know of anything better at this moment.

[martijnboland]

Unfortunately, two contexts becomes a mess. I'm officially out of ideas now.

[seesharper]

This is one of those things that IMHO needs to be fixed as Aurelia moves towards a release candidate. It is still a little unclear to me whether Webpack will be a "supported" option for bundling and package management. Maybe it is time for the Aurelia team, @EisenbergEffect , to take a closer look at this rather than just relying on the issue being picked up by a community member (No offence). Personally I would much rather see Webpack being the "default" as it seriously simplifies the whole dev stack.

[EisenbergEffect]

@seesharper Yes, I would like to have this fixed.

The challenge is that Aurelia is built on top of the idea that you've got a native ES 2015 module loader present. We have an abstraction for it so that you can plugin different module loaders, however the framework is built on this important concept of modern JS.

We have a loader implementation for Webpack, but it's important to realize that Webpack actually isn't a loader at all. It's a build and bundling tool. As a result, Webpack itself is limited in what it can do. It will never be able to do all the things that a real module loader can do. That doesn't mean it can't work with Aurelia. For a number of scenarios, Webpack works just fine. For other scenarios it does not. We would like to make the scenarios that don't work as small as possible and that's what we are still working on with the help from the community.

We are looking for a community member who will join our core team and commit to continue focusing on Webpack support long-term. One of the reasons we say that we only have "preliminary" support for Webpack is becase we have not yet found a community member to maintain it and we haven't worked out a few of these final issues. Once we do, we will mark this as "full" support.

That said, I don't think Webpack will ever be our default solution. The main reason is based on the information above. It's not a real module loader and thus will never be able to exercise the full capabilities of Aurelia. Our default solution needs to be full-fidelity. We are working on a new solution which I think will become our default. In some ways our upcoming solution is like webpack, but it actually builds real modules that can be consumed by a real loader.

[EisenbergEffect]

Now, as to the problem here, I would guess that it comes from the .css files not being bundled at all or with the wrong loader plugin. I bet it would work if there was a way to tell Webpack to grab certain .css files and bundle them as text resources. Wouldn't that be all that was required?

[adriatic]

Somehow two problems that prevent Aurelia developers from using webpack are "folded" in this thread.

The first, which is correctly described by @martijnboland as: webpack fails to load css files referenced from html, has a solution (proposed by @martijnboland) that is not really a solution: make references to css from JavaScript files.

Second problem appears when the application "uses" a plugin (use KendoUI bridge as the example, as this is how this problem is found). If that plugin has external dependencies, these external dependencies are "not found".

Note that when using jspm / systemJS alternative, this problem is solved by paths data as shown below:

  paths: {
    "*": "src/*",
    "github:*": "jspm_packages/github/*",
    "npm:*": "jspm_packages/npm/*",
    "kendo.*": "src/root/vendors/js/kendo.*.js",       <----
    "kendo-ui/*": "src/root/vendors/*"                     <----
  },

It is my understanding that @martijnboland is aware of this summary and shares the same view with me.

[istrau3]

@EisenbergEffect Personally, I moved from jspm -> Webpack just because of the ease of use. I do not really know the difference between a module loader and a bundler. I come from a background where gulp transpile and minify -> browser. I would really appreciate if you could take the time to explain the difference between the two and how it all fits into your vision for Aurelia (perhaps in a blog post). I think that many others are in the same camp as me where they aren't aware of all the nuances that go into bundling and/or module loading but they are finding themselves spending a ton of time on the setup and then wondering if they have made the right choices etc. (e.g. I am now questioning my choice of using webpack now that you say that it is not the "default choice" because it is not a proper "module loader". I would love to understand exactly what that means and what kinds of implications that has for me in the future.

[patroza]

I think the problem with loading css from html files is that under normal circumstances, the loaded css becomes a javascript object (unless you use the raw loader - but then css doesnt load from JS, I think), while the templating engine expects just-text. In that case extending the templating engine or making a webpack variant that actually understands the javascript object could be sufficient?

[seesharper]

@EisenbergEffect Thanks again for a quick and comprehensive answer. I really appreciate you taking the time to answer these questions. I know you're a busy man :). Given the state of things, we have decided to just stick with JSPM for now as that seem to work just fine once set up correctly. That being said, we are actually using Aurelia for a real-world production app and besides loader/bundling issues, we have not had any real issues. Coming from C# (MVVM), Aurelia has proved a very easy transition over to front end development on the web.

[EisenbergEffect]

@seesharper Thanks for the encouragement. We've still got lots of room for improvement and we're working on many thing for the future.

@sickboy Could the webpack loader simply take what is returned by webpack and transform it into text content before passing it back? Since we know it relates to a particular plugin...

[Thanood]

I'm not a webpack expert at all, so please excuse if my post is off since it will mostly contain guesses, albeit hopefully good ones. :smile:

Webpack might not be an ES2015 module loader. Anyway, with regards to bundled packages it works close to what a loader does, right? The app requests a package which Webpack "knows" is bundled, knows where it is and then (kind of) loads that package.

If I am assuming this correctly then everytime an Aurelia app hits the <require> element, the Aurelia loader abstraction is invoked which in turn invokes its concrete implementation - in this case Webpack loader.

So if Webpack "knew" the <require>d file (indexed in one of its bundles) the Webpack loader could read this file and return it. This point of view seems to be already emerging by the conversation between @EisenbergEffect and @sickboy.

So this could be a rather elegant solution for Webpack to act as a loader if it's possible to have required files bundled and indexed.

From this point of view (Webpack acting as a "loader" of known modules inside its own bundles) there seem to be some configuration options for Webpack to provide the location of files to bundle/load. Namely for instance resolving and alias - I may be on the wrong track there but please take it as a suggestion.

Maybe there could also be a Webpack plugin which is able to read html <require> and provide an index for Webpack.

To summarize my thoughts: Webpack is all about bundling (packing) an application/library. It contains an index of bundled files and is able to load these files. In this regard it's still not an ES2015 module loader in the strict sense but I guess it can act as if it was a loader if it knows these css files and external libraries we're talking about.

[stoffeastrom]

@EisenbergEffect I finally got a change to test this and if I do this

        var p = path.resolve(process.cwd(), "node_modules", "bootstrap", "dist", "css", "bootstrap.css");
        //force the request to the raw loader
        dependencies.push(new ContextElementDependency("!!raw!" + p, "./bootstrap/bootstrap.css"));

in the webpack-plugin it gets added

[186] ./~/raw-loader!./~/bootstrap/dist/css/bootstrap.css

and

<require from="bootstrap/bootstrap.css"></require>

it seems to work :).

[stoffeastrom]

Problem is how this could be mapped into actually working as intended. I guess the webpack-plugin could parse the .html files and know the userRequest from the require from attribute but how we can map that to an actual request e.g

dependencies.push(new ContextElementDependency("!!raw!" + request, userRequest);

I have no idea

[stoffeastrom]

@martijnboland thoughts?

[EisenbergEffect]

@stoffeastrom Is there no way to create a webpack plugin that we can simply give a few globs to so it locates the .css files and appropriate includes them? For example, could we just tell it to include bootstrap and then to, say, include all .css files in the src folder?