Depends on rxjs as dependencies

[lacolaco]

Currently, this project uses npm v3. That's great!
But, there are still peerDependencies in https://github.com/angular/angular/blob/master/modules/angular2/package.json .

In npm v3, peerDependencies are no longer installed implicitly.

Contributors can install those as dependencies from package.json on root, but users cannot. I must execute commands; npm install --save angular2@2.0.0-beta.1 rxjs@5.0.0-beta.1 reflect-metadata es6-shims es6-promise zone.js . It's not happy for developers.

I'd like to install only angular2 explicitly. I think many developers are also thinking so.

[lacolaco]

ES6 polyfills (es6-promise and es6-shims) may not be needed in some cases. Maybe these does not have to be dependencies.

Angular2 polyfills (zone.js and reflect-metadata) also are not always needed because there is angular2-polyfills.js .

But RxJS have to be installed always explicitly. This should be dependencies.

[lacolaco]

@btford Hi. How are you thinking about this?

[cebor]

👍

[ovrmrw]

+1

[okunokentaro]

👍
It's really tough.

[lacolaco]

#7001 could be prevent if rxjs were dependencies, I think.

@mhevery @IgorMinar I want you to think about this thing.
cc. @alexeagle

[alexeagle]

#7001 is simply tracking that changes are needed in angular 2 for us to work with the latest rxjs, not related to how the right node_modules structure ends up in your project.

See #5560 where we decided to make these peers.

@IgorMinar has written elsewhere about the reasoning for these peerDependencies - essentially it is that these are all API-level dependencies on upcoming EcmaScript standards (eg. reflect-metadata is already coming in es7, zone.js is TC-39 stage zero, rxjs is next) and so you could choose whatever implementation you want. Angular just wants you to bring some implementation for each of these standards. Also, you should use the same version of the peerDependency everywhere.

We think the right fix is to add an npm option that lets you opt-in to explicitly installing the peerDependencies that angular requests.

[lacolaco]

@alexeagle I agree on your opinion about es6 shims. But I think it should not apply on RxJS.
RxJS is just JavaScript library. And it's under developing as beta version. so it's unstable dependency.
Users can mistake easily to install wrong version RxJS.

If angular2 keeps peerDependency for RxJS, I think that to install it on postinstall of angular2 is one of the way.
What do you think this idea?

[alexeagle]

I don't even know if we've filed an issue with npm for the behavior we want.
I think something like a postinstall script in your project that looks
through your installed deps and installs their requested peers is closer to
correct.

On Tue, Feb 16, 2016 at 7:33 PM Suguru Inatomi notifications@github.com
wrote:

@alexeagle https://github.com/alexeagle I agree on your opinion about
es6 shims. But I think it should not apply on RxJS.
RxJS is just JavaScript library. And it's under developing as beta
version. so it's unstable dependency.
Users can mistake easily to install wrong version RxJS.

If angular2 keeps peerDependency for RxJS, I think that to install it on
postinstall of angular2 is one of the way.
What do you think this idea?

—
Reply to this email directly or view it on GitHub
#6659 (comment).

[lacolaco]

Okay, I can understand it. It's really correct but I'm worried if it is not friendly for beginners.
During angular2 is still in beta, this is a small problem. But in the future or soon, many people may have questions or issues like #7001.

[lacolaco]

If RxJS will be stable, my worry is unnecessary. I hope it. :)

[IgorMinar]

We decided to use peerDependencies rather than dependencies for all of our dependencies for several reasons, all of which are aimed at giving developers more control and flexibility over the dependency graph.

All of the peer dependencies as required today are expected to be provided by the runtime and compile-time environment to Angular 2 (as opposed to Angular loading these dependencies during boot time).

Let's take a look at all of them and discuss what I mean by the statement above.

• es6-promise - this is a polyfill that Angular requires to be provided by the environment. Due to a hack in zones.js we currently require this polyfill even when browsers provide native implementation of promises. This hack will go away when Angular 2 is upgraded to the next version of zone.js. Afterwards we expect the need for this dependency to go away once promises are implemented in all ever-green browsers we support.
• es6-shim - this is a polyfill that Angular requires to be provided by the environment. This polyfill monkey patches the global context (window) so we definitely don't want Angular to do this as a side-effect of loading Angular. We also want people to have a flexibility to use other polyfill implementation providing the same APIs (e.g. core-js). We are expect this dependency to go away once all ever-green browsers we support have all the APIs required by Angular available.
• reflect-metadata - this is a shared dependency between Angular and TypeScript compiler. Since we want users to have the flexibility to update to a new version of TypeScript without upgrading Angular, it's important that this package is a dependency of the application and not a dependency of Angular.
• rxjs - this is a prolyfill for Observables specification that is being standardized by TC39. Once again, we want developers to be able to control which version of rxjs to use (within a compatible version range) and not have to wait for Angular releases to receive bug fixes and new features.
• zone.js - this is a prolyfill for Zones specification that is being standardized by TC39. Once again, we want developers to be able to control which version of rxjs to use (within a compatible version range) and not have to wait for Angular releases to receive bug fixes and new features.

Now all of the polyfill dependencies, should ideally by just a suggestion or a hint to developers so that they know what Angular expects, but they should not be a hard requirement as they are today. There is an npm feature request for "optional peerDependencies" which would allow us to model this relationship better. Once implemented, Angular will switch over to using these optionalPeerDependencies rathern than peerDependencies for all polyfills.

[IgorMinar]

@wardbell could you please incorporate the information in the above comment into our docs in some suitable way? Thanks! (angular/angular.io#848)

[lacolaco]

@IgorMinar Thanks to very kind explanation. I finally understood your decision and purposes.
I never worry if there is the above documentation.

[okunokentaro]

I see! got it. Thank you.

[wardbell]

@IgorMinar It's on its way. See angular.io PR #852

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}