Explore webpack as replacement for browserify

[lance]

Currently we're generating a browser based version using browserify. Is webpack the new thing?

[helio-frota]

links:

http://blog.namangoel.com/browserify-vs-webpack-js-drama
https://www.toptal.com/front-end/webpack-browserify-gulp-which-is-better
http://perkframework.com/v1/blog/webpack-vs-browserify-the-ultimate-showdown.html
https://webpack.github.io/docs/comparison.html
https://laracasts.com/discuss/channels/elixir/browserify-vs-webpack-which-is-better
https://www.slant.co/versus/3454/11602/~browserify_vs_webpack
https://mattdesl.svbtle.com/browserify-vs-webpack
https://soledadpenades.com/2015/02/20/webpack-vs-browserify/
https://engineering.velocityapp.com/webpack-vs-browersify-vs-systemjs-for-spas-95b349a41fa0

[helio-frota]

Note: Focusing on the opossum's context only.

webpack

1. "never tries to actually be compatible with node.js
2. "It is built, from the ground up, to help you manage static assets for the front-end"
3. "brings more features and puts them in core"
4. "will always require some configuration to work for anything but the most basic case"
5. Install size (including dependencies):

[hf@t440 fooing]$ cat package.json 
{
  "name": "fooing",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "webpack": "^3.0.0"
  }
}
[hf@t440 fooing]$ npm install

> fsevents@1.1.2 install /home/hf/dev/fooing/node_modules/fsevents
> node install


> uglifyjs-webpack-plugin@0.4.6 postinstall /home/hf/dev/fooing/node_modules/uglifyjs-webpack-plugin
> node lib/post_install.js

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN fooing@1.0.0 No description
npm WARN fooing@1.0.0 No repository field.

added 342 packages in 10.573s
[hf@t440 fooing]$ du -s -h node_modules/
39M	node_modules/

browserify

1. "was born to make your Node code in the browser."
2. "expects to be used only in a Node.js project"
3. "is a smaller more ‘modular’ tool"
4. "is much more likely to work with minimal configuration but will force you into a small set of conventions"
5. Install size (including dependencies):

[hf@t440 fooing]$ cat package.json 
{
  "name": "fooing",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "browserify": "^14.4.0"
  }
}
[hf@t440 fooing]$ npm install
npm WARN fooing@1.0.0 No description
npm WARN fooing@1.0.0 No repository field.

added 131 packages in 2.199s
[hf@t440 fooing]$ du -s -h node_modules/
15M	node_modules/

random:

If however, you’re predominantly dependent on the NPM ecosystem and you want a tool with a small and very well designed API and takes minimal configuration, you should go for Browserify. It doesn’t have all the features of Webpack, but it does have most, and it’s very easy to get started with.

[helio-frota]

+1 to keep browserify

[lance]

Reopening, as I do believe webpack is the way to go after having read and heard more.

[lance]

Very simple changes so far (https://github.com/bucharest-gold/opossum/compare/53-webpack). For some reason, webpack is barfing on the test suite, so I'm not sure what we should do about that. It also barfs when having it output a compressed file. This, I think, is because it's using UglifyJS which cannot deal with certain ES6 syntax. Maybe this is related.

[helio-frota]

@lance is really necessary to have both exploded opossum.js and compressed opossum.min.js ?

using escompress :

-rw-rw-r--. 1 hf hf  92687 Feb 21 16:58 opossum-min.js

plus extra build steps on package.json and Makefile

using babel-minify-webpack-plugin (20K smaller but only min version on dist folder):

-rw-rw-r--. 1 hf hf 72342 Feb 21 16:25 opossum.js

plus a require() and a plugin on webpack.config

[lance]

@helio-frota I can live with that.