webpack 5

[ef4]

Known problems:

• we will hit this bug because some ember addons (including ember-data) use import { require } from "require". Incorrect handling of imported identifier "require" webpack/webpack#12154

Non-blockers with workarounds:

• needed to use weak types because of [5.0.0] built-in .d.ts is missing some(or many) types from @types/webpack webpack/webpack#11630
• thread-loader appears to break the new this.getOptions, so we'll keep using loader-utils for now

[rwjblue]

The upstream issue (webpack/webpack#12154), we need to investigate if the changes suggested there resolve our issue.

[ef4]

Unfortunately their solution doesn't really help us in the backward-compatibility case. We're relying on type javascript/auto because we really do have both import and require.

I still think this is a legitimate bug in their auto mode, but we can just work around it.

[ef4]

This is breaking both because of the webpack 5 upgrade (so apps with custom webpack config may need to adjust it) and because I made webpack a peerDependency of @embroider/webpack, so apps are now required to depend on it directly.