Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit build process, build artifacts #134

Open
jsantell opened this issue Jan 2, 2020 · 1 comment
Open

Revisit build process, build artifacts #134

jsantell opened this issue Jan 2, 2020 · 1 comment

Comments

@jsantell
Copy link
Contributor

jsantell commented Jan 2, 2020

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.

@blairmacintyre
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants