alpheios-project / webextension

Alpheios Browser Extensions
ISC License
6 stars 2 forks source link

move support files out of the dist directory #301

Open balmas opened 4 years ago

balmas commented 4 years ago

In order to pass the Mozilla code review, we need to make sure the contents of the dist directory are fully produced by the build process and can be reproduced by running our build script. Per the reviewer:

"I see you already have the dist folder populated with minified files. We do not run build instructions on already minified files and need to delete the dist folder, that's why the instructions return error. ...We need to be able to reproduce the exact build, in order to finish the review. We can wait 14 days for you to provide us with a version that will fix this issue. Otherwise we will reject all affected versions."

So we need to update our code to move all of the files out of the dist directory and make sure it can be fully populated by the build process.

At the moment, the directory contains the following files which are not produced or updated by the build:

  1. Manifest messages in _locales/en/messages.json
  2. Package icons in icons
  3. auth0chrome library in support/auth0
  4. polyfill library in support/browser-polyfill
  5. compatibility-fixes.js
  6. manifest.json
  7. env-webext.js

The build currently produces the following:

  1. compiled css in style
  2. compiled background.js
  3. compiled content.js

I think we can do the following:

  1. move the manifest.json, locales files, icons and compatibility-fixes.js to src and haven the build copy them there
  2. add the auth0-code-update step to the normal build process so that it always gets copied from the node_modules to dist
  3. add the polyfill library to our dependencies and copy it to the dist directory via the build process

I'm not sure of the best solution for the env-webext.js -- I have been wanting to change the way this works anyway because the dependency on the protected-config repo isn't usable for the switch to a full travis build. We could have a skeleton file that lives in the source directory and is populated by environment variables during the build. I'm open to other suggestions though.

@kirlat what do you think? Have I missed anything? We have to address this issue fairly urgently.