Simplify webpack #713

Merged

neb-b merged 1 commit from webpack into master

2017-11-08 20:02:25 +01:00

neb-b commented

2017-11-05 08:44:00 +01:00

(Migrated from github.com)

Simplifying by adding more webpack config files?! Yep.

There are now three webpack files for the ui, but only because there is now a common config with the webpack essentials (entry, output, babel) and two other configs with extend the base config.

Before

webpack.config.js was the prod config
webpack.dev.config.js was the dev config
A lot of duplication of basic webpack setup

After

webpack.common.js is the base webpack config
webpack.prod.js extends the base config
webpack.dev.js extends the base config
Also updated to webpack@3

Note: Most of the additions are from yarn
cc @liamcardenas

Simplifying by adding more webpack config files?! Yep. There are now three webpack files for the `ui`, but only because there is now a common config with the webpack essentials (entry, output, babel) and two other configs with extend the base config. #### Before `webpack.config.js` was the prod config `webpack.dev.config.js` was the dev config A lot of duplication of basic webpack setup #### After `webpack.common.js` is the base webpack config `webpack.prod.js` extends the base config `webpack.dev.js` extends the base config Also updated to `webpack@3` Note: Most of the additions are from yarn cc @liamcardenas

kauffj (Migrated from github.com) reviewed 2017-11-06 17:24:28 +01:00

kauffj (Migrated from github.com) left a comment

This looks good to me other than one question about minification in production.

ui/webpack.prod.js

kauffj (Migrated from github.com) commented

2017-11-06 17:23:57 +01:00

At the same time, we fairly frequently ask users to give console output related to errors.

If there's no real performance win here, I'd suggest this is not worth the added difficulty in debugging user issues, but I could possibly be persuaded otherwise.

Does this actually add any significant performance benefit when the files are being loaded locally? I suppose marginally, since the file still needs to be read from disk and interpreted, but my guess is it is very minor. At the same time, we fairly frequently ask users to give console output related to errors. If there's no real performance win here, I'd suggest this is not worth the added difficulty in debugging user issues, but I could possibly be persuaded otherwise.

neb-b (Migrated from github.com) reviewed 2017-11-07 04:48:16 +01:00

ui/webpack.prod.js

neb-b (Migrated from github.com) commented

2017-11-07 04:48:16 +01:00

Good point. I'll take it out for now until I can get some real performance numbers. Then we can decide.

kauffj (Migrated from github.com) reviewed 2017-11-07 22:57:47 +01:00

ui/webpack.prod.js

kauffj (Migrated from github.com) commented

2017-11-07 22:57:47 +01:00

@seanyesmunt once this is removed, go ahead and merge this into master.

Recommended merging practices are here: https://github.com/lbryio/lbry/wiki/Branching-and-Merging

@seanyesmunt once this is removed, go ahead and merge this into master. Recommended merging practices are here: https://github.com/lbryio/lbry/wiki/Branching-and-Merging