Build: Would like to completely disable unsupported module check

[jonahwilliams]

Initially I though that selectively disabling the unsupported module check would be sufficient to carry us forward until we could either remove dart:io or make a decision on what core libraries would be sufficient. Unfortunately, in the meantime many more people than expected are hitting issues and unsure of how to proceed, usually when attempting to port already working android/ios applications to the web. When trying to track down issues, I've personally found that runtime failures are much easier to debug.

I would like to support removing the check through a configurable option in bootstrapDdc, and any other places it is implemented

[jakemac53]

We can add an option to omit the check - I can see how it would make it easier to find the places where you are actually using dart:io.

Long term I do think disallowing it is the correct approach.

Is the problem here that the message isn't clear enough (or not working at all), or that conditional imports are to difficult to use, or something else?

[jonahwilliams]

I think its a combination of problems:

• conditional imports are _really_ hard to use correctly.
• transitive dependencies may contain dart:io, which sort of leaves the user stuck if they don't depend on it.
• The concept of unsupported libraries is not really well defined to our users, we'd have to spend a lot of time explaining it.
• Multiple entrypoints muddles things a bit too.

Long term is somewhat separate. We have a lot of plugins that use dart:io so we obviously need to do something

[jakemac53]

transitive dependencies may contain dart:io, which sort of leaves the user stuck if they don't depend on it.

Ya, this is definitely a hard problem. These are presumably real errors in most cases though. These packages ideally would be migrated to actually support the web.

I can see how it would be much easier though to guard usage of such libraries with imperative code based on Platform than resolving it with conditional imports. There are downsides to this approach too though, both in terms of code bloat and runtime failures.

Also note that it is really only dart:io (and mabye dart:isolate) that claim any support (even though they are 99% just throwing stubs). Any other libraries would still cause problems. But, these are almost certainly the most common.

• The concept of unsupported libraries is not really well defined to our users, we'd have to spend a lot of time explaining it.

I think this is an important thing to understand though if you want to deploy to multiple platforms. I don't really see any way around that which doesn't cause other problems.

• Multiple entrypoints muddles things a bit too.

This should hopefully be helped with the build-filters stuff, so you can just build one app at a time.

Long term is somewhat separate. We have a lot of plugins that use dart:io so we obviously need to do something

Do we have any idea what portion of those actually do anything useful on web today?

[natebosch]

This used to be the behavior of dart:io, it would silently compile code that would throw at runtime. We intentionally changed it because it's a better UX to learn at compile time that something won't work than at runtime.

There _are_ cases where you avoid certain code paths at runtime and can get by just fine, but we also have a lot of users hit confusion when they _don't_ avoid those code paths and then their code throws. Dart as a whole has moved towards static checking from runtime checking. It feels non-Darty to me to silently allow you to compile code that will never work.

[jakemac53]

While I agree with @natebosch I do think its fine for us to expose this feature given that it is supported by the compilers and our underlying apis probably shouldn't be this opinionated.

[jonahwilliams]

To sum things up briefly, we're definitely working on the dart:io issue, but there are a lot of moving parts and no one has made any decisions. Even though the compilation error should be easier to deal with, it leads people to trying to use config specific imports which I think are actually harder to use.