aurelia / aurelia/webpack-plugin

Double inclusion of multiple builds in a package

Open
#206 6 comments 1 reaction 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.