Closed johnspackman closed 6 years ago
I am in favour of 1) - we select what we want to support and what we can reliably maintain (and we should be very conservative about that). Everything else is left to developers to implement in their own favourite build system (which can use the CLI or the API).
I think we need both. In generaty.py was an watch task for compilation of the scss files. Therefore this must be a first class feature of qx-cli watch process. Best would be if the watch has something like an pattern based plugin mechanism so that it can be easily extented. The process must be configurable in compile.json, e.g. to add the include dirs for the sass process.
For the static build i would like to have something like "before_compile" and "after_compile" scripts to some special copying for example. In old generate.py you could override each build step with your own commands. I think this is not really needed. What's needed is special work before and after compile. The application/feedreader is an good example where such jobs are needed. They do special copy of index.html after compile.
SASS is integrated now as first class member with qooxdoo-compiler #42 and qooxdoo-cli #31.
We have SASS Integration now. So we could close this isssuee
Thank you @hkollmann for your work on this!
In https://github.com/qooxdoo/qooxdoo-cli/pull/25, @hkollmann added an example showing how to add additional build processes such as
sass
, something which is necessary in order to support mobile development.In that PR, the solution is to add a bit of code into
compile.js
, which is an effective solution but will not get called more than once when using the--watch
option.My first thought was about how to adding facilities like SASS to the existing code that is fired when file changes are detected, and possibly making it possible to add any process into the build process. This is very attractive, but IMHO quite dangerous in that it is important to stay away from the area of a generic build systems. We do not want to veer off in the direction of grunt/brocolli/whatever because they are complex and it would be too much of a distraction and not part of our core goals.
On the other hand, having a command like
qx compile
is very effective and is an important part of the pitch about how easy it is to use Qooxdoo - even when there is a continuous compilation step, which JS developers sometimes steer away from. We would also not want to force developers to switch to another build system becauseqx compile
is inadequate in common scenarios.This issue is to discuss how we strike a balance between creating a very functional
qx compile
(which is not a full build system) vs. one that runs out of steam too quickly.I think the options are:
Create SASS and other processing steps as first class features of the
compile.json
- as there is a specific need (mobile development) this seems ideal. It would be integrated into the--watch
process and we would be free to change how it works. The risks of unexplained interactions between build processes are low, because we understand them and write the code.Create limited generic processes, which are fired when one or more files (identified by pattern matching) are modified. Processes would be run at a given stage, sequentially. The risk is that it becomes increasingly difficult for a user to debug what's happening when something doesn't work the way they expect, and there are complications in making sure we put in all the hooks in all the right places.
Create a conversion of
compile.json
into grunt/brocolli/whatever, and also build grunt/brocolli/whatever plugins to integrate the API. The risks would be that we dont have the resource to properly implement this and there may be compatibility issues which are difficult to replicate all functionality from one build system to another.At the moment, I'm favouring (1) because it seems simplest to write and maintain, and anyway SASS is an essential step, but what do you think?