-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop support for Isolate.resolvePackageUri from dart2js and DDC #37153
Comments
Interesting, while we can't rule out that people are using it via My inclination is to go ahead and remove the support as well. We can do a quick search for packages that use either the isolate API or the resolve package to assess potential impact to make sure. Then create a breaking change proposal to remove the support. Especially since we say that Another option to consider here is that instead of removing just this API, to go to the full leap and make it invalid to import these libraries entirely. That has the potential of being more breaking (since the presence of an import will break people's builds), so I'd consider that more cautiously. |
If We have made yet another "kind-of supported" library, and we shouldn't be doing that. What would break if we simply disallowed importing |
The golden path for external users is to compile through We are working hard on restricting imports internally as well. Users who run
We did that for |
The implementation in dart2js is broken by default already. It was broken in 7911fb2#diff-894e25213751e7522ad6394c40e9378e
Unless the user explicitly assigns to
defaultPackagesBase
the call will fail. We do have some tests against this behavior:sdk/tests/lib_2/isolate/browser/package_resolve_browser_hook2_test.dart
Line 14 in b080e7c
There is at least one known use case which attempts to be cross platform which depends on this. It's currently broken by default with dart2js but works with DDC: https://github.com/dart-lang/resource/blob/f8e37558a1c4f54550aa463b88a6a831e3e33cd6/lib/src/resolve.dart#L11
We need to decide if it is worth supporting this use case and either break support, or migrate the implementation to some other place - perhaps as a utility in
dart:html
. My preference would be to remove support.cc @vsmenon @sigmundch
The text was updated successfully, but these errors were encountered: