[Proposal] Moving files & packages to aurelia-cli

[RomainLanz]

Hey everyone ! 👋

After the default installation of Aurelia with the CLI somes files are created under aurelia_project.

Those are Gulp's tasks, stubs for generators, environment configuration and the aurelia.json.

I think that those files shouldn't be managed by the developer. All gulp packages and tasks can be moved inside the CLI and same goes for stubs.

This will allow the aurelia team to manage them easily. Actually, we (devs) need to check with a new installation if tasks has been changed, gulp package updated, etc.

I feel that the current default installation of aurelia with the CLI is kinda bloated cause of that. We will remove 12 packages of the package.json, it will also ensure that aurelia provide the version of package it supports (https://github.com/aurelia/cli/issues/636).

So to resume, my proposal is to...

1. Move all Gulp's packages to aurelia/cli directly.
2. Move all stubs to aurelia/cli directly.
3. Move all Gulp's tasks to aurelia/cli directly.
4. Move env's configuration to aurelia.json.
5. Move aurelia.json to the root of the project.
6. Create a command to "extract" tasks and stubs to be able to custom them (like React eject command).

What do you think?

[JeroenVinke]

Hey @RomainLanz. Having the gulp tasks in the project (as opposed to in the CLI ) allows developers to easily modify and extend them, which many developers do. I believe this is a big plus, and I would like to keep it that way. We can definitely improve the update process, which is tracked in https://github.com/aurelia/cli/issues/231, but we have other priorities to take care of right now.

We're thinking of a solution where developers can install gulp tasks / generators that they need, where community members can share their tasks and generators so that others can install them. Perhaps we could use versioning of tasks/generators that would help with automatically updating the CLI (as discussed in https://github.com/aurelia/cli/issues/231)

[RomainLanz]

Do you have some statistics about how often people change those tasks?

I think the default setup should be always the most simple one for newcomers or advanced developers but you should have the possibility to extend with ease.

That's why React provide nothing by default but you can still use the eject command that will move all tasks/stubs/etc to the project.

Start small and grow with ease and quickly when needed

[JeroenVinke]

Ah yes, this is actually something we are going to look at in the future.

[avrahamcool]

I don't know about statistics, but I for one rely on the fact that I can change the build/run task for my projects. it can be a simple convention over configuration approach, where you have the ability to modify everything with ease if you want to, but you don't need to do anything if you just want the defaults.

[RomainLanz]

Hey @avrahamcool !

rely on the fact that I can change the build/run task for my projects

And you will still be able to do that!

So my thinking was to get the convention over configuration first, if you need to change something (task, template, etc.) you only need to "eject" those file and you'll end the same has you are right now (with all the files in the project).

[zewa666]

@RomainLanz I think this is quite a nice feature as typically beginners get confused with all those additional folders and dependencies. One thing I could see is that the CLI, when scaffolding your app, right away asks you whether you want to create it already ejected. Nevertheless a short documentation of the feature will be essential so that people really understand that they aren't loosing anything with the new approach and can always eject, to return to the old known way.

[plwalters]

Currently when starting a new project and using the aurelia-cli you are giving up configurability for convenience. It makes deciding to use the cli a bit of a gamble because once a project starts to grow larger or the team decides to tweak tooling it can be very tough to maintain a large cli project.

As mentioned before, at this point there should be a command in the cli which ejects and moves all of the tasks out of the cli and gives complete control back to the project, cli-free.