Reduce size of module dependency graph #1342
Description
The qunit npm package has quite a lot of dependencies installed when used in another project.
The total number of packages installed according to (as of QUnit 2.8.0) is 143 packages. (Not including dev dependencies, that are only installed for QUnit contributors.)
- Graph visualisation: https://npm.anvaka.com/#/view/2d/qunit/2.8.0
- Tree visualisation: https://snyk.io/test/npm/qunit/2.8.0?tab=dependencies
Assuming we won't be investing in a way to sandbox QUnit, I believe this is beyond what we can reasonably expect a developer to audit before installing. Keeping in mind that merely running npm install in a Git project using qunit, is enough for any of these packages turned bad to start scraping process.env, ~/.ssh, etc (e.g. through postinstall hooks, or at run-time).
I'm aiming with this task to take a serious look at what abstractions we need and are providing value, and which we might be better off not using a package for. For problems where the abstractions can be "simple enough to obviously have no problems", it might be better to simply inline it within our repo (with proper licensing information inline, if based on an existing package). In such case, I believe the theoretical value gained from future updates is non-existent or small enough to not outweigh the loss in understandability and security of QUnit overall. If in these areas we do find a rare bug one day, we can easily update it by hand.
Goal: Maximum 20, preferably less than 10.
QUnit prides simplicity, I believe. We've done well to uphold that in our API. I'm hoping we can reach simplicity in our dependency graph as well!
Relating reading:
- https://jakearchibald.com/2018/when-packages-go-bad/
- https://hackernoon.com/npm-package-permissions-an-idea-441a02902d9b
And also: