Repository navigation
Add an option to skip the platform check for specific packages - #2420
Conversation
Flutter web must allow some `dart:io` import in `package:flutter`, but adding `dart:io` to the `DartPlatform` causes the module crawling to pick the imports in some cases - we want the `DartPlatform` to match the `libraries.json` that will be used by DDC and kernel.
grouma
left a comment
There was a problem hiding this comment.
I trust this is the correct thing to do but can you add some more context? I don't follow why libraries.json contains the valid information to make this work.
|
Friendly bump :) |
This seems like the core issue? Can we not remove those imports (or hide them behind conditional imports?) |
|
It's not a trivial change: flutter/flutter#38773 |
I updated the first comment on the PR and will make the commit message match.
In the long term I hope we will so that we can restore the build system restrictions on imports since it's friendlier to users. In the short term I think this is the right change. |
|
We could potentially make it take a whitelist of packages to allow these imports in instead of disabling the check entirely? I am concerned people will be really confused when their app starts throwing at runtime due to some transitive dep that is trying to use dart:io.... |
|
@jonahwilliams - I'll take a stab at adding a |
|
As a short term solution, either should be fine. As for the long-term behavior of build_runner/ddc in the presence of dart:io/unsupported libraries, I'm not convinced that the current build_runner behavior is any less confusing than the resulting (potential) runtime exceptions. I think this behavior should be re-evaluated and potentially include some UXR work from Flutter. |
|
While it is true that we would refuse to compile an app that might actually work, the same could be said for all static errors. Skipping these import checks is basically equivalent to allowing imports to a non-existent uri and then only failing at runtime if you tried to actually use that library. Improving the ergonomics of platform specific code would certainly be good, but I think that would have to happen at the language level. We could also work on the error messages etc to be more intuitive. |
|
What is the path forward here? I understand that I'm asking for a quick hack, but this shouldn't effect anyone besides the flutter tool. We should not be putting the dart:io problem on the critical path for flutter web |
|
I think the short term fix we should shoot for is allowing a (hopefully temporary) whitelist of packages that are allowed to ignore the import checks. |
|
@jonahwilliams - can you try with the latest packages from this branch? You'll need to override both |
|
Will do |
Flutter web must allow some
dart:ioimport inpackage:flutter, butadding
dart:ioto theDartPlatformcauses the module crawling topick the imports in some cases - we want the
DartPlatformto match thelibraries.jsonthat will be used by DDC and kernel in terms of whichlibraries are supported, but to avoid the failures for bad imports.
The kernel and DDC workers have always allowed imports to missing
dart:libraries with stubbed implementations that will throw if they areused at runtime. The restrictions on imports are implemented in the
build systems instead of the compilers. This argument allows loosening
the restriction in specific flutter packages while keeping the handrails for
user code.