RFC wanted: Migration plan off of bower.

[nathanhammond]

We need an RFC for the migration plan off of bower. This RFC should address:

• The transition story for the community.
• Ability to continue installing packages via bower.
• How to support the existing workflow so as not to require a major version bump.

Possible approaches:

• Compatibility addon?
• Just in time installation of supporting packages during the workflow?

Notes:

• Likely want to install our own local version of bower so we can control it.
• Can probably detect known likely failures:
  • ember init and blueprint depends on bower.
  • ember install and a dep has bower.

[stefanpenner]

in broad strokes my thoughts are:

1. remove last bower deps
2. remove bower from ember-cli deps
3. provide bower-compat module
4. detect scenarios were it is required like this.addBowerDependencies, and auto-install the bower compat module, maybe with warning

[Gaurav0]

Until Ember Twiddle has support for addons, we will be relying on bower compatibility for all dependencies, including ember and ember-data. cc/ @joostdevries @alexspeller

[stefanpenner]

@Gaurav0 unless I'm missing something that seems somewhat orthogonal to ember-cli providing bower by default or not, as ember/ember-data etc are committed to continue publishing to bower, the earliest they may change this is at 3.0, but if they will or not is undecided.

[Gaurav0]

@stefanpenner Thanks for clarification.

[MiguelMadero]

I think that in order to remove bower, it's important to make the NPM story better for CLI. Just the Ember CLI part, I'm not talking about fixing NPM's issues). For example, right now I can't app.import('node_modules/client-lib/my-lib.js') without having to funnel that first, which is a high barrier of entry.

[stefanpenner]

I think that in order to remove bower, it's important to make the NPM story better for CLI.

yes but that isn't a requirement to continue decoupling, bower will continue to be optional etc.

To address the NPM issue, the solution will be to resurrect @chadhietala's work, which we intend to actually do after we drop bower. As that was actually one of the biggest pain points for that effort (where ember/ember-data/loader/jquery etc came from)

[MiguelMadero]

How can we decouple (and migrate off of) bower if there is no easy way to
use npm?

Do you have a link or more info about Chad's work? Are you referring to the
packager/linker?
On Sat, Apr 23, 2016 at 9:23 PM Stefan Penner [email protected]
wrote:

I think that in order to remove bower, it's important to make the NPM
story better for CLI.

yes but that isn't a requirement to continue decoupling, bower will
continue to be optional etc.

To address the NPM issue, the solution will be to resurrect @chadhietala
https://github.com/chadhietala's work, which we intend to actually do
after we drop bower. As that was actually one of the biggest pain points
for us.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#41 (comment)

[stefanpenner]

bower if there is no easy way to
use npm?

People can still use bower, ember-cli just wont enforce it for any core libraries. The complexity was for libraries related to bootstraping the app, loader/ember/test stuff etc.

In the interim people can write wrapper add-ons, or us ember-browserify for top level deps.

Are you referring to the packager/linker?

yes, which basically just made browserify work at any addon level, and also made esnext flag "just work" on any level.

Post de-bowering, we will explore ^ again.

[MiguelMadero]

In the interim people can write wrapper add-ons, or us ember-browserify for top level deps.

That seems like a really high barrier for front-end NPM libs. I get the need for browserify for CJS modules, but what if something is using globals or umd? For example, getting lgtm from bower or npm is the same, with the exception that is really easy to consume it if we get it from bower, but we need to jump a few extra hoops if we get it from npm.

[stefanpenner]

For example, getting lgtm from bower or npm is the same, with the exception that is really easy to consume it if we get it from bower, but we need to jump a few extra hoops if we get it from npm.

lgtm seems to have jsnext:main here which means it would "just work"

Typically things on npm, work reasonably with browserify, or if they ship es6 esnext:main, which in both scenarios would "just work" with chads work.

Also note, bower support wont be provided by default, but it would exist as an addon. And when ember-cli discovers an addon that still depends on bower is used, it would warn but auto-install the compat add-on.

[stefanpenner]

@MiguelMadero you seem to be concerned about something, but migrating off bower (or leaving it) wont change your concerns. The state will remain basically the same, except that core dependencies will finally only use npm. Which will allow us to simplify the build, and let us resurrect chads work. (which this one aspect complicated quite abit), ultimately that work will give users a much better solution to your concerns then the current state.

[MiguelMadero]

lgtm seems to have jsnext:main here which means it would "just work"

I'm probably missing something here. Do you mean it will "just work" after Chad's work is ready? Or is there a way to do this today? AFAIK, we don't process anything from vendor trees, right?

All that said, I think the goal of this is different than what I was thinking. Sounds like the plan is to allow ember CLI to migrate off of bower and not (yet) to allow our apps to migrate off of bower. For that, I think Chad's work is the ultimate goal and there might other interim steps which we could discuss separately.

[stefanpenner]

Sounds like the plan is to allow ember CLI to migrate off of bower and not (yet) to allow our apps to migrate off of bower.

The default ember-cli install will not require bower, if users use bower stuff we will try to detect and install a an add-on that brings it back (aka "just work"). We will encourage (when possible) users to avoid, and then continue to improve the experience, with the long term goal of not requiring bower at all for anyone anymore.

[MiguelMadero]

... We will encourage (when possible) users to avoid...

I think this is the part that I think is important to cover and I was alluding to. Before we encourage users to avoid bower, I think we need to at least enable importing umd, amd and code using globals from node_modules just as easily as we can do it today from bower. Supporting esnext and processing is a step forward, but not supporting the others seems like a step backwards that will frustrate users instead of encouraging them.

[stefanpenner]

@MiguelMadero are you interested in fleshing out that material? As it seems valuable, but I also don't want to block this work on it.

[MiguelMadero]

Sounds good.

[MiguelMadero]

@stefanpenner I created an RFC for this. You can see it on MiguelMadero@0d9dfd5
After writing it I think we have enough alternatives that we can just wait for the final solution, but let me know if you think it's worth opening a PR and a discussion with a larger audience.

[dfreeman]

@MiguelMadero 👍 I hacked together an addon a couple months ago to eliminate all the funneling boilerplate in our internal apps/addons – it would be great to see first class support land in ember-cli itself, even if not in the immediate future

[stefanpenner]

\w emberjs/ember.js#13022 landed, this needs to be restarted

[locks]

I think we're roughly where we want to be ;)