[#1164] move web_components line to dev_dependencies in the pubspec.yaml

[michilu]

In the context of #1164

Sorry, I do not know how to testing about this change.

[vicb]

I commented on the issue: I think that having web_components as a dependency makes sense as the code is used in WebPlatform and not only from the tests.

The better fix we can is probably to widen the version range but we should make sure there is breaking changes in the latest versions.

This is probably something that can be done after or as part of the current work @vsavkin is doing on improving the shim support.

[jbdeboer]

WebPlatform doesn't reference web_components explicitly. Instead, it uses js interop to check for platform.js.

+1 for moving web_components to a dev_dependency.

[vicb]

@jbdeboer does the fact that we're using js interop makes any difference ?

Let's say wc release X's platform.js solves our current issue by adding a new API (to enable scoping CSS with any selector not only the host tag name).

If angular does not depend on >=X, the user can have wc X-1 and then angular would not work for browsers that do not support wc natively.

(I am not sure what would be the result of calling an unimplemented method on a JsObject - at best it would not work but I guess it would rather throw an exception)

[vicb]

I'm 👎 on this being merged, I would have expected more discussion after my last comment.

/cc @mhevery @jbdeboer @vsavkin

[jbdeboer]

@vicb, you are describing a runtime dependency and pub deals with compile-time dependencies. There is not an issue here.

[vicb]

@jbdeboer to me a dep is a dep and there is no such things as hard / soft / runtime / compile-time deps for pub. But that's only words let's compare the 2 solutions:

wc as dep

• 👍 Users don't have to have wc as a dep in their own pubspec, everything will work out of the box,
• 👍 Users can specify an un-tested version of wc in their own pubspec.yaml (it would conflict with angular pubspec and woud not install),
• 👍 If users want an un-tested version of wc, they have to override a dependency. By doing this they know that they are doing something that might break things (and pub prints a warning message in such a case)

wc as dev dep

• 👎 User apps won't work out of the box if they don't explicitely add wc as a dep in their pubspec.yaml - actually "won't work" it a false statement, it might work depending on what browser their are testing with. "Intermittent" bugs,
• 👎 Users must add wc as a dep but they have absolutely no clue what version is required / tested and what versions fail.

I count +3 vs -2, but I'm probably a little bit biased :) Anyways I would love to hear more about your biased reasoning too.

[zoechi]

Users don't have to have wc as a dep in their own pubspec, everything will work out of the box,

If users reference a package in their own code they should have a direct dependency in their pubspec.yaml instead of depending on transitive dependencies. If a package maintainer decides to not depend on a package anymore the user code would break (a general rule learned from Dart team members).
As far as I know they need to add the script tag for web_components.js in their entry page. So they have a directly reference to the package in their own code.
This is not an argument against adding it in dependencies just against your argument why it should go into dependencies ;-)
Even when Angular has wc in dependencies the users should add it in their own pubspec.yaml anyway.

If users want an un-tested version of wc, they have to override a dependency.

I guess applications are usually not published, but pub doesn't allow to publish packages which use a dependency_overrides. Therefore I assume this is not meant to be used in production.

I guess a wide enough dependency constraint is the best way to avoid this problem anyway.

I assume this doesn't provide much help to make the decision easier.

[vicb]

As far as I know they need to add the script tag for web_components.js in their entry page. So they have a directly reference to the package in their own code.

I've preferred not to mention that to keep things simpler but I guess this could be done by a transformer (which would be active by default but users would be able to disable). There should be no need for users to reference something they don't use directly.

I guess applications are usually not published

You're right, they're not meant to be published so "I assume this is not meant to be used in production" is not applicable here.

I assume this doesn't provide much help to make the decision easier.

Nope, I'd like to be +1 / -1 for each cases.