You may be tempted to use a shimming plugin for browserify to ideally include these libraries to your build tool chain. I would advice to forget all that hassle and just add the external module as a script tag before bundle.js:

<script src="http://code.highcharts.com/highcharts.js"></script>

and assume that Highcharts is a globally available variable similar to window and document variables. It's not ideal, and causes browser to do an extra request but it will save you from the never ending hassle of supporting various module import standards.

You can try to setup shim plugins, I'm not sure how they work nowadays but you've been warned.

As of Windows 10 Anniversary update we now have Bash on Ubuntu on Windows. It's not perfect but if Windows devs use it the portability issues mostly go away. Hoorah!!!

Prior to this I used the git for windows bash shelland started each npm script that requires portability with bash -c ""; however escaping quotes can become a real mess.

I noticed you scripts are not strictly portable as you set env vars at the start if the line. There is a npm package you can use but I think we can forget such hacks that now as mention above.

Don't worry, it will shrink a lot in production build.

As an example, let's see how big a bundle.js this project has:

• The development version of bundle.js is 1.8M
• Minified production version of bundle.js is 278K
• Minified and GZipped version of bundle.js is 65K, which is probably smaller then any picture in your page.

Even if the initial development version would be >4M in size, it's should be OK. E.g React is quite a big library and it increases the size a lot. If you need to analyze how you could reduce the size, disc is a useful tool to visualize the dependencies' sizes: https://github.com/hughsk/disc