Part of the reason I was motivated to do this work is that I love Three's batteries-included approach – I don't need to spend a long time configuring my project or trying to figure out how to glue different libraries together (I've written more about this here https://medium.com/@Rich_Harris/small-modules-it-s-not-quite...). Nothing has changed vis-a-vis Three being a drop-in file.

But it's a double-edged sword – batteries-included historically means including code that you're not using in your project. ES modules give us the best of both worlds via tree-shaking. And once you've learned them (you're not learning Rollup, you're learning JavaScript – this is a standard we're talking about) you'll find it's much more logical than the alternative. Trust me!

The KeyframeTrack thing is just a special case resulting from the codebase's history. It could easily be fixed more elegantly, it was just outside the scope of this PR.

I build a framework that runs on top of Three.js. I need to not only consume Three.js and make a bundle for demos, but I also need to create a library bundle that other people can consume. Every time I've looked into Webpack or Browserify to try to do this, the only documented use cases I've seen have been for consuming, not publishing libraries.

What would you suggest as a workflow for providing drop-in packages? Most of my users are not very technical and usually don't have Node installed. They might be semi-comfortable getting a basic, essentially static site going (though they are often running on RoR), or they're hacking on scripts almost exclusively on CodePen. They want to be able to script-tag include JS files and get to work on their projects.