chore: improve pubspec.yaml, remove pubspec.lock

[vicb]

replaces #1082

[jbdeboer]

No, pubspec.lock is useful and should remain.

We use the pubspec.lock to keep all developers on the exact same version of libraries and to ensure that bugs introduced in patch releases of dependencies do not break our tests.

[vicb]

Interesting argument, but:

• Dart recommendations is not to version pubspec.lock for libs (only for apps),
• More recent libs are less likely to be buggy (they are bug fix releases),
• The locking is effective only for core developers (the lock file is not taken into account when installing angular as a lib in an application),
• I personally do not wait for the pubspec.lock to be updated in the repo but often run pub update.

But I'm not opposed to keep it if you think it makes more sense - the other option could be to only list the dependencies which cause troubles there when any.

[jbdeboer]

I disagree with the "don't check in your pubspec.lock". While it isn't useful for distribution, it is critical for keeping the dev team in sync and providing a record of which exact versions are tested at which SHAs.

Without the pubspec.lock, we are letting other packages potentially break our tests -- yet we are responsible for the tests and should be the only people breaking them.

A compromise would be to write a bot that runs pub update on a regular basis and updates the pubspec.lock if the tests pass.

[vicb]

No need to spend so much effort on this. I'll re-add the file.

[vicb]

@jbdeboer I have updated the PR to re-add pubspec.lock.

I originally update the web_components deps to web_components: '>=0.3.3 <0.5.0' resulting in v0.4.0 being used. However this breaks web_components_spec.dart - this is probably something that needs to be investigated at some point. (I have reverted to the original "<0.4.0" in this PR)

[jbdeboer]

LGTM

The Travis failure is expected, but let @chirayuk merge this PR.

[jbdeboer]

And the failure in web_components_spec.dart is #1289 , the test was already failing.

It should be ok to upgrade web_components to 0.5.0, I will fix the test independently of this PR

[vicb]

Could you ping me when it's fixed... could also explains some failure I had with IE/Safari

[jbdeboer]

Test and rebase before we can merge.

[vicb]

Fixed & rebased. Travis is unhappy due to a g3 conflict only.

[vicb]

@jbdeboer does #1337 makes you change your mind about the need to list web_components as a regular dependency (instead of a dev one ?).

Edit: 1337 says that we need wc 5+ when using ff.

[jbdeboer]

@vicb, web_components should be listed as a dependency of the example.

[vicb]

I have updated examples & benchmark deps

[vicb]

@jbdeboer I'd like to update DI to the freshly released 3.0.0, could I do this as part of this PR or would it be better to submit an other one (wrt g3) ?

[naomiblack]

Not in scope for this PR.