qooxdoo / qooxdoo-compiler

Compiler for Qooxdoo, 100% javascript
MIT License
36 stars 23 forks source link

Intelligently revert #539 #540

Open cboulanger opened 5 years ago

cboulanger commented 5 years ago

In the interest of DRYness, we should revert #539 eventually and remove the autogenerated website files. We need them only to have an up-to-date version for git checkouts of this repo - the NPM package already always contained the newest version. In the current code (after #539), we need to make sure to update the built version with qx compile --rebuild-startpage and commit the result if the source version changes, otherwise both NPM and Git clone will contain outdated code. However, before we revert, we need to figure out how to make sure that git checkouts re-generate the build version automatically if the source has changed.

johnspackman commented 5 years ago

How about compiling it on first run into the ~/.qooxdoo directory (which is also used for configuration and other data). We already track the version number of the current qx, so record that version number in a file in that temporary directory, and if it does not match the current version delete the directory.

Not having the output directory inside the repo directory is a good thing IMHO, unless the output is going to be commited

cboulanger commented 5 years ago

Maybe we could also return to things as they were, since they were working completely fine for NPM builds, and solve only the problematic case, i.e. git clones? I was wondering if git hooks could be a solution - the website could be regenerated on each pull, for example...

johnspackman commented 5 years ago

do you mean a hook that did rm -f ./source/resource/qx/tool/website/build ? That would be fine (so long as a future fix doesn't change that to git clean -dfx 😱;) ) but it still feels a little inelegant to have important runtime artifacts weaved in with the git archive.

cboulanger commented 5 years ago

This would allow to "unweave" the build files, wouldn't it? The intention would be that the build files would be removed from Git and so the build dir would always be empty on checkout, as it was before, and the build generated on demand when qx serve is started and the dir found empty. This works well for NPM since it the NPM package is generated on Travis and there the build files are generated before deployment. The hook would then just make sure that the pages are regenerated when a new git version is loaded, whether or not the source version actually changed.

The other option would be to regenerate the website each time qx serve is executed, but we talked about that earlier and found it wasteful.