with this change qooxdoo-sdk is used as an npm plugin

[hkollmann]

So you can use: npm install qooxdoo-cli -g qx create myapp cd myapp qx compile

[hkollmann]

Full usage need package.json change in qooxdoo!

[johnspackman]

great! it's really nice to see this coming together 👍

[hkollmann]

There is no 6.0.0-alpha avaiable on npm

[cboulanger]

I have suggested that we release a 6.0.0-alpha NPM module consisting not of the (almost daily changing) code, but a stub that downloads the current master directly from GitHub, for example, using https://www.npmjs.com/package/github-download

[cboulanger]

If 5.0.2 doesn't work with the compiler, the whole npm package thing doesn't make sense, and it also makes no sense in my opinion to repeatedly upload a changing codebase to NPM, given that it is so huge.

[hkollmann]

You are right. 5.0.2 is compiling but not running. So we have 2 posibilities:

• release a 6.0.0-alpa version once from the current source. And write an comment that that is only a snapshot version.
• We use the github-download. This has the benefit that you get a current version each time you run node install

[cboulanger]

What about this: https://github.com/cboulanger/qooxdoo-sdk-prerelease

[cboulanger]

Very simple stub, could be published to NPM as qooxdoo-sdk@6.0.0-alpha.

[hkollmann]

I like the idea. With some minor changes:

• it's enough to download the framework, maybe documetation. The other stuff is not needed.

` if(fs.existsSync(frameworkDir)) rmdir(frameworkDir);

ghdownload("https://github.com/qooxdoo/qooxdoo.git/framework", frameworkDir ) .on('error', function(err) { throw new Error(err); }) .on('end', function() { console.info("Download completed."); `

[hkollmann]

@johnspackman: What's your opinion?

[cboulanger]

@hkollmann Sure, that would cut down on download time. Did you test if that works? MAybe github-download needs a different syntax for downloading subfolders... I can try.

[hkollmann]

not testet yet.

[johnspackman]

I'm not convinced that we should implement our own downloader unless the point is to only download those source files which have changed - while the qooxdoo-sdk module only needs the framework folder, if we delete the downloaded directory completely and redownload then what is the difference between that and just including all of the framework code in the npm module?

[cboulanger]

@johnspackman The point for me is that this would be the easiest way to let alpha/beta-testers use the latest qooxdoo master without us having to re-publish qooxdoo master as an NPM module after each and every change. We would remove two steps of complexity (to have to git clone and nom link) and let people use the workflow that will be available after stable release AND use the latest code at the same time. Does that make sense?

[cboulanger]

Of course, we could create a travis job which publishes the whole of qooxdoo-sdk to NPM if the tests pass, replacing the 6.0.0-alpha release if this is possible (I don't think it is though). Otherwise, it would have to have some version number - which would that be? 6.0.0-alpha-1 etc? Which would then have effects on dependency calculation etc. For me, having a fixed NPM module which does the downloading itself seems to make much more sense... But I am open for other solutions that remove work for us and users in the same way.

[cboulanger]

@johnspackman Of course, if you can think of a way to download and apply a diff between a published version and the current master, that would be the ideal solution. See for example github-diff (needs a token, though). Other NPM modules that might be useful: https://www.npmjs.com/package/apply-patch or https://www.npmjs.com/package/git-diff-apply ...

[cboulanger]

Doing a bit more research, seems like it is possible to get a diff from GitHub without using the API. For example, to get all the changes since commit bf679b81250ea5d373a46a550ae128ada3513b62 :

https://github.com/qooxdoo/qooxdoo/commit/bf679b81250ea5d373a46a550ae128ada3513b62.diff

That means that we could publish a snapshot with an install script that would patch the snapshot to the current state.

[cboulanger]

@johnspackman @hkollmann Ok, maybe that is the solution: a) We publish a snapshot of 6.0.0-alpha as soon as @hkollmann's module rename PR has been merged. b) we add a script to qooxdoo-cli's postinstall hook which patches the qooxdoo-sdk module with a live diff from GitHub. Thoughts?

[hkollmann]

Is ok for me. Could you write the script?

[cboulanger]

I am happy to do it once the NPM module thing is resolved, i.e. once we have a working setup that loads qooxdoo-sdk@6.0.0-alpha as a dependency of qooxdoo-cli (so that I can work with the actual setup)...

[johnspackman]

@cboulanger it would be a lot easier to write a bash script to increment the version number and publish to npm than it will be to build a download function, with error handling etc. It also means that users can choose to go back a minor release if there is a compatibility issue (EG the recent revert with min/max)

One difficulty with a custom download function (whether diff or not) is that if there are unexpected things happening then there will always be a question over whether the diff was correctly applied or not. I suspect that without considerable work, it will be difficult to establish a concrete version that can be verified (eg can you calculate the hash of the entire codebase and check it against github?)

Sorry, but at the moment I still don't see the benefit in the approach of a custom download (when npm already provides a very well tested and well understood implementation), only downsides.

[cboulanger]

@johnspackman Maybe I wasn't clear enough yet - I think we're still not talking about the same thing - I am only talking about the alpha-state in which there is no version number other than 6.0.0-alpha (and no additional minor/major releases; you would have to create additional sub-alpha versions 6.0.0-alpha-1,2,3,4) while at the same time, the qooxdoo library code changes daily. For any identifiable release - for example beta-1, beta-2, RC-1, 6.0.0, 6.0.1, etc of course we use the normal NPM way, as you say. But we won't be there for at least a few more months. And in the meantime I would like to offer a way without having to "git clone" and "git link", just using NPM. Does it become clearer now what I want to achieve?

[hkollmann]

What‘s the problem with git clone and npm link?

[cboulanger]

@hkollmann @johnspackman Ok, if I cannot convince neither of you, I give up. :-) I was was thinking of a user-friendly way of tech-previewing the coming qooxdoo release in the way it would be used...

[hkollmann]

I understand your way. My idea was more pragmatic: First release an npm alpha Version. If we many questions and problems with npm link we should rethink and build an automatism. I do'nt think that there are to much users in the world which will work with the new toolchain in the moment.

And, the framework is very stable - so imho we could live with the alpha version the next time. I think there are some more points on the list of the new toolchain to work on before we can release version 6.

[cboulanger]

@hkollmann The qooxdoo master is stable - but there will be massive changes during alpha! For example, a lot of stuff will be removed and put into contribs. But sure, that doesn't affect the framework folder itself. So yes, then release the alpha as a snapshot. Make sure to populate the files property of package.json so that only the framework folder is published to NPM, and not the other stuff the compiler doesn't need.

[oetiker]

@cboulanger have you looked into how other projects solve this ? using git to keep the branch up to date seems like a neat idea ... since you get all the 'magic' for free and I guess we can expect from someone using alpha version to have a copy of git installed on his system after all these would probably also be people who are willing to contribute, and thus having a copy of git on their system is a great start

[cboulanger]

@oetiker I've probably put more thought into this than necessary - since we are only talking about the "framework" folder which, as @hkollmann noted, won't change dramatically (in contrast to the whole qooxdoo-sdk package, which probably will). So finally I agree that it is enough to have a random working alpha snapshot NPM package to work with, and not bother whether this snapshot is up-to-date or not. I just thought it would be nice to be able to offer the option to get an up-to-date installation by simply doing npm install qooxdoo-cli. But it is true that this won't make a major difference to early adopters.

[hkollmann]

Then i only need the approve and merge of https://github.com/qooxdoo/qooxdoo/pull/9446 from @johnspackman :)

[cboulanger]

@johnspackman Can you re-review (there was a merge confict) and merge? Thank you!