We are faced with both the per platform problem and the general configuration problem. Neither can be ignored for too long. It is best to think of the two together. Solutions exist, but they need to fit in with the constraints of Dart and its user culture.

Set owner to @gbracha.
Added Area-Language, Accepted labels.

Marked this as blocking #13062.

Unmarked this as blocking #13062.

Since there's been no progress on this on the language front, we've decided (at Kasper's suggestion) to use the transformer infrastructure to handle it in pub.

Set owner to @nex3.
Removed Type-Defect, Area-Language labels.
Added Type-Enhancement, Area-Pub, Started labels.

Changed the title to: "Support cross-platform packages".

Marked this as blocking #20068.

This comment was originally written by @kaendfinger

@NweiZ Can you comment with an explanation of how this would work?

In the system I've been working on, imports of "dart:io" and "dart:html" would work on all platforms. All types would be available everywhere, but the implementations would throw UnsupportedErrors on platforms where they're unavailable. This may not end up landing, though.

Removed the owner.
Added Triaged label.

This comment was originally written by hach...@gmail.com

I would like this solution.

This comment was originally written by @radicaled

Who do we have to bribe and how much do we have to give them to get your implementation integrated?

Lars is ultimately the one who decides on the solution. He and Bob have been discussing it.

This comment was originally written by @Emasoft

Why throwing "UnsupportedErrors" when we can adopt a "polyfill" like approach to this, like we make with browsers? If a specific platform is missing some functionality, Dart should just emulate it. It should do it at the lowest possible level, to avoid too much abstraction, but it should do it for everything. Node.js is messy but is running on dozen of platforms and OS's now, and because of this its adoption is growing fast. Dart should be what Node.js is trying to be. The polyfill approach is what is going to make Dart succeed where even Java failed (too much abstraction) and where Node.js strives to achieve.

Polyfilling is a good approach for packages, but not for the core libraries. There's too much fundamental difference in capabilities; for example, the browser fundamentally can't support standard input or custom SSL certificates. This proposal allows packages to build their own polyfills with more restrictive APIs.

This comment was originally written by @Emasoft

Ok, but Dart should try to avoid throwing errors as much as possible. If STDIN or another device is not present it should not throw an error, but just return an empty, silent stream.
For all missing devices it would start listening but nothing will be heard because the device is not there. That way the code will retain its functionality and would not throw errors. Also device states Enumerators would be VERY useful to be included in all libraries for checking the presence of something before trying to use it, as good practice. For example this check could be a strongly reccomended coding practice:

 if( console.currentStatus == consoleStatus.DeviceNotPresent ) ... then ... doSomethingElse()

Custom SSL certificates can be generated in the browser to be used in Data Channels (the DTLS handshake performed between two WebRTC p2p clients relies on self-signed certificates), so the library to generate them should be always there.

If that's the behavior you want, you're welcome to implement a package that exposes it.

Bouncing this back to the language since the team decided pub wasn't the right place to handle it.

cc @lrhn.
cc @larsbak.
Removed Area-Pub label.
Added Area-Language label.

Marked this as blocking #21917.

Anything new on this issue?

This is still a big issue for libraries that want to use HTTP or WebSockets internally.

#24581

Right, you can do this with config-specific imports now.