Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Upgrade to Webpack 3 #10279

Merged
merged 1 commit into from
Aug 16, 2017
Merged

Upgrade to Webpack 3 #10279

merged 1 commit into from
Aug 16, 2017

Conversation

evq
Copy link
Member

@evq evq commented Aug 3, 2017

Fixes #8614

Submitter Checklist:

  • Submitted a ticket for my issue if one did not already exist.
  • Used Github auto-closing keywords in the commit message.
  • Added/updated tests for this change (for new code or code which already has tests).
  • Ran git rebase -i to squash commits (if needed).
  • Tagged reviewers and labelled the pull request as needed.

Test Plan:

I tested that the browser started up, the about pages loaded, and webtorrent loaded and functioned correctly in two scenarios:

  1. Running the browser via npm run watch and npm start
  2. Producing a build via CHANNEL=dev npm run build-package and running the resulting binary

Reviewer Checklist:

Tests

  • Adequate test coverage exists to prevent regressions
  • Tests should be independent and work correctly when run individually or as a suite ref
  • New files have MPL2 license header

@evq evq changed the title WIP Upgrade to Webpack 3 Upgrade to Webpack 3 Aug 3, 2017
@evq evq requested a review from NejcZdovc August 4, 2017 20:40
@luixxiul luixxiul added this to the 0.21.x (Nightly Channel) milestone Aug 5, 2017
@luixxiul
Copy link
Contributor

luixxiul commented Aug 6, 2017

note: after this PR is merged, we could test to upgrade file-loader to v1.0.0. Please see: #10203

