dart-pad
dart-pad copied to clipboard
Flutter plugins should not be importable in pure Dart code
This code:
import 'package:url_launcher/url_launcher.dart';
main() {
launch("https://dartpad.dev");
}
Will not produce analysis errors, but will fail to compile:
Error compiling to JavaScript:
Warning: Interpreting this as package URI, 'package:dartpad_sample/main.dart'.
Error: Couldn't resolve the package 'url_launcher' in 'package:url_launcher/url_launcher.dart'.
lib/main.dart:1:8:
Error: Not found: 'package:url_launcher/url_launcher.dart'
import 'package:url_launcher/url_launcher.dart';
^
lib/main.dart:4:3:
Error: Method not found: 'launch'.
launch("https://dartpad.dev");
^^^^^^
Error: Compilation failed.
It's correct to fail, since url_launcher is a Flutter plugin that can't work without the Flutter SDK. It would be good to have an earlier warning produced by the analyzer, though.
NOTE: This is a definite edge case, since most devs would understand that url_launcher is a Flutter thing. In the long term, though, we should try to provide a message that makes sense.
You can determine which packages require Flutter by looking at their pubspec.yaml -- if that contains flutter under environment:, then the package is flutter only:
https://github.com/flutter/plugins/blob/master/packages/url_launcher/url_launcher/pubspec.yaml#L8
What is the desired output here?
Should we report an error saying the plugin is not importable without flutter, or should we implicitly compile it as a flutter app?
I think it might be confusing to implicitly compile it as Flutter, especially if they explicitly selected to create a Dart app.
The easiest solution would be to just spit out an error. The nicest might be to offer to convert it to a Flutter app.
This is an edge case, so I imagine the lowest-effort-but-still-clean approach is probably the best use of time.
Updating getUnsupportedImports so that it's smart enough to disallow Flutter plugins when no Flutter SDK packages are included is probably enough to correctly produce an error. The annoying bit is that @srawlins would need to maintain separate lists of "packages" and "plugins."
I think we have a general problem here beyond DartPad, which we should probably be handling in the SDK somehow: https://github.com/dart-lang/sdk/issues/47470
I'm always in favor of doing less work, so if this can be fixed in the SDK, that's great. 😄
Fixed by https://github.com/dart-lang/dart-pad/issues/1826