Update pubspec for Dart2

[ConProgramming]

Could the sdk version for the pubspec.yaml be changed to ">=1.20.1 <3.0.0"?

[aspantel]

Hi there. We're migrating our Angular app (Chrome extension) to Dart 2 and the chrome package becomes a show stopper. Any suggestions/workarounds? Are you planning to correct pubspec any time soon? Thanks

[adambender]

I replied over on another issue but I will just say here, we are sorry we haven't gotten to these sooner. This project had really low traffic for a while (everything was nice and stable :) ) and we haven't done a good job waking up from hibernation. We will get an answer for you on the Dart 2 stuff asap.

[adambender]

Alright, had some time to take a look today. It looks like we are dependent on two other libraries that both require updates: unscripted (probably not critical) and parsers (critical). Unfortunately, neither of these may look like they will be getting fixed soon. I will continue to try looking for work arounds. If anyone is interested in lending a hand let me know.

[ghost]

We tried to create a new interop package around chorme.* APIs using new package js without using dart:js and IDL files.

https://gitlab.com/drbcode/chrome.dart
https://gitlab.com/kleak/chrome.dart

I feel like above approach is the right approach and if we follow this then it will make code more readable and allow contributions from a lot of developers.

Right now I'm using a package that follows above approach and has full support for APIs that are used by my own chrome extensions.

[adambender]

@drbcode Interestingly enough this is the pattern being adopted by a lot of teams inside of Google as well (since we use this package a fair amount). With the arrival of package:js maintaining interop boundaries with Chrome got a lot better and for future projects that is a very reasonable way to go. Depending on how bad the Dart 2.0 fixup is, and if you only use a few APIs you can get up and running really quickly. You may run into problems with this approach if you use many Chrome APIs (20+) because the maintenance may drown you. For projects like that, being able to autogenerate APIs from the IDLs is very useful. In truth I dont have a good sense for how many users of this library are in that situation. For those that aren't, pacakge:js puts you more in control of your destiny (you no longer depend on a third-party project) and that is a good thing.