Get rid of ember install

[mehulkar]

I’m not entirely clear why we have ember install, but it seems like it just narrows the search for packages by the ember-addon keyword?

Regardless, I think it’s an unnecessary learning hurdle and we should just use npm/yarn to install packages.

(Tangentially related, ember-auto-import has also probably reduced some of the value add of addon packages, meaning that more packages are probably being installed directly now).

[Panman82]

ember install also runs the default blueprint, which is used quite a bit by addons that wrap other libraries, to install a dependency in the consuming app.

https://ember-cli.com/extending/#default-blueprint

[buschtoens]

...or to create configuration files, etc.

[jrjohnson]

I agree that ember install is a confusing extra addition to the learning experience, especially since ember-auto-import is going to have more ember devs doing npm install as well.

It also papers over the difference between yarn and npm install. I wonder if we focused on NPM if we could script the blueprint stuff out in a post/preinstall script. I also think that adding dependencies in this way should probably be an anitpattern. If your addon needs the deps then it should install and mange the versions, adding them to my app just gives me one more thing to worry about.

This additional tooling is one of the weirdly heavy parts of adopting ember when you're already an experienced user of other JS frameworks.

[buschtoens]

@jrjohnson

If your addon needs the deps then it should install and mange the versions, adding them to my app just gives me one more thing to worry about.

I am not saying this statement is wrong and I sonewhat agree with it, but sometimes the dependency needs to be defined in the host app, like with peer dependencies.

[mehulkar]

Could running the blueprint also happen with npm postinstall?

[rwjblue]

The semantics of postinstall are quite different. postinstall is ran every time you npm i / yarn in the repo, whereas ember install foo runs the blueprint once when you invoke it.

[rwjblue]

Regardless, I think it’s an unnecessary learning hurdle and we should just use npm/yarn to install packages.

How is it a hurdle, please explain? It removes the need for every addon to have examples like:

If using npm run:

npm install --save-dev foo
ember generate foo

If you are using yarn run:

yarn add foo
ember generate foo

it seems like it just narrows the search for packages by the ember-addon keyword?

Ya, I think this is the only thing to change here. Making ember install lodash-es work (and use npm if the project is using npm or yarn if it is using yarn) seems better.

[miguelcobain]

The semantics of postinstall are quite different. postinstall is ran every time you npm i / yarn in the repo, whereas ember install foo runs the blueprint once when you invoke it.

npm docs mention that the postinstall script is ran "after the package is installed": https://docs.npmjs.com/misc/scripts

The way you phrased it makes it sounds like anytime you install something, postinstall script will run. Please correct me if I'm wrong.

[jrjohnson]

@rwjblue you and @locks convinced me thoroughly that #448 was necessary because NPM was already the community default. In that case I would argue that addons do not need to provide instructions for yarn, anyone choosing to use yarn will be able to do so, and the extra instructions are just noise.

The hurdle is in learning anything here at all. npm install is a known quantity. If I come from anywhere else in JS and node I will probalby be very familiar with this command and its options, if I'm using something like oh-my-zsh there will be a plugin and shorthands for me to use. The new-to-ember devs I've worked with stumble over this. It's not a big stumble, but its a minor annoyance that adds to the opinion that ember is not up to date with the JS world and learning it might not be worth it.

[Panman82]

@miguelcobain right, but if you delete your node_modules and npm install to re-install everything, then the postInstall hook will trigger again. It may or may not be desirable to have the default blueprint run again in these cases. Since ember install is only needed for the "first" installation, the default blueprint only runs once. If the default blueprint runs upon each npm install, it could potentially wipe out any changes made after the initial install, by re-applying things in the default blueprint.

[mehulkar]

1. I wonder how many addons actually define a blueprint that runs on install.
2. The need to document that users have to run a post installation step is not the end of the world IMO, since it at least brings us back into npm land.

On a higher note, I think it would be really great to align with the larger JS community and treat ember addons more like regular npm packages. The special sauce of an addon is the merge behavior at build time, and we would still have that.

[Panman82]

1. I wonder how many addons actually define a blueprint that runs on install.

There are 1,077 that have normalizeEntityName(), which is a (unintended) requirement for a default blueprint (I believe anyway).

https://www.emberobserver.com/code-search?codeQuery=normalizeEntityName&sort=score&sortAscending=false

[davewasmer]

1. I wonder how many addons actually define a blueprint that runs on install.

A significant portion do, and the functionality that the default blueprint provides in these cases is not easily replicated through other means. Just randomly scrolling through the top addons on Ember Observer, at least 3 of the top 25 use a default blueprint.

Personally, I'm quite sympathetic to the idea that dropping things like ember install would lessen the learning curve and unfamiliarity factor of Ember.

However, there are concrete, significant benefits ember install brings to the table as mentioned in this thread. @mehulkar do you have a suggestion of what would fill this gap? Is it just the two step install, npm install and ember g addon-name? If so, I'm not sure what that buys us, and comes at the cost of reduced convenience and consistency.

[Panman82]

Perhaps there is a way to have a (default) postInstall script run and detect if the default blueprint (if one exists) is applied already, and apply it if not.?.

For example, creating a new addon would result in a pre-defined postInstall script added to the initial package.json file. That script is something that ember-cli provides as part of an addon, and automagically runs the default blueprint if one exists and sets a flag somewhere (not sure where) that it was completed. Upon next run, the script sees that it already had ran the default blueprint and just exists.

[jrjohnson]

The blueprint process is great for first installs, but breaks on updates so while it is amazing I don't see it as a blocker in it's current state. Maybe moving to a more standard postscript process would open up some options for managing the complication of blueprint changes being applied to the app when updated.