Comments (20)
@MiguelMadero
from rfcs.
@stefanpenner Thanks for clarification.
from rfcs.
\w emberjs/ember.js#13022 landed, this needs to be restarted
from rfcs.
in broad strokes my thoughts are:
- remove last bower deps
- remove bower from ember-cli deps
- provide bower-compat module
- detect scenarios were it is required like
this.addBowerDependencies
, and auto-install the bower compat module, maybe with warning
from rfcs.
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
from rfcs.
@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.
from rfcs.
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.
from rfcs.
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)
from rfcs.
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)
from rfcs.
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.
from rfcs.
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.
from rfcs.
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.
from rfcs.
@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.
from rfcs.
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.
from rfcs.
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.
from rfcs.
... 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 import
ing 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.
from rfcs.
@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.
from rfcs.
Sounds good.
from rfcs.
@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.
from rfcs.
I think we're roughly where we want to be ;)
from rfcs.
Related Issues (20)
- convention for specifying browser support HOT 2
- Problems with standardized targets RFC #95 and javascript HOT 23
- configurable tmp directory [Docker] HOT 5
- Dropping ember data from the default blueprint HOT 1
- Making addon dummy apps less special HOT 10
- addon entry-point other than index.js HOT 5
- Public API to examine app dependencies from an addon HOT 3
- lib/broccoli/ember-modules-app HOT 4
- Generate Babel Helpers HOT 2
- Provide a way to skip import of add-on assets HOT 5
- Breaking "bugfixes" for an eventual 3.0 HOT 1
- Access to `app.options` is inconsistent HOT 3
- Configurable paths for Tree Paths HOT 5
- I'd like to discuss Webpack HOT 4
- Better server watchers HOT 10
- Expose API to customize and/or disable colors used in terminal output. HOT 1
- Import syntax should "just work" for ES6 modules available via npm HOT 17
- We need a better teaching & learning story. HOT 8
- Don't set license in app's package.json HOT 1
- Support in-repo commands by default. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rfcs.