This PR aids multiple versions (preview and release) of the website in coexisting at once by making sure they source from distinctly named root /static directories. Details:
In the repository, we move...
src/static/client4.js to src/static/js/client.js
src/static/xhr-util.js and src/static/lazy-loading.js into src/static/js as well
src/static/site7.css to src/static/css/site.css
src/static/site-basic.css to src/static/css/site-basic.css as well
src/static/icons.svg and src/static/warning.svg into src/static/misc
In the url-spec, we define...
all static paths to be in terms of a new STATIC_VERSION constant, initially '2p1' (see below)
all static paths to not be in terms of CACHEBUST (prev. defined in upd8.js, now dropped)
In the build, we route...
src/static/css to /static-${STATIC_VERSION}/css (via staticCSS.root)
src/static/js to /static-${STATIC_VERSION}/js (via staticJS.root)
src/static/misc to /static-${STATIC_VERSION}/misc (via staticMisc.root)
src/util to /static-${STATIC_VERSION}/shared-util (via staticSharedUtil.root)
Imports are unfortunately slightly misrepresented by the new code structure. We opted not to move any files currently under src/util, pending #82, and there's possibly room for improving apparent relative imports at that point. We're currently addressing the confusion by creating a mock src/static/shared-util folder (appropriately adjacent to src/static/js), which just has a readme explaining what's what.
This allows us to indicate new versions of the site source internals just by updating STATIC_VERSION. We're tentatively using this naming scheme:
static: Old naming scheme, never referenced in new builds
static-3p1, static-4p1, etc: initial preview build of release after the upcoming one, etc
This allows us to avoid source file collisions, have obvious updates within the naming scheme, and still benefit from cachebust in subsequent release/preview builds.
Ideally, after a release, the first commit is url-spec: STATIC_VERSION 2r1 (for example). This should make it easier to rebase preview after publishing a patch to release (not pending changes to how we merge pull requests, keep commit history, etc).
This PR aids multiple versions (
previewandrelease) of the website in coexisting at once by making sure they source from distinctly named root/staticdirectories. Details:src/static/client4.jstosrc/static/js/client.jssrc/static/xhr-util.jsandsrc/static/lazy-loading.jsintosrc/static/jsas wellsrc/static/site7.csstosrc/static/css/site.csssrc/static/site-basic.csstosrc/static/css/site-basic.cssas wellsrc/static/icons.svgandsrc/static/warning.svgintosrc/static/miscSTATIC_VERSIONconstant, initially'2p1'(see below)CACHEBUST(prev. defined in upd8.js, now dropped)src/static/cssto/static-${STATIC_VERSION}/css(viastaticCSS.root)src/static/jsto/static-${STATIC_VERSION}/js(viastaticJS.root)src/static/miscto/static-${STATIC_VERSION}/misc(viastaticMisc.root)src/utilto/static-${STATIC_VERSION}/shared-util(viastaticSharedUtil.root)Imports are unfortunately slightly misrepresented by the new code structure. We opted not to move any files currently under
src/util, pending #82, and there's possibly room for improving apparent relative imports at that point. We're currently addressing the confusion by creating a mocksrc/static/shared-utilfolder (appropriately adjacent tosrc/static/js), which just has a readme explaining what's what.This allows us to indicate new versions of the site source internals just by updating
STATIC_VERSION. We're tentatively using this naming scheme:static: Old naming scheme, never referenced in new buildsstatic-2p1: Initial preview build of upcoming release (Snow Pollen Appreciation Station)static-2p2,static-2p3, etc: subsequent preview buildsstatic-2r1: Initial release build of upcoming release (i.e, when it is public not under/preview-en/)static-2r2,static-2r3, etc: subsequent release buildsstatic-3p1,static-4p1, etc: initial preview build of release after the upcoming one, etcThis allows us to avoid source file collisions, have obvious updates within the naming scheme, and still benefit from cachebust in subsequent release/preview builds.
Ideally, after a release, the first commit is
url-spec: STATIC_VERSION 2r1(for example). This should make it easier to rebase preview after publishing a patch to release (not pending changes to how we merge pull requests, keep commit history, etc).