Feature/multi build #4659
Feature/multi build #4659
Conversation
|
Hi to chime in, We are currently using dash.js almost exclusively on legacy hardware with targets down to Chrome 47 (roughly Tizen 3 (2017), WebOS 4), which is our lowest target, and a Chrome 63 breakpoint, which is roughly Tizen 5 (2020), WebOS 5. We're currently in the process of optimizing our bundle outputs to approximate the targets:
The reason for this is that most TVs or STBs target either Chromium or WebKit and from our experience in the German market these targets have a pretty good compatibility. We noticed that more and more new TVs are being used, so we decided to add Chrome 108 as our modern target, which fits well with our use of TVs and evergreen browsers. In my experience, I prefer packages which provide the most modern npm distributions in ESM without corejs polyfills, since we have a dedicated pipeline for our transpilation needs anyway. We use esbuild + swc + corejs to build the bundles we need. One pain point we currently have with dash.js v4, which will be fixed in v5, is the lack of an ESM bundle. For now, we need to patch sideEffects: false in dash.js because we want to remove dash.js from the final output via tree-shaking if the target does not need to play DASH content (if the content is progressive or HLS). We only ever need a browser bundle for libraries that try to support runtimes other than the browser, which may introduce nodejs libs that need to be replaced, but that shouldn't be the case for dash.js anyway. I hope this feedback helps a bit, and for what it's worth, I would welcome a modern esm build of dash.js. EDIT: For some features, we write our own small polyfills for common functions that we replace during the build process. Doing this on a modern bundle is usually much easier than doing it on already transpiled and polyfilled code. For example, there are cases where some tools do not like for let of loops, which can either be written by hand or introduced by transpilers (esbuild, typescript, or similar), which then get transpiled incorrectly when targeting ES5 and then need to be changed either before or after in the bundle generation process. |
There was a problem hiding this comment.
I would love to hear other opinions, but I think this could just be two bundles/folders:
dist/umd: The ES5/UMD bundle that can be loaded via<script src="" />on older platforms (TVs mostly).dist/esm: The ESM bundle for modern browsers using<script type="module" />and apps that use build tools to compile their JS.
| const esmConfig = merge(legacyConfig, { | ||
| experiments: { | ||
| outputModule: true | ||
| }, | ||
| output: { | ||
| path: path.resolve(__dirname, '../../../dist/legacy/esm'), | ||
| publicPath: '/dist/legacy/esm/', | ||
| library: { | ||
| type: 'module', | ||
| }, | ||
| libraryExport: 'default', | ||
| }, | ||
| }); |
There was a problem hiding this comment.
If legacy is essentially an ES5 build, how can there be an ESM version?
| const umdConfig = merge(modernConfig, { | ||
| output: { | ||
| path: path.resolve(__dirname, '../../../dist/modern/umd'), | ||
| publicPath: '/dist/modern/umd/', | ||
| library: 'dashjs', | ||
| libraryTarget: 'umd', | ||
| libraryExport: 'default' | ||
| }, | ||
| }); |
There was a problem hiding this comment.
The legacy version is already a UMD bundle. What is the advantage of having a modern non-ESM variant? I would think that anyone needing to include the library via script/src would use legacy+umd and anyone in a modern browser, or using a build system, would use modern+esm.
- integrate dash.js bundle in sample app output bundle
|
For information, the sample application |
|
Hi all,
That leaves us with the following builds:
The Please also let me know if you see any other issues with these changes. |
|
No input from our side; all sounds reasonably here. |
|
We'll likely continue pulling Dash.js' source files directly and building/bundling them ourself – just to remove a step in the chain of code transformations up to the build of our TV apps platform. We take a very similar approach to @story75 and share the same concerns as I describe in our previous discussion: #4617 (comment) Our main concern is the polyfills needed to run Dash.js don't change drastically. Our tools will notify us if an unsupported polyfill is introduced so we're not flying blind here. |
This PR addresses #4622.
Description
As discussed in #4617 and #4619 developers have implemented different ways to include dash.js in their application. This PR applies changes to the Webpack configuration and the build process of dash.js to create two different bundles:
A
legacybundle settingie: '11'as the target for Babel and amodernbundle that uses a.browserslistrcfile with target set todefaults.defaultsis a shortcut foris a shortcut for > 0.5%, last 2 versions, Firefox ESR, not dead.. For both builds, we create aUMDand aESMversion.This PR contains multiple commits but the relevant one is this one: 15a2bf1. It includes:
.browserlistrcfile to define the target browsers for the buildbuild/webpackfolder including subfolders for common configuration of thelegacyandmodernbuilds.commonfolder to avoid code duplicationdistfolder. It contains alegacyfolder and amodernfolder withesmandumdsubfolders for both.webpack.legacy.base.cjsthe'@babel/preset-envtarget is set explicitly toie:11. For unknown reasons, ignoreBrowserslistConfig was not working for me.package.jsonwas adjusted to use the right files inexports. Moreover,npm run buildnow creates both thelegacyand themodernbuild files. There are separate npm scripts to build only thelegacyor themodernfiles.The other commits in this PR adjust the path to the
distfiles accordingly and remove outdated samples.Open Questions
I am looking for any feedback people have on these changes. For instance:
modernbuild?legacybuild. See also Issue with dash.js 5.0 (nightly version) #4619 and Webpack and Babel Loader - Which target to define? #4617..browserslistrcconfig?dist?Open Todos