Bundling, tree-shaking and 3rd party libraries

Add-ons Development
#1

Please can someone clarify what we are allowed to do with respect to bundling 3rd party libraries via a build system such as webpack or rollup?

I have recently seen advice that indicates that:

  1. 3rd party libraries must be manually included independently of the webpack bundle
  2. It’s fine to use npm/yarn to include a 3rd party dependency as long as there are clear instructions on how to reproduce the add-on code (i.e. npm ci or similar)

I’m not sure how to best interpret the combination of advice and I’m particularly interested in understanding this soon because I am experimenting with using tree-shaking to massively reduce the amount of 3rd party code that gets bundled into the addon, both to improve security through a reduced attack surface and to reduce the size of the extension package.

1 Like
#2

You essentially can’t tree shake libraries. Since that’d mean you modify the third party code. The reason for that rule is so libraries can be identified to be authentic.

So you’d end up with a setup where you manually include the libraries using file-loader and use their globals via a global providing setting in webpack.

#3

So how does that work for the many libraries that are structured like https://github.com/MitsuhaKitsune/vuex-webextensions ? The npm package just contains a bunch of module files that build systems pull in as required and no “old-school” min.js file in sight. Even ignoring tree-shaking for a moment, that can’t be built using something like webpack file-loader can it?

It could just be that no-one uses any library like that but otherwise I’m still missing something in my understanding of how modern libraries can be included in a way that can pass AMO review.

1 Like
#4

Hello @luckyrat. Did you find out more about this problem? Have you been able to release new version with bundled 3rd party libraries?