Add sentinel libraries dart:cupertino and dart:desktop to allow for conditional imports in Flutter

[ohir]

Currently the only avaliable conditional import mechanics ("dart:io/dart:html") works reliably only to differentiate for web and !web targets.

As Flutter gained full desktop support I would ask to this being expanded to cover at least two additional target configurations, ie. dart:cupertino being avaliable for Apple's targets (macOS/iOS) and dart:desktop being available for macOS/Linux/Windows/Fuchsia targets - also, or especially, in AOT mode.

For Flutter ecosystem having just two (Cupertino/Material and Mobile/Desktop) knobs would allow developers to ship only platform relevant pieces compiled in.

Rationale: the conditional code preprocessing issue stays open for over 4 years now without a clear resolution in sight (what's understandable considering the scope). So while it would be better to have a kind of proper conditional compilation, or at least a kind of Go-style build constrains, reusing already present mechanics seems to be the least friction path.

Related: dart-lang/2133, dart-lang/1889, flutter/106950, flutter/23122.

[lrhn]

You don't need libraries to do conditional imports, just the compilation environment variables to switch on.

We currently only allow configurable imports to switch on dart.library.libraryName environment variables, but we could extend that to also accept, say, dart.platform.something.

It's absolutely not clear which granularity you need for platform detection. Or, rather, what you need is often not precisely what someone else needs.

With more granularity comes less code sharing, less ability to pre-compile for multiple platforms. That's the reason we don't currently allow free-for-all conditional imports on any compilation environment value - it would make modular pre-compilation much more expensive.

[ohir]

we could extend that to also accept, say, dart.platform.something.

Yes, please.

---

For now I myself, and likely quite a lot others trying Flutter on desktop, would be happy to have a reliable way to differentiate then not-to-compile unused on a given target platform UI code. Despite Flutter/Dart is truly multiplatform now, frontends must still often be fine-tuned per supported platform separately, as UX on desktop is paramount. This matters the most for backoffice type apps. Runtime detection is fine but should we really waste cpu cycles to compile and bandwitdh to ship never executing at given platform code?

It's absolutely not clear which granularity you need for platform detection.

As stated in the opening message: just two knobs of apple/not-apple and mobile/desktop would allow to exclude enough of unused UI. For now even accepting dart.platform.* env and instructing devs to use --define/--dart-define might be a good start. Yet better would be to have metadata based mechanics as dart:io/dart:html have.

I now feed config to a const bool then I may pray to compiler to not emit eg. if (desktop && linux) {} blocks. As of now the only way I can be reliably sure a piece of Flutter UI code does not ship is to maintain separate include trees then selected by a build --target=path invocation. This is more a quagmire to maintain in the long run. (That said, I am a relatively fresh incomer to the Dart ecosystem — had I missed other avenues?)

With platform dependent exports, I hope, we at least will have a chance to see the intended target of file's opened in the editor, then we may also implement unimplemented for platform compile-time guards.

(Some day dart:platform might even really provide us also with entry points to the intrinsic stuff like syscalls or winapi wrappers as an addition to the abstract stubs it offers now — orthogonal to this issue but mention worthy).

With more granularity [...]

I know the reasons, I have come to age on #ifdef swamps :)
Thank you.