Use npm organizational scopes for package naming

[cajus]

Using scopes for package naming (see scopes documentation), we can use our organizational prefix @qooxdoo for packages. Packages with this prefix are only publishable by the qooxdoo npm user.

Package naming would be this way:

@qooxdoo/cli @qooxdoo/sdk

This allows us to indirectly mark packages as "official" because they're from the @qooxdoo scope.

[cboulanger]

This should be in sync with the repo merging/renaming efforts of @hkollmann (see https://github.com/qooxdoo/qooxdoo-cli/issues/74#issuecomment-353058672). Should ´qooxdoo-cli and qxcompiler be merged into @qooxdoo/cli or into @qooxdoo/compiler?

[derrell]

In answer to @cboulanger's question about merging: based on my current understanding that there's almost no time that they would be used separately, my opinion is emphatically YES!

[cboulanger]

@derrell Ok, but yes to @qooxdoo/cli or yes to @qooxdoo/compiler? :-)

[cajus]

Oups. I didn't intend to start a discussion on which name to merge it to ;-)

compiler vs cli - I personally don't care. They both look great. Maybe it's a question of "why do I install that package?". If it's mainly because of the cli, let's name it cli.

[derrell]

LOL. Misread the question. I think I'd merge into @qooxdoo/compiler based on current functionality. The question is, do we have any plans to add functionality to the qx command that has nothing to do with compiling? I recall there was something planned for dealing with contribs, which wouldn't be compiler-related. If so, then @qooxdoo/cli may be more appropriate.

[cboulanger]

Wait a second. Does it really make sense to distribute separate "sdk" and "cli" packages, with the compiler being in the "cli"? Wouldn't you expect the "sdk", being a "Software Development Kit", to contain the compiler (like the java-sdk)? What about merging the compiler with the sdk? Or even: merge everything into the sdk?

[derrell]

What about those of us who don't really need the sdk because we work from master? I guess it does make some sense, since qxcompiler currently does require("qooxdoo") which I assume is the sdk... Also, we core developers are (hopefully!) the minority...

[johnspackman]

@cboulanger this is a good point - I'm trying to think back to why we ended up with separate cli, compiler, and sdk packages, the best I can come up with is that cli/compiler was working on a faster and more informal release cycle, not sure how it would sit alongside the legacy stuff, and working at a time when it wasn't clear how the cli/compiler would integrate (especially when they were proof of concept/beta releases). It's been helpful conceptually to keep them separate so far, but my sense is that we have a clear plan of where we're going (including backward compatibility) and I'm struggling to find a reason to not merge it into qooxdoo-sdk.

The cli & compiler APIs both depend on qooxdoo so there's no additional overhead, and users of qooxdoo will need to use cli and vice versa. compiler & cli's release cycle has formalised in line with qooxdoo.

[johnspackman]

PS merging into qooxdoo/master, the code could become part of the main framework, eg under a new qx.tools.* namespace. This may mean there would be one of those recursive situations where qx is used to compile qx, but that was on the cards anyway.

[johnspackman]

This issue was moved to qooxdoo/qooxdoo-compiler#89