@@ -3,7 +3,7 @@
"react",
["env", {
"targets": {
"chrome": 57
"chrome": 60
Copy link
Member

Choose a reason for hiding this comment

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

This is a great change too 😄

@bsclifton
Copy link
Member

cc: @gyandeeps (who had originally provided a webpack 2 upgrade PR that we didn't have enough time/knowledge to review at the time)

@gyandeeps
Copy link
Contributor

gyandeeps commented Aug 7, 2017

These changes looks good to me.

The best part about Webpack 3 is webpack.optimize.ModuleConcatenationPlugin which helps in content size reduction as well as improves runtime perf of the code. I would recommend trying that on the repo (at least for prod version). Make sure we test it thoroughly.

@luixxiul
Copy link
Contributor

luixxiul commented Aug 7, 2017

also when I tested the PR I noticed that the CPU usage on npm run watch reduced massively, which helps to prevent our laptops from consuming the battery :-)

@@ -23,7 +23,7 @@ function config () {
path.resolve(__dirname, 'app', 'browser', '*'),
path.resolve(__dirname, 'app', 'extensions', '*')
],
loader: 'babel'
loader: 'babel-loader'
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess we should update it to 7.1 to match webpack3. current version (6.2.0) only matches 1.x and 2.x (with deprecation warnings)

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

upgraded

// In development we overwrite the output path so the dev server serves everything from the gen subdir
if (env === 'development') {
// Note that this directory will never be created since the dev server does not write out to files
merged.output.path = path.resolve(__dirname, 'app', 'extensions', 'gen')
Copy link
Contributor

Choose a reason for hiding this comment

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

it wrote for me. maybe put in .gitignore? or maybe it will be needed eventually due to hash changes?

also having Content not from webpack is served from /Users/cezaraugusto/dev/browser-laptop/app/extensions/brave, is that expected?

Copy link
Member Author

Choose a reason for hiding this comment

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

weird, I will add to .gitignore.

that is expected and the same behavior as before (content base was previously set via --content-base=./app/extensions/brave" in the webpack-dev-server params)

@cezaraugusto
Copy link
Contributor

I left some comments/questions but looking forward for this. @NejcZdovc can you try this out too? app seems to be working fine and build seems to be faster for local development, looking good to me.

package.json Outdated
"webpack": "^1.12.9",
"webpack-dev-server": "^1.14.0",
"webpack": "^3.4.1",
"webpack-dev-server": "^2.6.1",
Copy link
Contributor

Choose a reason for hiding this comment

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

How about removing the carets for now (to avoid the failures) until those updates are confirmed to work properly and the automated tests are added, because those are major updates and they are not tested thoroughly yet? This is the lesson that I learned when I updated Aphrodite to ^1.2.3. Just my two cents.

Copy link
Member Author

@evq evq Aug 9, 2017

Choose a reason for hiding this comment

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

@luixxiul you're referring to possible future failures due to minor version bumps? does switching to tildes instead so we can use patch version bumps sound good?

Copy link
Contributor

@luixxiul luixxiul Aug 9, 2017

Choose a reason for hiding this comment

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

sgtm. if we keep following the development and make sure that failures which might be introduced by future minor updates can be fixed easily, let's change the tildes to carets :-)

@evq evq force-pushed the evq/webpack_3 branch 2 times, most recently from ce848d6 to 0c161db Compare August 9, 2017 08:36
@NejcZdovc
Copy link
Contributor

@gyandeeps I agree with you that we should be adding more plugins that would help us out with perf and size. What I would suggest that we keep this PR clean and should only include upgrade code and then we create separate PR for introducing new features. This way we prevent any strange regressions and start using new webpack sooner. wdyt all?

@gyandeeps
Copy link
Contributor

@NejcZdovc Makes absolute sense. Thanks 😄

@evq
Copy link
Member Author

evq commented Aug 9, 2017

All comments should be addressed, thanks everyone! :)

Copy link
Contributor

@cezaraugusto cezaraugusto left a comment

Choose a reason for hiding this comment

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

lgtm

@cezaraugusto
Copy link
Contributor

ok @bsclifton found a problem when trying to make a build. I did some research and uglify-js seems to have trouble minifying es6. I added babel-preset-es2015 and added the preset to .babelrc which made the build run longer but broke anyway. ATM I'm not able to find a good version of webpack's uglify plugin to make the release happen. I'm labeling PR/blocked until that is solved.

@gyandeeps
Copy link
Contributor

gyandeeps commented Aug 10, 2017

i would recommend against babel-preset-es2015 as its tranforms all the code to ES5. which is not good for chrome 60. Thats why way back in the day i moved to babel env plugin which smart enough to tranform code based on platform (chrome 60 in this case).

Uglify js has a es branch but i havent tried it. I would say try babili (babel minifier) which works well. It has some issues but worth a shot.

"uuid": "^3.0.1",
"webdriverio": "4.7.1",
"webpack": "^1.12.9",
"webpack-dev-server": "^1.14.0",
"webpack": "~3.4.1",
Copy link
Contributor

@gyandeeps gyandeeps Aug 10, 2017

Choose a reason for hiding this comment

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

this is already old 😄 ... latest is 3.5.3

@evq
Copy link
Member Author

evq commented Aug 10, 2017

I got a branch working with babili but it is really, really slow.

https://github.com/brave/browser-laptop/tree/evq/babili

@evq
Copy link
Member Author

evq commented Aug 10, 2017

@petemill
Copy link
Member

What's the goal with uglify / babili for the project? Is it primarily size reduction, code obfuscation or to prevent misuse? I'm guessing the former since the source is open?

Here's some analysis of the different branches:

  • uglify-es took 1m30s to build the package and resulted in 1.96mb aboutPages.entry.js and 0.98mb app.entry.js
  • babili took 6m30s to build the package and resulted in 2.01mb aboutPages.entry.js and 0.97mb app.entry.js
  • webpack3 with no minify took 1m to build the package and resulted in 3.53mb aboutPages.entry.js and 2.19mb app.entry.js
  • master (webpack 1 w/uglify) took 1m to build the package and resulted in 3.95mb aboutPages.entry.js and 2.75mb app.entry.js
  • uglify (with mangling turned off) took 1m25s to build the package and resulted in 2.41mb aboutPages.entry.js and 1.42mb app.entry.js

In all cases the package seemed to run fine, albeit limited and manual testing, so maybe for now it's ok to go with uglify-es.

Both uglify and babili have a subset of plugins / options that can be turned off, and that may help with the speed / size.

Hope that helps somewhat to get this moving. Happy to help in any other way.

@evq
Copy link
Member Author

evq commented Aug 14, 2017

@petemill Awesome, thanks for the detailed analysis! :) Seems like uglify-es is a clear winner vs babili, I've squashed it into this branch.

@cezaraugusto
Copy link
Contributor

@petemill thanks for the report. Results from me were very similar to yours. I did another one with package size:

CHANNEL=dev npm run build-package

  • 371.9 MB - webpack3 uglify-es
  • 365.9 MB - webpack3 babili
  • 361.5 MB - webpack1

While webpack3 with uglify-es have a bigger size, there are several options we can use to reduce it. I'm endorsing my last approval.

Will defer merging to @bsclifton as he may have other testing cases. @evq thanks for leading this and for everybody that helped. awesome work!

Copy link
Member

@bsclifton bsclifton left a comment

Choose a reason for hiding this comment

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

Awesome collaboration on this one, folks 😄
@evq @cezaraugusto @petemill @gyandeeps @luixxiul

I just tried out packaging / creating installer... appears to work flawlessly! 😄

@bsclifton bsclifton merged commit 3e8c8dd into master Aug 16, 2017
@bsclifton bsclifton deleted the evq/webpack_3 branch August 16, 2017 05:35
@bbondy bbondy modified the milestones: 0.21.x (Developer Channel), 0.20.x (Beta Channel) Oct 25, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants