Skipping compiling with dart2js because some of its transitive libraries have sdk dependencies that are not supported on this platform:.

[MichealReed]

Asking here first per dart-lang/build#4179 (comment)

CC and thanks to @davidmorgan

There should be a way to override the unsupported platform check. dart-lang/build#2200 (comment) mentions flutter has this disabled, how?

The code paths in my library have no problems with web yet I cannot use webdev serve to compile a js library.

dart-lang/sdk#50181

Many parts of analyzer work on web yet it seems to be blacklisted. How can I force this to allow a package through and compile the code?

If I dart2js then webdev serve, even though webdev serve skips building, the file built through dart2js works. If I must use dart2js, how can I fully package all the dart dependencies? These packages work fine in flutter too, so I should be able to build them with webdev serve.

[nshahan]

Can you clarify what you are asking for? Are there libraries that your application depends on that webdev reports are invalid for the web and blocks compilation? Can you provide the specific libraries that are are having problems with?

[MichealReed]

Can you clarify what you are asking for? Are there libraries that your application depends on that webdev reports are invalid for the web and blocks compilation? Can you provide the specific libraries that are are having problems with?

@nshahan the restrictions between webdev and dart build js are inconsistent.

The best example is probably the analyzer package which https://pub.dev/packages/dart_eval depends on, it has many paths that can work on web.

Webdev needs to allow an override to stay consistent with dart2js instead of skipping all compilation off of basic library presence detection.

[Markzipan]

It appears we removed the ability to skip platform checks here: dart-lang/build@6a93e68

Maybe @jakemac53 has additional context?

[jakemac53]

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 only for flutter web, as soon as flutter web stopped using build_runner we removed the unused functionality. I believe the dart2js/DDC support also was only added to support the flutter web launch because the flutter web team asked for it.

It is my strongly held opinion that the support for compiling dependencies with dart:io or other unsupported imports should have never existed, it opens up your application to arbitrary runtime errors that cannot be caught at compile time. Some library could at any time start using a function from dart:io without warning and you would be broken, even if your code happens to work today. Or maybe you just have some edge cases which aren't tested on web (but are tested on other platforms) and so they only fail on web and only at runtime after you deploy to your users.

The fix here is to ask for platform independent libraries to import from the analyzer team.

Unfortunately, if we have this flag, then the vast majority of users will just end up using it instead of keeping the ecosystem and their own code platform agnostic, or separating out their libraries in such a way that the platform agnostic parts can be imported separately.

Unless there is some huge outcry from a very large number of users over this, everybody is better served by not allowing this, it forces the ecosystem as a whole to be better.

[MichealReed]

I understand the choice to restrict this but disagree, developers should have the choice as it is entirely possible to use a library with restricted dependencies with flutter. The behavior is inconsistent with flutter, giving flutter a competitive advantage over other frameworks that want to develop on dart. The restriction is superficial in that it does not actually analyze if the code path would generate an error on a given platform, but instead broadly restricts without override. If a dev can build using code paths that do not cause errors or conflicts and test these paths, I should be able to compile/use the code.

I do agree that it would make more sense if dart provided core libraries that gracefully fail on unsupported apis to all platforms. Precedent for at least IO has been established with https://pub.dev/packages/universal_io, but I cannot refactor analyzer or other third party packages that use IO (intentionally working still on web).

Always better to give users a choice than to police the ecosystem with a presumptive restriction. It's the developer's responsibility to test their code on the provided platforms and not many devs are compiling to JS these days anyway, I do not see how webdev supporting an override would pollute the ecosystem much if at all.

Essentially this does more to restrict those that want to produce a JS package from the dart package ecosystem than it helps to keep the dart package ecosystem clean. My intended use is to offer a JS SDK using dart packages, not to produce a JS bundle published in a dart package.

[nshahan]

If I understand your request correctly, you would like a mechanism to allow compilation of applications that contain imports of libraries that are not supported on the target platform. I'm going to keep this issue open but we don't expect to add support here at this time. Please feel free to 👍 if you discover this issue and also need the support so we can track this need.

I understand this is confusing since you can observe some tools supported by the Dart and Flutter teams allow this but the inconsistencies are simply an example of long term technical debt that one day we hope to clean up. It is extremely difficult to clean up usages that have proliferated through the ecosystem but we still believe it is a useful goal to work towards so new tooling, compilers, and infrastructure can be built without having to implement bespoke support for unsupported libraries.

The recent history of the Dart language has been to move more errors from runtime to compile time (examples: Dart 2.0 static type system and 2.12 null safety). Similarly, rather that allowing a platform unsupported library to be compiled into an application and cause runtime errors we have opted for a library level granularity for supported platforms.

Always better to give users a choice than to police the ecosystem with a presumptive restriction.

I wish it was that easy. In practice, our teams have found success in trying to find the delicate balance of choice, guidance, and sometimes enforcing prescriptive decisions. User feedback is helpful here, thank you for this issue and discussion. There have been many users confused by how some APIs in an unsupported library can work while others mysteriously fail at runtime without any warning or documentation.

It's the developer's responsibility to test their code on the provided platforms

And it is our job to help make this as easy and intuitive as possible. Currently there is no mechanisms to tell users if an API is supported on any given platform other than writing code that exercises the API fully and test it. It could be argued that member level granularity would allow more code to compile and run but supporting that would put the burden on all package authors to define and document support for every single API and ensure that stays correct even when code they depend on changes. There are not any mechanisms currently to make this possible aside from the library level support.

Maybe this should be a language level request for a mechanism to formally define platform support for a package, library, or some other granularity.

[MichealReed]

If I understand your request correctly, you would like a mechanism to allow compilation of applications that contain imports of libraries that are not supported on the target platform.

Not quite, even with proper stubbing to prevent the application from accessing unsupported apis in those libraries, the general restriction denies the compilation for the webdev tool but not dart2js. It's not a matter of trying or allowing it to compile unsupported paths, it's a matter of if the library is included at all for native support, it cannot be compiled with the webdev tool. 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 entirely separate dart packages, one for web, one for native, requiring developers of apps to do the same, overall worse for the ecosystem. With this decision you are asking developers of packages to choose support for native or web and as mentioned this only applies to the dart ecosystem, flutter ignores this check entirely and compiles mixed packages given they are properly stubbed.

Hopefully the unwillingness to support an override flag is reconsidered until the strategy regarding packages is fully defined. The technical complexity of supporting a flag that was previously available seems minor compared to ironing out the graceful failure of native APIs on web.

I do not think many will stumble on this issue as there are few compiling dart to JS outside of flutter. It is not such a common use case to produce a JS SDK from a dart package, but it could be if not so restricted.

[jakemac53]

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 entirely separate dart packages, one for web, one for native, requiring developers of apps to do the same, overall worse for the ecosystem.

While we don't make it easy, it is very much possible to write a platform agnostic package, which has a single import yet works on all platforms it supports (either through dependency injection or conditional imports).

The problem is pushing the ecosystem to actually develop in this way. When we introduced this check originally, there was initially some pain but we did manage to get the entire (angular at the time) ecosystem migrated to use these patterns including all their transitive dependencies.

but I cannot refactor analyzer or other third party packages that use IO (intentionally working still on web).

Have you filed an issue on the analyzer?

The analyzer was never designed to be used on the web and does not support the web today. It might happen to run on the web if you inject a special file system etc, but that is mostly just by accident and general good library design (which allows you to inject custom file systems etc).

[MichealReed]

While we don't make it easy, it is very much possible to write a platform agnostic package, which has a single import yet works on all platforms it supports (either through dependency injection or conditional imports).

Yes, it is possible and I have published several packages that support both, a platform interface or stubs can be used. The problem here is that webdev does a nested dependency search and cares nothing about the proper way to build packages with both.

The analyzer was never designed to be used on the web and does not support the web today. It might happen to run on the web if you inject a special file system etc, but that is mostly just by accident and general good library design (which allows you to inject custom file systems etc).

Analyzer was the example, this problem exists for many packages. It does a nested search for any banned dependencies and prevents compilation regardless of the actual code paths used. If I use a package that includes IO in a stub or a platform implementation, webdev will just prevent compilation to JS.

The majority of packages in dart that compile to JS are for flutter, flutter skips this check and allows the libraries like IO so it would go unnoticed by anyone developing for Flutter. The problem arises when I try to compile a package that has both native AND web paths using webdev. It simply will not allow it because it stops when it detects a native dependency regardless of the actual path used, EVEN in nested platform specific packages. I cannot skip this check. This means I must use dart2js to compile my dart dependencies to JS outside of flutter or maintain a separate web package to superficially satisfy webdev or only use dartjs. The current check and inability to provide an override flag prevents packages from compiling with webdev to JS if there is even mention of the wrong package in nested platform specific package dependencies.

If I stub with conditional imports native/web packages, webdev will fail. If I create separate packages entirely for native and web, webdev will fail because a banned package is detected in the pubspec, even if that particular package is not used.