Two v2 ideas for discussion

[3cp]

I updated aurelia-cli deps, many deps dropped nodejs v8 support, so I changed the minimum supported nodejs version to 10.12.0.

Since this is a breaking change, the next release will be v2.0.0, although there is no new features.

I think we probably should take this opportunity to incorporate some other possible breaking changes.

1. decouple skeleton files.
   • creates a new repo aurelia/v1, moves skeleton files there.
   • user can create v1 app through npx makes aurelia/v1 with no tool installation.
   • au new will simply pass the arguments to "makes" which reads aurelia/v1 repo.

Pro: reduce aurelia-cli repo complexity, reduce published aurelia-cli package size, simplify e2e tests. Plus always up-to-date skeleton (through git repo, no need publish to npm) just like what we did for Aurelia 2 skeletons. Con: small breaking change because "makes" does unattended mode with -s features (silent mode with feature selections) while aurelia-cli uses -u (unattended) + optional -s features for unattended mode.

2. remove bin name au??
   • aurelia-cli creates not only bin name aurelia, but also alias it to au for convenience.
   • but we have plan to use npm package name au (acquired) for Aurelia 2 CLI (right now under @jwx's work in his personal au2 npm package).

Should we take this opportunity to remove bin name au from aurelia-cli?

[3cp]

au command probably can print out an error for now, something like

Sorry, "au xxx" has been removed from aurelia-cli, please use "aurelia xxx" instead.
We have decided to reserve "au" for Aurelia 2 CLI, which will be under plain npm
package name "au". More to come...

Then we will remove au command totally before Aurelia 2 CLI launch.

"aurelia xxx" might be too troublesome for lazy typers, maybe support "au1 xxx"?

[fkleuver]

I'd vote for an au1 alias for the v1 cli

[jwx]

The behavior I've had in mind once Aurelia 2 is ready for it, is that

• when in an Aurelia project, (npx) au will run the CLI, au1 or au2, matching the project
• when not in a project, (npx) au will run the au2 CLI
• (npx) au1 and (npx) au2 will specifically run the CLI for Aurelia 1 and Aurelia 2 respectively

This means that the Aurelia organization will have and publish not only au but also au1 and au2 (and so on if needed). I've got POC code for this locally and will push as soon as possible.

As for decoupling skeleton files, I think everything that's worth doing time-wise even when considering that v1 will eventually be replaced (even though it's a bit away) is fine.

[3cp]

when in an Aurelia project, (npx) au will run the CLI, au1 or au2, matching the project

That means all commands will be removed from aurelia-cli. The commands will be handled in au, au1, au2 packages.

I like the idea, it will reduce the code base of aurelia-cli even further.

I just want to highlight: I hope the end result will let users

1. don't need to install au2, au1, au inside the project devDependencies. (This is one of thing users don't like: a webpack app with dep on aurelia-cli which includes a irrelevant bundler).
   • global au can read local package.json to find out whether this is au2 or au1 project, without local installed au1 or au2.
2. only need npm install -g au (may be au1, au2 too if users want to use them directly).
3. au1 and au2 will only contains code for running tasks, aka a pure task runner. No bundler, no scaffolding.
4. scaffolding will be handled in git repo for "makes" tool, so the scaffolding is always up-to-date without requiring users to upgrade their globally installed au.

[3cp]

But I am thinking: since aurelia 1 will eventually be deprecated, do we need to invest "smart" cli to only allow users to omit "1" or "2"?? It seems not much benefit for too much work.

Why not simply do a breaking change?

1. au in aurelia-cli to print an error for now.
2. use au1 in aurelia-cli.
3. before aurelia 2 cli release, remove au from aurelia-cli totally.
4. simply use au for aurelia 2 cli.

In the end

1. au for aurelia 2 which is globally installed only.
2. au1 for aurelia 1 which is both globally and locally installed, no big code change in current aurelia-cli. I really hope to avoid big change around aurelia-cli code base, because of low interest.

[jwx]

Good comments and questions. Will try to answer them later, but for now a clarification: au1 is and will run the current aurelia-cli. au is and will run the latest CLI, which will be au2 when this starts to matter. All CLIs from au2 and upwards will know how to invoke the right CLI for a project. (This didn't require much to solve, actually.)

[3cp]

Ok, so for the scope of aurelia-cli, we just switch from au to au1? I will keep au to print out error message for a while.

As long as this what we will do for aurelia-cli, I can move on now for this repo. I guess it will just work after you got au and au2 packages implemented.

[3cp]

Ok, I started the work on https://github.com/aurelia/v1, note it's not the au1 CLI, but "makes" skeleton for Aurelia 1 (just like https://github.com/aurelia/new for Aurelia 2).

For npm packages au, au2, and au1 (the placeholder to protect the npm name). I guess @fkleuver will create them in the monorepo https://github.com/aurelia/aurelia packages folder.

[3cp]

npx makes aurelia/v1 is working now. Not fully tested yet.

[3cp]

Decoupled skeleton is landed in v2. Renaming bin name is on hold for further discussion.