ember-cli-update should be ember update

[mehulkar]

Updating complex apps and addons is difficult and making it a more core feature of the CLI tool will be very useful.

[wycats]

I think this is a good idea. I wonder what it would look like to document this in the guides as a core part of the workflow for everybody. I think it would help to see something like that fleshed out, even in outline form.

[rwjblue]

FWIW, I don't know that I agree that we should make ember-cli-update fundamentally tied the the CLI tool that also bundles the thing being updated. In most cases you always want the most recent version of ember-cli-update, but making ember update work would mean that you are tied to using an older (and possibly buggy) version. 🤔

[NullVoxPopuli]

Taking that to the extreme, should ember-cli be a lil'wrapper script that npx's the real CLI? So that people get the latest bugfixes?

[wycats]

@NullVoxPopuli I was going to say something to that effect. But isn't this already how ember-cli works? I thought the only time that we use the actual installed Ember CLI is when you're creating a new app (and ember update is run in the context of an existing app).

[NullVoxPopuli]

I mean, I have no clue. Lol

[mehulkar]

@NullVoxPopuli is asking for the opposite of what happens. Currently, the local version of ember-cli is used if its available. To avoid the problem @rwjblue is talking about, we'd want to always favor the global version (or more accurately, the remote version) of ember-cli for updates so that it could use the latest version of the update command.

[wycats]

TL;DR There are many ways we could make ember update work without putting the source code for the command in ember-cli, which I agree we should try to avoid.

---

There are a few pieces of this:

• the version of ember you installed globally
• the version of ember you installed in package.json
• the version of ember-cli-update to use to upgrade from one local version of ember to the next
• the version of the blueprints to use

the version of ember you installed globally

As far as I can tell this is not relevant here.

the version of the blueprints (or the version of ember-new-output) to use

This is already something that is versioned outside of the ember-cli itself

the version of ember-cli-update to use to upgrade from one local version of ember to the next

This matters if we made improvements to the ergonomics of the upgrading process, but is not necessary to get new versions of the blueprint to use.

Because people already upgrade ember-cli as they upgrade Ember, the problem we're talking about here doesn't feel particularly different than being behind on any other aspect of ember-cli.

the version of ember-cli you installed in package.json

As far as I can tell, this is not relevant to this question.

---

I think that @rwjblue's desire to avoid coupling the updating process directly with the tool that you're updating is reasonable. I also think it's avoidable, even if we want ember update to work.

First, we could adopt a strategy like git or cargo subcommands (so that ember update wouldn't need to be distributed with ember-cli). In our case, that would also mean using node_modules/.bin/ember-cli-update when the user invokes node_modules/.bin/ember update (directly or indirectly through yarn or via package.json scripts).

If we don't do that, we would still have a few options for allowing users to upgrade to a different version of ember-cli-update while making an ember update subcommand:

• As @NullVoxPopuli suggested, we could prefer the global ember-cli for the ember update subcommand. I think this is not ideal, because it relies on the user installing something globally as a part of the workflow. It's not terrible, but I also think it's not necessary.
• Alternatively, we could hardcode the update subcommand in ember-cli to delegate to the local version of ember-cli-update. This would allow users to update ember-cli-update in their package.json first, and then get any updates when they use the ember update subcommand. This is sort of like the idea of git or cargo subcommands, but with a specific allowlist for commands we want to support.

[wagenet]

I'm closing this due to inactivity. This doesn't mean that the idea presented here is invalid, but that, unfortunately, nobody has taken the effort to spearhead it and bring it to completion. Please feel free to advocate for it if you believe that this is still worth pursuing. Thanks!