1

I built an Aurelia app using CLI and Webpack. Then upgraded both. Running au run or au run --env dev --watch I get the following in my console:

d:\projects\aurelia\aurelia-app\node_modules\tapable\lib\Tapable.js:63
                throw new Error(`Plugin could not be registered at '${name}'. Hook was not found.\n` +
        ^ Error: Plugin could not be registered at 'module'. Hook was not found. BREAKING CHANGE: There need to exist a hook at 'this.hooks'. To create a compatiblity layer for this hook, hook into 'this._pluginCompat'.
    at Compiler.plugin (d:\projects\aurelia\aurelia-app\node_modules\tapable\lib\Tapable.js:63:9)
    at Compiler.deprecated [as plugin] (internal/util.js:52:15)
    at ModulesInRootPlugin.apply (d:\projects\aurelia\aurelia-app\node_modules\enhanced-resolve\lib\ModulesInRootPlugin.js:15:11)
    at Compiler.apply (d:\projects\aurelia\aurelia-app\node_modules\tapable\lib\Tapable.js:71:16)
    at Compiler.deprecated [as apply] (internal/util.js:52:15)
    at PathPlugin.apply (d:\projects\aurelia\aurelia-app\node_modules\awesome-typescript-loader\src\paths-plugin.ts:120:13)
    at webpack (d:\projects\aurelia\aurelia-app\node_modules\webpack\lib\webpack.js:37:12)
    at Object.<anonymous> (d:\projects\aurelia\aurelia-app\aurelia_project\tasks\build.ts:19:16)
    at Module._compile (module.js:635:30)
    at Object.require.extensions..ts (d:\projects\aurelia\aurelia-app\node_modules\aurelia-cli\lib\project.js:239:19)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (d:\projects\aurelia\aurelia-app\aurelia_project\tasks\run.ts:3:15)

I read about the changes in Webpack 4 that break compatibility with plugins/loaders. But not sure if awesome-typescript-loader is compatible and if this loader causes the problem. Relevant env info:

  • node 8.9.1
  • npm 5.7.1
  • aurelia-cli 0.33.1
  • webpack 4.4.1
  • awesome-typescript-loader 4.0.1

TIA for any help, Benny

Benny Halperin
  • 1,872
  • 3
  • 13
  • 18

2 Answers2

0

Without knowing the complete list of your loaders I can't guess which one it is - you could deduce it by looking at which of your loaders has not had a major release in, say, the past 2-3 weeks.

It could be awesome-typescript-loader although it seems they have updated it by now. I moved to ts-loader when webpack 4 was released which fixed the problem.

The easiest way to upgrade to webpack 4 is by building up your webpack.config more or less from scratch, copying over parts one by one and making them work before adding the next.

Remove all text/css/json stuff and start with just typescript, then work from there. It's worth the trouble imo, because webpack 4 is fast

A few things you'll run into / want to consider:

  • Various optimization plugins (such as common chunks) have moved to another namespace
  • Source maps are mostly broken (again)
  • You need to set the mode property of your webpack config to "development" or "production" (no longer a cli argument)
  • ts-loader has caught up with (if not surpassed) awesome-typescript-loader in terms of speed, which was originally the latter's primary selling point; may be time to just move back to the "official" one
  • Some plugins seem to behave a bit differently when they're imported, e.g. I noticed I need to do import HtmlWebpackPlugin from "html-webpack-plugin"; instead of import * as HtmlWebpackPlugin from "html-webpack-plugin";
  • The upgrade is a bit of a zombie virus. You need to upgrade everything now.
Fred Kleuver
  • 7,797
  • 2
  • 27
  • 38
  • Thanks @fred-kleuver for your answer. I will check my list and use your guidelines. I use `awesome-typescript-loader` simply because `aurelia-cli` is installing it when creating a new typescript project. I agree that webpack 4 is worth the effort, although the plugin/loader ecosystem needs to catch up due to breaking changes. – Benny Halperin Apr 01 '18 at 17:58
  • Yes, and `aurelia-cli` installs it because back when they first put that together, `awesome-typescript-loader` was simply the better tool for the job. I would argue that it isn't anymore, hence I moved away from it (in fact I don't use aurelia-cli anymore at all, I just call webpack directly from npm). Anyway, don't be afraid to swap out the defaults provided by aurelia-cli. There are no hard dependencies regarding webpack, with the sole exception of `aurelia-webpack-plugin` – Fred Kleuver Apr 01 '18 at 18:32
  • I enjoyed having `aurelia-cli` do the tooling for me and let me focus on my code. Otherwise I have no sentiments to any particular loader. If `ts-loader` is a live project and does it well then great. – Benny Halperin Apr 01 '18 at 18:36
  • And @fred-kleuver BTW until recently I used Aurelia's webpack project template to start a project. But then I wanted to check `aurelia-cli` because I assumed it had matured and adopted webpack as its preferred bundler. And I wanted to understand how `aurelia.json` works (not there yet). I hope to find the formula that works best for me and requires minimum tooling effort. – Benny Halperin Apr 01 '18 at 18:50
  • Considering `aurelia-cli` is still on version 0 (not even alpha or beta yet), I wouldn't call it matured. There are still lots of uncertainties in terms of which way to go with bundling. If you'd like to have a working example of (aurelia-cli-free) setup with webpack, check out my plugin skeleton: https://github.com/fkleuver/aurelia-plugin-skeleton-ts-webpack (specifically `webpack.config.ts`) – Fred Kleuver Apr 01 '18 at 19:27
  • Thanks. Will do. By matured I meant a relative form of speech. Since I've read through blog posts and SO threads that it's widely used by Aurelia developers I assumed it was good enough for a small side project I am developing for learning purposes. The downside is that I find that their generated `webpack.config.js` may not be optimal/ideal/minimal for my purposes. So maybe better to revert to the skeleton based version I had used before and there upgrade to webpack 4. Or, use your skeleton (is it webpack 4?) – Benny Halperin Apr 01 '18 at 19:37
  • Yes, my skeleton is webpack 4. All latest stuff :) It's a plugin skeleton though, so bear in mind you need to be looking at the "demo" folder and related configuration for the rest of the setup if it's meant to be used for an app. I'm also using a couple additional tools such as NPS and I have the webpack configuration in typescript. But you can see in the package.json scripts how I get all that to work, – Fred Kleuver Apr 01 '18 at 21:16
  • After replacing `awesome-typescript-loader` with `ts-loader` it compiled successfully. Now I'm having an issue with `aurelia-google-maps` plugin but this is at run time. I will check your skeleton (sounds funny I must say) in the next free time slot. Thanks @fred-kleuver. – Benny Halperin Apr 02 '18 at 12:20
0

In my case, it was caused by an old plugin html-webpack-inline-chunk-plugin which does not support Webpack 4. Once removing it, the error is gone.

Also, there two might help future people:

Hongbo Miao
  • 45,290
  • 60
  • 174
  • 267