search

ember-cli / rfcs

Archive of RFCs for changes to ember-cli (for current RFC repo see https://github.com/emberjs/rfcs)
45 stars 54 forks source link

RFC wanted: Migration plan off of bower. #41

Closed nathanhammond closed 7 years ago

nathanhammond commented 8 years ago

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

Possible approaches:

Notes:

stefanpenner commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@stefanpenner Thanks for clarification.

MiguelMadero commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/ember-cli/rfcs/issues/41#issuecomment-213857524

stefanpenner commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

... 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 commented 8 years ago

@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 commented 8 years ago

Sounds good.

MiguelMadero commented 8 years ago

@stefanpenner I created an RFC for this. You can see it on https://github.com/MiguelMadero/rfcs/commit/0d9dfd5ee040fbbe9c8053bbf1eccdb8700175e1 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 commented 8 years ago

@MiguelMadero :+1: 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 commented 8 years ago

\w https://github.com/emberjs/ember.js/pull/13022 landed, this needs to be restarted

locks commented 7 years ago

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