aurelia / aurelia/webpack-plugin
Double inclusion of multiple builds in a package
- Dominant language
- TypeScript
- Stars
- 89
- Forks
- 33
- PR merge metrics
- No merged PRs in 30d
Description
**I'm submitting a bug report**
* **Library Version:**
5.0.3
**Please tell us about your environment:**
* **Operating System:**
Windows 11
* **Node Version:**
16.14.2
* **NPM Version:**
8.7.0
* **JSPM OR Webpack AND Version**
webpack 5.72.0
* **Browser:**
none
* **Language:**
TypeScript 4.6.4
**Current behavior:**
I have created a reproducing example [here](https://github.com/rmja/double-include) with a description of the problem.
In essence, it seems as if two different builds of a dependency package is included depending on whether e.g.
```js
import { PureAbility } from "@casl/ability";
```
or
```js
PLATFORM.moduleName("@casl/ability")
```
is used. That is probably ok, but if _both_ are used, then only one of the two should be actually included. Currently both are included which causes strange bugs, for example when registering an instance in DI with the key `PureAbility`. The instance is registered with key `PureAbility` from one build, but is resolved with a different version of `PureAbility` from another build.
**Expected/desired behavior:**
Only one build should be resolved for any package dependency.
A workaround currently is to use `NormalModuleReplacementPlugin` like this in the webpack config to force one particular build:
```
plugins: [
...,
new NormalModuleReplacementPlugin(/^@casl\/ability$/, resolve("./node_modules/@casl/ability/dist/es6m/index.mjs")),
]
```
Contributor guide
Research direction
Start with the linked double-include reproducing example and compare the webpack resolution of the ES import with PLATFORM.moduleName("@casl/ability"). Check the plugin behavior around these two entry forms; done means a package dependency resolves to only one build without requiring the listed NormalModuleReplacementPlugin workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, webpack
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100