search

qooxdoo / deployment

In this repository, we run tests and deploy the qooxdoo NPM compiler and framework packages
https://qooxdoo.org
0 stars 0 forks source link

Deployment workflows #1

Open cboulanger opened 4 years ago

cboulanger commented 4 years ago

Here's how I understood our recent discussions:

In the deployment repo, we do the testing with the setup that John has already prepared (testing compiler with framework and framework with compiler, testing compiler and framework on a set of applications).

When building and testing are successful, we then release:

a) the compiler package, containing the compiled compiler, with a dependency on the framework package. However, the dependency is only on the framework source code. Because compiling takes place outside of the repo itself, we no longer have a circular dependency on the "qx_server" package. The source code could theoretically be downloaded on-the-fly from GitHub, or shipped with the compiler package (which would blow up its size). The dependency on the framework package mainly serves to keep the package size smaller.

b) the framework package, containing the uncompiled framework source code with a compiled version of qx_server. This package has no dependencies.

open questions:

Is this the way to go?

hkollmann commented 4 years ago

a) I would prefer the source in the package - so you have an consistence state. We should put the courrent source tree of the framework into the compiler before packing him. b) The framework package is only needed for old projects, And the older compiler version. IMHO it must'nt be maintained and could be set to deprecated for v7.

johnspackman commented 4 years ago

I don't agree, IMHO the framework source code should be a npm package because the framework is not really tied to the compiler in that way. As the compiler is installed by npm, there shouldn't be any version issues and it keeps things clean and explicable. The compiler version numbers do not match with the framework version numbers either, so if we ship the source code of the framework with the compiler, we'll have to "know" that if you're using compiler v1.2.3 that this relates to framework version 6.2.1

Having the framework as an independent version allows users to easily choose a specific framework version (eg for team development), and be clear about exactly what version of the framework they are all using. It makes sense for this to be independent of compiler version, because a minor bugfix or feature improvement in the tooling should not force everyone in the team to upgrade their framework - not least because they might be concerned that there is a lot more room for problems to be introduced if the whole framework is upgraded.

There are two variants of entire-framework-as-a-single-js-file that we would want to produce - one for browser development and one for nodejs development. The browser version should only be made available via a CDN - it's only used for browser apps which have no compiler and therefore no loader, and while there are some webpack-type tools which pull in JS from npm, there are plenty of those tools which do not use npm. All tools, including projects which do not use tools like jsfiddle, will support CDN versions so it's an easy fix. (Also, the browser version of entire-framework-as-a-single-js-file is not the same as the framework shipped as npm that I mentioned in the first paragraph)

The nodejs version of entire-framework-as-a-single-js-file would obviously only have an npm version.

cboulanger commented 4 years ago

I agree with John that it makes sense to keep compiler and framework separate as NPM packages, at least for the time being. We should revisit this question when we start v7. We've always talked about re-integrating the qx.tool namespace back into the main code tree, but that's a decision we should consider thoroughly, since there are some practical reasons to keep them separate. Anyways, that's for later.

If we can agree to this, at least temporarily, would this be the list of deliverables?

  1. NPM: Compiled compiler
  2. NPM: Framework source code
  3. CDN package (entire-framework-as-a-single-js-file)
  4. NPM "Qx-Server" (entire-server-framework-as-single-file)
    • containing the compiler or not (probably not)?
    • part of 2. (as it is now) or separate (which I would prefer)?
hkollmann commented 4 years ago

I agree too.

  1. seperate module. We had this before: https://www.npmjs.com/package/qooxdoo-sdk
johnspackman commented 4 years ago

:+1: #4 not including the compiler

cboulanger commented 4 years ago

Ok, we seem to have a consensus. I'll post it on the dev chat to give the others the opportunity to weigh in.

cboulanger commented 4 years ago
cboulanger commented 4 years ago

The old https://www.npmjs.com/package/qooxdoo package should probably be a copy of @qooxdoo/server.

oetiker commented 4 years ago

in the past there where several changes to the framework which also required changes to the compiler ... effectively tying the two together ... when doing the theming work I was looking at adding additional features to the theme definition method and found that this is not easily possible without changing the compiler as the compiler knows which properties are legal in a theme definition ...

how do we deal with this ?

cboulanger commented 4 years ago

@oetiker I think this needs to be dealt with on the level of the application, which can enforce a minimal version of both compiler and framework. As I've said above, we should think about the pros and cons of one single codebase for compiler and framework, but I think the right time for this is after the release of v6.

johnspackman commented 4 years ago

I was looking at adding additional features to the theme definition method and found that this is not easily possible without changing the compiler as the compiler knows which properties are legal

I think that this is a bit of a special case - the compiler tends to care little about many of the keys, but does try to expect certain keys just so that it can provide warnings or errors at compile time instead of leaving it until runtime; AFAICR the generator did a similar thing, although the generator was better at policing it than the compiler is.

cboulanger commented 4 years ago

In @qooxdoo/server, should we ship two different packages, one for current node LTS and one for Rhino? They certainly would have different babel settings. Or is Rhino such a special case that we leave it to users to hand-compile a Rhino version (I think among us, only @johnspackman uses it). UPDATE: Or should it be a least-common-denominator build?

johnspackman commented 4 years ago

NodeJS only, because Rhino does not have a delivery mechanism or even require (and you might well be right that I'm the only Rhino user).

hkollmann commented 4 years ago

Which CDN server we should use? This is the not longer supported web pack: https://www.cdnpkg.com/qooxdoo?id=63524

cboulanger commented 4 years ago

I don't know. What do the cool kids use these days? cdnpkg looks ok to me...