Support cross-platform packages

[DartBot]

This issue was originally filed by ladicek@gmail.com

---

I know that Dart wants to solve environment-specific libraries somehow, see for example the notes from November 5th language design meeting. Here is my proposal that I also posted as a reply on the list.

---

This isn't about a general facility for configuration-specific code, but only for code that varies between different Dart execution environments. I've always believed that solving this on library level would be good enough. Having one 'browser' and one 'standalone' library and being able to import them in a unified way, that solves a lot of issues.

And thinking about it more, it would totally suffice to only modify the 'export' directive. Look at this:

awesome_lib_browser.dart:
...

awesome_lib_standalone.dart:
...

awesome_lib.dart:

library awesome_lib;

export 'awesome_lib_browser.dart' if in 'browser';
export 'awesome_lib_standalone.dart' if in 'standalone';

I would be able to write

import 'awesome_lib.dart';

and get awesome_lib_browser.dart imported in the browser or awesome_lib_standalone.dart imported in the standalone VM. (Note that I'm specifically not using the term VM, because the VM can be both in the browser and in the standalone environment.)

Semantics: the Dart compiler always knows what execution environment it targets (in case of the VM, I'm not sure if the embedder takes care of exports in the same way it takes care of imports, but I guess it could), so it only processes those exports that are appropriate and ignores all the other ones.

It would be possible to add similar clause to 'import' (and it would make them more symetric), but I believe that adding it only to 'export' is sufficient.

Notice that it looks like english sentence and I didn't have to add any new keyword :-) Also, this allows for additional execution environments (like Dart on JVM), but I'm not sure if that is necessary.

[gbracha]

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.

[nex3]

Marked this as blocking #13062.

[peter-ahe-google]

Unmarked this as blocking #13062.

[nex3]

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.

[nex3]

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

[nex3]

Marked this as blocking #20068.

[DartBot]

This comment was originally written by @kaendfinger

---

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

[nex3]

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.

[DartBot]

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

---

I would like this solution.

[DartBot]

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?

[nex3]

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

[DartBot]

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.

[nex3]

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.

[DartBot]

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.

[nex3]

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

[munificent]

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.

[nex3]

Marked this as blocking #21917.

[stevenroose]

Anything new on this issue?

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

[zoechi]

#24581

[munificent]

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