-
Notifications
You must be signed in to change notification settings - Fork 972
Conversation
@@ -3,7 +3,7 @@ | |||
"react", | |||
["env", { | |||
"targets": { | |||
"chrome": 57 | |||
"chrome": 60 |
There was a problem hiding this comment.
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 😄
cc: @gyandeeps (who had originally provided a webpack 2 upgrade PR that we didn't have enough time/knowledge to review at the time) |
These changes looks good to me. The best part about Webpack 3 is |
also when I tested the PR I noticed that the CPU usage on |
@@ -23,7 +23,7 @@ function config () { | |||
path.resolve(__dirname, 'app', 'browser', '*'), | |||
path.resolve(__dirname, 'app', 'extensions', '*') | |||
], | |||
loader: 'babel' | |||
loader: 'babel-loader' |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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') |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
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", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :-)
ce848d6
to
0c161db
Compare
@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? |
@NejcZdovc Makes absolute sense. Thanks 😄 |
All comments should be addressed, thanks everyone! :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
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 |
i would recommend against Uglify js has a es branch but i havent tried it. I would say try |
"uuid": "^3.0.1", | ||
"webdriverio": "4.7.1", | ||
"webpack": "^1.12.9", | ||
"webpack-dev-server": "^1.14.0", | ||
"webpack": "~3.4.1", |
There was a problem hiding this comment.
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
I got a branch working with babili but it is really, really slow. https://github.com/brave/browser-laptop/tree/evq/babili |
Branch using uglify-es - https://github.com/brave/browser-laptop/tree/evq/uglify-es |
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:
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. |
@petemill Awesome, thanks for the detailed analysis! :) Seems like uglify-es is a clear winner vs babili, I've squashed it into this branch. |
@petemill thanks for the report. Results from me were very similar to yours. I did another one with package size:
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! |
There was a problem hiding this 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! 😄
Fixes #8614
Submitter Checklist:
git rebase -i
to squash commits (if needed).Test Plan:
I tested that the browser started up, the about pages loaded, and webtorrent loaded and functioned correctly in two scenarios:
npm run watch
andnpm start
CHANNEL=dev npm run build-package
and running the resulting binaryReviewer Checklist:
Tests