You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Build artifacts should be committed on every commit
✔️ can use tip of tree build artifact from git, have a built file for every commit
❌ messy git history
will need to set up a github action to build this via CI or something
Build artifacts should be committed only on publish
✔️ cleaner git history, can easily grab latest published/working build from git
❌ can't get tip of tree build artifacts
Build step can be a part of the publish
Build artifacts should not be committed
✔️ Cleanest history
❌ Requires npm or build step to use
Can create a build during publish as part of an npm package that never hits git history.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: