Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: remove browserify, switch to webpack #498

Merged
merged 7 commits into from
Jun 14, 2018
Merged

refactor: remove browserify, switch to webpack #498

merged 7 commits into from
Jun 14, 2018

Conversation

lidel
Copy link
Member

@lidel lidel commented Jun 11, 2018

This PR switches the build from browserify to webpack.
I tried to make non-invasive and easy to review, so it does not change project layout.

Immediate gains introduced by this PR:

  • more control over build process, no surprises
  • time required by subsequent yarn build decreased from ~100s to ~30s
  • size of window.ipfs content script from 1.1M to 869K
  • size of entire add-on/dist from 6.5M to 5.6M
  • yarn watch produces human-readable code that is easier to debug

Long term goal is to use webpack for vendor-specific builds as well,
replacing current combination of browserify, jq-based json manipulation
and inlined shell scripting with more programmatic approach that
is easier to maintain.

Tasks

This PR is ready for review & merge if all below are checked:

  • remove browserify from build and deps
  • yarn build and yarn watch work as expected
  • there are no .js bigger than 4MB (limit introduced by addon-linter)
  • UI pages such as browser action have a separate, small bundle
    (we dont want js-ipfs and js-ipfs-api in common bundle, as it slows down UI popups)
  • yarn watch should generate human-readable code and/or source maps
  • yarn release-build produces the same output every time

Future Improvements

These things are not included in this PR:

  • cleanup final package (eg. ensure source .js are not copied to /dist/)
  • use webpack to generate manifest
  • use webpack to generate HTML entry points that load bundles, enabling further size optimizations

This is a first step in moving the build from browserify to webpack.
The goal is to use webpack for vendor-specific builds as well,
replacing current combination of browserify, jq-based json manipulation
and inlined shell scripting.

This changes:
- time required by `yarn build` from ~100s to ~30s
- size of window.ipfs content script from 1.1M to 869K
- size of entire add-on/dist from 6.5M to 5.6M
@lidel lidel self-assigned this Jun 11, 2018
@lidel lidel requested review from olizilla and alanshaw June 11, 2018 13:37
@olizilla
Copy link
Member

👀

This fixes noisy console logs on CI by switching to safe reported
when in CI env
Copy link
Member

@olizilla olizilla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am kicking the tires now. If all is well, I'll flip this to 👍

/*
occurrenceOrder: true,
minimizer: [
new UglifyJsPlugin({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why we can't enable uglify here?

Copy link
Member Author

@lidel lidel Jun 11, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we run webpack with -p minification via uglify it is enabled with default options.
I've left this section in case we want to customize options that are passed to uglify, but defaults seem to works just fine. Will probably remove it before merge.

alias: {
// These are needed because node-libs-browser depends on outdated
// versions
// zlib: can be dropped once https://github.com/devongovett/browserify-zlib/pull/18 is shipped
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// versions
// zlib: can be dropped once https://github.com/devongovett/browserify-zlib/pull/18 is shipped
zlib: 'browserify-zlib',
// http: can be dropped once https://github.com/webpack/node-libs-browser/pull/41 is shipped
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- removed custom options that we don't need to use for now
- removed workarounds that are no longer needed
- shared webpack config as a base for all targets
- separates build targets for background page, GUI and content scripts
- bundled webext polyfill for chrome, removed two calls to `tabs.executeScript`
- detects and rebuilds ipfs proxy content script on changes (`yarn watch`)
- removes browserify libs and other leftovers
lidel added 2 commits June 13, 2018 13:44
This is a PR on top of #498 

- `add-on/dist/` size decreased to `5.5M`
- shared webpack config as a base for all targets
- separates build targets for background page, GUI and content scripts
- bundled webext polyfill for chrome, removed two calls to `tabs.executeScript`
- detects and rebuilds ipfs proxy content script on changes (`yarn watch`)
- removes browserify libs and other leftovers
@lidel
Copy link
Member Author

lidel commented Jun 13, 2018

Added changes from #499 to this PR, which brings:

  • add-on/dist/ size decreased to 5.5M
  • shared webpack config as a base for all targets
  • separates build targets for background page, GUI and content scripts
  • bundled webext polyfill for chrome, removed two calls to tabs.executeScript
  • detects and rebuilds ipfs proxy content script on changes (yarn watch)
  • removes browserify libs and other leftovers

This will make logs non-interactive and more detailed
Copy link
Member

@olizilla olizilla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@lidel lidel merged commit 4c77644 into master Jun 14, 2018
@lidel lidel deleted the webpack branch June 14, 2018 21:54
lidel added a commit that referenced this pull request Jun 15, 2018
This PR enables Firefox users to disable creation of `window.ipfs` attribute via _Preferences_ screen, solving fingerprinting issue raised in #451.

It requires webpack, so should be merged after #498 

### Background

Existing `tabs.executeScript` API with `runAt: 'document_start'` flag was executing too late and page scripts were  unable to detect `window.ipfs` correctly.  More info on the underlying issue: #368 #362 (comment)

As a workaround that worked in both Chrome and Firefox, we were forced to always load content script via manifest definition. This meant no control over when it is loaded and no easy off switch. If `window.ipfs` was disabled via _Preferences_, it was throwing an Error on access, but remained in the scope.

Mozilla added [`contentScripts`](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/contentScripts/register) API in Firefox 59. The key difference between `tabs.executeScript` and `contentScripts` API is that the latter provides guarantee to execute before anything else on the page, passing [our synchronous smoke test](https://ipfs-shipyard.github.io/ipfs-companion/docs/examples/window.ipfs-fallback.html). 

### Known Issues

Chrome does not provide `contentScripts` API so it will continue to statically load `content_script` via  manifest.  Hopefully with time, other browser vendors will adopt the new API.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants