qooxdoo-archive / qooxdoo-cli

(deprecated, moved into qooxdoo-compiler) qx commandline
MIT License
4 stars 5 forks source link

Adding support for additional build processes #26

Closed johnspackman closed 6 years ago

johnspackman commented 7 years ago

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 because qx 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:

  1. 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.

  2. 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.

  3. 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?

cboulanger commented 7 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).

hkollmann commented 7 years ago

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.

hkollmann commented 6 years ago

SASS is integrated now as first class member with qooxdoo-compiler #42 and qooxdoo-cli #31.

hkollmann commented 6 years ago

We have SASS Integration now. So we could close this isssuee

cboulanger commented 6 years ago

Thank you @hkollmann for your work on this!