Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposed Packaging in Qooxdoo v6 #9369
This issue is to discuss the proposed packaging for Qooxdoo v6.
One-Step Install and Setup
It’s anticipated that Qooxdoo will primarily be delivered via npm, which will allow a really nice and simple getting started guide like this:
Use in Node.JS
We would also like users to be able to easily use Qooxdoo in nodejs applications, starting with our own components
Note that in this scenario (Zero-Compilation), we would not require that there is a separate compilation step in order to use Qooxdoo in a nodejs application - you might choose to add the compilation step later, for example if you wanted automatic dependencies/class loading, or you wanted to use the ES6->ES5 transpilation, etc, but we would not force you to use the extra compilation step unless/until you wanted to. This is important because the working practice for just about every node tutorial and npm module ever written is to just use
Zero-Compilation Web Applications
Another similar request is that there is an option to create web applications without using a compilation step at all; this would mean providing the whole of Qooxdoo for use by a single
Python Toolchain (generate.py)
Note that it is planned that we replace the API generator/viewer and the TestRunner in v6.0 because these are tools used by the end user and the generator does not support ES6 syntax - effectively this requires that we reimplement the API generator/viewer and TestRunner using the new tool chain (WRT the API generator, we also want to support “true” JSDoc standard so there are potentially changes that need to be made there anyway).
The new API generator/viewer and TestRunner could both be separated out into separate npm modules; there might also be good reason to separate out the Python toolchain including the API generator/viewer and TestRunner so that there is clear separation of concerns and an immediate upgrade path from 5.x to 6.x.
The disadvantage is that end users would have to change their batch processes for API & TestRunner - I am unclear as to how much of an issue this would be, presumably it is pretty easy? It might be possible to do it anyway by modifying the config.json files so that the “test-runner*” jobs are farmed out to the external modules?
So far, our proposal is to have these npm modules:
Potentially, we could also consider these new modules:
A complication to consider is that a "zero-compilation" version of
Rather than have a
Can we say that in semver of x.y.z, x.y should be synchronised across all modules, but the module increments its own .z as often as it likes?
Moving the python toolchain into a separate module makes a lot of sense, since it could be separately maintained for legacy applications.
Another idea would to farm out the "components" not to npm modules, but to contribs. This would remove one layer of maintenance complexity: you could work with the GitHub repos only and skip the npm publish step. This would require putting each component into its own repository. But there are pros & cons to this approach.
+1 for the Zero Compilation Web Applications. It will also enable Typescript support.
BTW, the following files are the only two (2) files needed in our Visual Studio IDE. Thanks to jbaron for updating it to Qooxdoo 5.0.2
Definition File: https://github.com/jbaron/cats/blob/master/src/typings/qooxdoo.d.ts
@johnspackman, the proposal regarding npm packages is reasonable, but SDK includes compiler, cli and any other stuff, so sdk contains everything a developer need:
Is it really necessary to have so many npm packages you proposed?
Please note, that qooxdoo-sdk is fundamental for qooxdoo SPA application developer, at present.
@johnsky the reasons we're proposing dividing Qooxdoo up into a number of modules is partly to keep download size down, and partly for separation of concerns inside the project. Components (like the demo browser) sprawl across the repository, and ideally would follow a separate (although similar) release schedule to the main framework anyway - these are client applications that use the Qooxdoo Framework, even though they are developed as part of the Qooxdoo Project.
This separation should make it easier for new users to get to know the project as well as make for an easy transition for more established users (and help us clear up a lot of files that are simply not used any more along the way).
What we're proposing is that
The reason that
The reason that
The reason that
While the other two, apiviewer and demobrowser should be separate (IMHO), I tend to agree with you that making them npm modules does not necessarily make best sense. I think now that they will probably be best delivered as contribs.
The idea is that
We don't release that often (although once we've reached v6 we should probably release more frequently), and if anyone needs a more fine grained delivery they would use git.
I think that the
I agree with you that real releases should be ready-to-go npm packages. I wasn't clear enough: I mean as long as we are in the alpha/beta phase, we should already be offering an NPM package so that the workflow is established, but it seems so incredibly wasteful (and a unneccessary work) to be releasing NPM packages of a moving target. My idea was that during this time, we could have a
That's the idea i am working on. We have a stable qooxdoo-sdk package version 5.0.2 on npm . We could use this to integrate into qx-cli package. We can't use qooxdoo for this - as suggested above - because the qooxdoo package is used for the qooxdoo Server components for a long time.
If you want to use the develop version of qooxdoo you can use npm link ../qooxodoo
Im just testing if changing the package name will break the build system before i submit a PR for this