Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
WIP: Webpackify #5033
initial assets output for the new webpack build:
compared to current master:
Things of note:
We may end up not going forward with this due to the size increase from switching back to a bundler like webpack. After some fiddling locally, I got it to only be an increase of about 11% and with the IE8 removal work, it may be only about 10% increase but would be nice if we can avoid that increase.
I'm sad to see your decision..
in my opinion, this should be fixed in es6 context in the plugins.
maybe like this api:
do you think this is a good idea?
So, the main reason why we aren't going to use webpack is because switching to it from rollup altogether makes the file size too large. We were looking about rolling up our files and then running webpack over that but we ran into another issue with trying to inline VHS. VHS depends on Video.js currently and either we get a circular dependency where VHS gets an empty object as Video.js or Video.js gets included twice in the final build of a user's bundle.
Updating plugins to not auto register themselves isn't necessarily an issue for webpack vs rollup. And for VHS itself, registering it correctly is a bit tricky, compared to just a regular plugin.
currently, whether video.js will be packaged by rollup or webpack, a user should be able to do:
import videojs from 'video.js'; import '@videojs/http-streaming'; // this isn't even necessary once we ship 7.0 by default import 'silvermine-videojs-quality-selector';
However, having the plugin export itself for the user to register isn't a bad idea. The main reason we do it currently so that we can easily export the plugin for
import videojs from 'video.js'; import qualitySelector from 'silvermine-videojs-quality-selector'; videojs.registerPlugin('qualityselector', qualitySelector);
ok I agree that my problem is not related to webpack vs. rollup...