Unable to generate bundle.js that matches the reviewers using browserify


Currently I’m trying to get my first add-on trough the review process. It’s an add-on that connects to MetaMask and gathers ownership information about specific tokens on the Ethereum blockchain. To achieve this the metamask-extension-provider and web3 are used. These dependencies are installed using NPM and a version-lock file is provided to make sure the versions of the dependencies match.

As outlined on https://github.com/MetaMask/extension-provider browserify is used to be able to package this into a bundle.js for use in the add-on.

However I’m not able to match the resulting bundle.js the Mozilla reviewer gets. At first I thought that de difference was caused because of version mismatches of the used tools (npm, node and browserify) since I used Arch during development and the reviewer used Ubuntu 20.04 . So I installed a Ubuntu 20.04 VM where I installed the specific versions of the tools the reviewer used (node v17.1.0, npm 8.1.2 and browserify 17.0.0). Unfortunately there is still a mismatch, so the add-on can’t be approved by the reviewer.

If i compare the resulting files I get the following Diff.

< }).call(this)}).call(this,{"isBuffer":require("../../../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js")})
< },{".":285,"../../../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js":152,"ethereumjs-util":496}],288:[function(require,module,exports){
> }).call(this)}).call(this,{"isBuffer":require("../../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js")})
> },{".":285,"../../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js":152,"ethereumjs-util":496}],288:[function(require,module,exports){
< }).call(this)}).call(this,{"isBuffer":require("../../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js")})
< },{"../../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js":152,"./internal":497}],496:[function(require,module,exports){
> }).call(this)}).call(this,{"isBuffer":require("../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js")})
> },{"../../../../../.nvm/versions/node/v17.1.0/lib/node_modules/browserify/node_modules/is-buffer/index.js":152,"./internal":497}],496:[function(require,module,exports){

It seems that browserify keeps referencing to local relative paths (which is useless when running in the browser anyway). The resulting bundle.js files does seem to work. Does anybody have any experience with similar issues when using browserify? And did you manage to fix it/get the add-on reviewed?

Any help is greatly appreciated .

Quick sidenote. I did a test where I moved the project 1 subdirectory down so the relative path matched the relative path on the reviewers machine. That does result in a matching bundle.js . But this isn’t really a clean/viable solution for future add-on updates/releases.

The clean/reliable solution is likely to use a browserify that is installed (as dev dependency) in the project’s node_modules instead of globally. That way the relative path will always be the same. It would also allow you to do thinks like npm run build (by defining a build script in the package.json that invokes browserify, which thanks to npm magic will just be available as an executable, as if it were installed globally)

EDIT: for anyone reading this in the future, this also makes sure the reviewer will use the same browserify version as you, since you can control it via package-lock!


Hey, thanks for the tip. I will give it a try as soon as I have time.

Currently I already did define a build script in the package.json, but this script simply assumes browserify is available globally. But I do agree that your sugestion is cleaner.