Description
This is a complicated one so deserves some explanation...
In 4.x we mangled private properties of the player (player.somethingPrivate_ --> player.a) including the tech. We've kept the tech private because it's extremely important to the video.js ecosystem that developers aren't building plugins that are locked to a specific tech. We should instead be aggressively abstracting video playback concepts at the player level so that they work the same across techs.
We've been able to maintain this for years through the combination of abstracting concepts and allowing users to pass configuration options to the techs (videojs.options.flash.foo = true). However with the new Source Handler interface and moving advanced formats like HLS and DASH into that model, it's put stress on this philosophy, because player users (not plugin developers) want to control unique aspects of those formats and their operation.
#2616 is the first step, allowing configuration options to be passed to the source handlers.
For more advanced run-time configuration we want to give 'approved' access to the tech and source handlers, for users who are just configuring the formats, not publishing plugins to be shared.
The API we've come up with looks like this:
var tech = player.getTech({ IWillNotUseThisInPlugins: true });
If you don't include the object, it will alert() and throw a new Error(). The point of doing the alert is to inform even the newest developer who may not be working with the console open. We don't want to frustrate people with this, we just want to make sure they're informed.
The alert and error will show how to disable the error and a link to a blog post/issue explaining the situation.
Comment if you have any other thoughts on function or object key naming.