Jacob MacDonald

So, this is a story as old as time, originating in a desire to launch a product quickly instead of correctly. The ability to skip the check was added in...

> There is no way to avoid this blanket restriction no matter how you architect your package if you aim to support native as well, you have to maintain two...

> It sounds to me like the check today is too strict: it is currently rejecting web programs that have native code in their transitive _packages_, when it could instead...

If flutter did not enable this by default without even so much as a warning, the number of flutter packages out there importing `dart:io` unconditionally would be significantly lower. They...

> Could we have a compile mode you can turn on where we replace `dart:io` with the platform-suitable package of your choice? Instead of doing this you should just use...

Note also that allowing people to replace `dart:io` or any core library with a package of their choice would make evolving the core libraries incredibly difficult - even more so...

If you want to ensure specific versions, I would just pin them in the pubspec instead of using version ranges. This has its own disadvantages, and I wouldn't do it,...

That is true that for transitive deps it is a pain to manually pin them, and just relying on pub to get an initial version solve is a lot easier....

The pubspec is the better source of truth (if present), so if we are going to look there I would trust that over the package config (this will also handle...

> A package repo can contain more than one `pubspec.yaml` file, fx in the `example` directory. If you run `dart pub get` in the root, it won't run it in...