immersive-web / webxr-polyfill

Use the WebXR Device API today, providing fallbacks to native WebVR 1.1 and Cardboard
Apache License 2.0
378 stars 84 forks source link

Revisit build process, build artifacts #134

Open jsantell opened 4 years ago

jsantell commented 4 years ago

Currently, as a vestige of earlier prototype days by a single developer, the built files are created and committed manually, on an as-needed basis and before publishing. It's a good time to revisit what should be done

Some potential options:

My preference is for committing builds only on publish, or not committing them at all -- I don't know how much value it is to have tip-of-tree built artifacts.

Additionally, what kind of output files should be supported? I wouldn't mind only a ES module export, and leave minification up to consumers, unless we want to get in the business of hosting (via unpkg or other CDN solutions) a canonical polyfill URL.

blairmacintyre commented 4 years ago

My $0.02 is that I don't think a single canonical URL is useful; I would never include that in my web app because when it gets updated, my web page may break. I would always include a known version. Canonical URLs that are versioned would be useful, though.

Including a minified or at least packaged file seems useful; tossing a webxr polyfill at the top of your html file seems like a normal pattern, doesn't it?

Aren't there three models: ES6 modules (I have all code on my site), a collection of packaged js files (I include three.js/babylon.js/aframe.js/webxr-polyfill.js from my site, at the top of my html), or npm (I package everything in a blob). The former and later would just pull from npm, I guess, but the middle seems to need a file.

I personally am moving to ES6, but not everyone will.

I agree that we don't need tip of tree; only devs would care, and then can just use npm or build right?

Alternatively, it would be reasonable to move to a two branch system: develop branch for ongoing work, where we build on every commit (which also serves the purpose of making it easy to test), and then do "releases" by moving to master and adding a tag.