Auto importing dart:html

[rlee1990]

Flutter keeps auto importing dart:html when I try to use a Text widget. I am using VsCode.

Flutter Doctor:

[✓] Flutter (Channel stable, v1.12.13+hotfix.9, on Mac OS X 10.15.4 19E287, locale en-US)
    • Flutter version 1.12.13+hotfix.9 at /Users/rickeylee/Desktop/flutter
    • Framework revision f139b11009 (3 weeks ago), 2020-03-30 13:57:30 -0700
    • Engine revision af51afceb8
    • Dart version 2.7.2

 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/rickeylee/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-R, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4, Build version 11E146
    • CocoaPods version 1.9.0

[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 43.0.2
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)

[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.9.1

[✓] Connected device (1 available)
    • iPhone • d0545eb2ff26e1c087d1b29c26f8e15da19284bb • ios • iOS 13.3.1

[devoncarew]

I think we'll want to do one of either:

• manually reduce the suggestion order of items from dart:html when writing a Flutter app, or
• ensure that the statistics of import usage naturally lead to a lower heuristic for dart:html types

cc @pq @bwilkerson @jwren

[bwilkerson]

When the code completion engine decides whether to suggest names defined in other not-yet-imported libraries, it can use the declared package dependencies to do so. We don't have quite the same information available for core libraries, but maybe there's a mapping we can make from the SDK (Dart vs. Flutter) to control the availability of them.

[tomasbaran]

Same here:

I just always end up deleting import 'dart:html';. Then I rerun the app and the same thing repeats over but on random basis.

I also now notice that it also adds other imports by itself without me knowing about it.

import 'dart:async';

But dart:async doesn't give me an error saying "Not found.

(content deleted for brevity)

[  +32 ms] executing: [/Users/tomas/Developer/flutter/] git -c log.showSignature=false log -n 1 --pretty=format:%H
[  +52 ms] Exit code 0 from: git -c log.showSignature=false log -n 1 --pretty=format:%H
[        ] b8bd09db210d2c6299555643af8db4b8ff3e8d92
[        ] executing: [/Users/tomas/Developer/flutter/] git describe --match *.*.* --first-parent --long --tags

...

#0      throwToolExit (package:flutter_tools/src/base/common.dart:14:3)
#1      RunCommand.validateCommand (package:flutter_tools/src/commands/run.dart:337:7)
<asynchronous suspension>
#2      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:725:11)
<asynchronous suspension>
#3      FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:642:33)
<asynchronous suspension>
#4      FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart)
#5      AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:29)
#6      _rootRun (dart:async/zone.dart:1184:13)
#7      _CustomZone.run (dart:async/zone.dart:1077:19)
#8      _runZoned (dart:async/zone.dart:1619:10)
#9      runZoned (dart:async/zone.dart:1539:10)
#10     AppContext.run (package:flutter_tools/src/base/context.dart:149:18)
#11     FlutterCommand.run (package:flutter_tools/src/runner/flutter_command.dart:632:20)
#12     CommandRunner.runCommand (package:args/command_runner.dart:197:27)
#13     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:340:21)
#14     _rootRunUnary (dart:async/zone.dart:1192:38)
#15     _CustomZone.runUnary (dart:async/zone.dart:1085:19)
#16     _FutureListener.handleValue (dart:async/future_impl.dart:141:18)
#17     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:682:45)
#18     Future._propagateToListeners (dart:async/future_impl.dart:711:32)
#19     Future._completeWithValue (dart:async/future_impl.dart:526:5)
#20     _AsyncAwaitCompleter.complete (dart:async-patch/async_patch.dart:36:15)
#21     _completeOnAsyncReturn (dart:async-patch/async_patch.dart:303:13)
#22     FlutterVersion.checkFlutterVersionFreshness (package:flutter_tools/src/version.dart)
#23     _rootRunUnary (dart:async/zone.dart:1192:38)
#24     _CustomZone.runUnary (dart:async/zone.dart:1085:19)
#25     _FutureListener.handleValue (dart:async/future_impl.dart:141:18)
#26     Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:682:45)
#27     Future._propagateToListeners (dart:async/future_impl.dart:711:32)
#28     Future._completeWithValue (dart:async/future_impl.dart:526:5)
#29     Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:556:7)
#30     _rootRun (dart:async/zone.dart:1184:13)
#31     _CustomZone.run (dart:async/zone.dart:1077:19)
#32     _CustomZone.runGuarded (dart:async/zone.dart:979:7)
#33     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:1019:23)
#34     _microtaskLoop (dart:async/schedule_microtask.dart:43:21)
#35     _startMicrotaskLoop (dart:async/schedule_microtask.dart:52:5)
#36     _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:118:13)
#37     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:169:5)

 info • The value of the local variable 'placemark' isn't used • lib/screens/loading_screen.dart:17:21 • unused_local_variable
   info • Avoid using web-only libraries outside Flutter web plugin packages • lib/screens/my_city_screen.dart:2:1 • avoid_web_libraries_in_flutter
   info • Unused import: 'package:Sundee/screens/location_denied.dart' • lib/screens/my_city_screen.dart:4:8 • unused_import

Logs

[✓] Flutter (Channel master, v1.18.0-6.0.pre.42, on Mac OS X 10.15.4 19E287, locale es-ES)
    • Flutter version 1.18.0-6.0.pre.42 at /Users/tomas/Developer/flutter
    • Framework revision b8bd09db21 (11 days ago), 2020-04-15 22:25:32 -0700
    • Engine revision deef2663ac
    • Dart version 2.8.0 (build 2.8.0-dev.20.0 c9710e5059)

 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/tomas/Library/Android/sdk
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.4.1, Build version 11E503a
    • CocoaPods version 1.9.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 3.6)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 44.0.2
    • Dart plugin version 192.7761
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-release-1586-b4-5784211)

[✓] VS Code (version 1.44.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.9.1

[✓] Connected device (5 available)
    • iPhone            • 00008020-000415840E50003A            • ios            • iOS 13.3.1
    • iPhone 11 Pro     • A85E0A78-987E-41EA-9676-E33AC01D746D • ios            • com.apple.CoreSimulator.SimRuntime.iOS-13-4 (simulator)
    • iPhone 11 Pro Max • 29AAAD23-5952-417E-A4F1-4763923FDA6C • ios            • com.apple.CoreSimulator.SimRuntime.iOS-13-4 (simulator)
    • Chrome            • chrome                               • web-javascript • Google Chrome 81.0.4044.122
    • Web Server        • web-server                           • web-javascript • Flutter Tools

• No issues found!

[cth00]

Same issue here, along with my 3 friends facing this issue.

[pq]

Thanks for the feedback (and sorry for the continued hassle). Tracking on the SDK here: #41641.

[DanTup]

This came up in Dart-Code/Dart-Code#3265 (comment) too, and Eric made an interesting comment about non-Flutter code. It reminded me that I've accidentally imported dart:html (quite a lot, actually) into a CLI project I have (a static website generator - which has a lot of overlap with class names that are also in dart:html).

So it may be advantageous for the solution to not be Flutter-specific/based on the SDK type, but something that can be opted-in to pure CLI projects too.

(I just found there's a lint avoid_web_libraries_in_flutter and wonder whether a less Flutter-specific version would work - and perhaps could be used to filter the completion?)

[srawlins]

@bwilkerson the comment about avoid_web_libraries_in_flutter is enticing. Would it be not a crazy idea to look up whether avoid_web_libraries_in_flutter is enabled, and if so, strictly never offer up package:html elements?

[bwilkerson]

It isn't necessarily crazy. But as Danny pointed out (on Apr 8, 2021), a non-Flutter-specific solution might be better (if we can figure out when these libraries should not be suggested).

Aside from that, the only concern I have is performance. Currently the lint parses the pubspec.yaml file to determine whether is should be enabled, and that's probably too expensive for code completion. We'd need to cache that information on a per analysis context basis in such a way that it doesn't leak memory.

Would we want this to be transitive? That is, not suggest items in libraries that directly or indirectly import one of these libraries?

[srawlins]

But as Danny pointed out (#41641 (comment)), a non-Flutter-specific solution might be better (if we can figure out when these libraries should not be suggested).

I don't understand this idea. Wouldn't this be based strictly on whether VM-only libraries are imported (like dart:io)? If so, it would not benefit most libraries, as most libraries do not directly import dart:io. I imagine even in a CLI app, most libraries do not import dart:io.

Currently the lint parses the pubspec.yaml file to determine whether is should be enabled

Why would have to execute the lint rule? Don't we know (without reparsing) whether the lint rule is enabled or not?

Would we want this to be transitive? That is, not suggest items in libraries that directly or indirectly import one of these libraries?

I don't think so. The main pain point as I understand it is accidentally importing things from dart:html, like Element, and Text.

[bwilkerson]

Wouldn't this be based strictly on whether VM-only libraries are imported (like dart:io)?

I don't think so. The question isn't about whether we're importing non-web libraries, the question is whether it's valid to import web-only libraries. Or, more generally, if we have platform-specific libraries in the SDK, then we shouldn't be suggesting them if the code isn't targeting the required platform.

Why would have to execute the lint rule? Don't we know (without reparsing) whether the lint rule is enabled or not?

Yes, but I wasn't talking about the lint rule. The question that code completion would need to answer is: is this a Flutter app? The way the lint rule answers this question is to parse the pubspec.yaml file. I suspect that it would be too expensive for code completion to parse the file in order to answer that question, so we'd need to have some low-cost way to get the answer, and my (potentially unwarranted) assumption is that we'd need to cache the information in order to make it cheap enough. But maybe we can get the UriResolver to tell us whether it can resolve package:flutter URIs (and if so, perhaps that's the better approach for the lint to use as well).

Would we want this to be transitive? That is, not suggest items in libraries that directly or indirectly import one of these libraries?

I don't think so. The main pain point as I understand it is accidentally importing things from dart:html, like Element, and Text.

Right. But if we shouldn't suggest names from dart:html when there's an import of package:flutter/material.dart, wouldn't it be equally wrong to suggest them when there's an import of another file that imports material.dart?

[srawlins]

Yes, but I wasn't talking about the lint rule. The question that code completion would need to answer is: is this a Flutter app? The way the lint rule answers this question is to parse the pubspec.yaml file.

Ah I see. Very curious.

Right. But if we shouldn't suggest names from dart:html when there's an import of package:flutter/material.dart, wouldn't it be equally wrong to suggest them when there's an import of another file that imports material.dart?

I think I got lost in asking my question. What do you mean by "when there's an import of package:flutter/material.dart? This question is the first I'm seeing about "an import of package:flutter/material.dart". Is this some mechanism by which we might decide that one shouldn't suggest elements from dart:html?

[bwilkerson]

I was riffing on your question of "Wouldn't this be based strictly on whether VM-only libraries are imported", which changed the discussion from "is this a Flutter app" to "is this library importing a VM-only library". I should have been more clear.

So let me restate my previous assertion: I think the question is "is the library in which completion is being performed expected to only run on platforms that allow the use of the library under consideration", not "is there an import that makes it wrong to also import this library".

It might be easier to answer that question if we only answer it for Flutter apps (because I think the supported platforms are better specified there), but it's a question I'd like us to eventually be able to answer for any code.

[srawlins]

I think the question is "is the library in which completion is being performed expected to only run on platforms that allow the use of the library under consideration", not "is there an import that makes it wrong to also import this library".

I agree.

It might be easier to answer that question if we only answer it for Flutter apps (because I think the supported platforms are better specified there), ...

I'm not sure it would make it easier, as dart:html is a valid import for an app running Flutter on the web.

... but it's a question I'd like us to eventually be able to answer for any code.

I agree. But there is no mechanism for this today, right? Are we circling into an answer that we cannot implement this feature today?

[bwilkerson]

Probably. Sigh.

[srawlins]

Haha yeah. I think there is a whole collection of problems that need the answer, "is this expected to be compiled for web? is this expected to be compiled for CLI?" In google3 we have the "platforms" list which solves this.

Actually, come to think of it, I'm not sure where the pub badges come from. Like the file package does not have 'web' listed, but the markdown package seems safe for everything, and the camera "package" only lists flutter. Definitely might be worth a look. Definitely maybe.

[DanTup]

This came up at Dart-Code/Dart-Code#4693 with dart:js_interop too. It has an extension member (jsify()) on Object? which I guess shows up in the completion list on every(?) target. Running on the VM will fail with "Dart library 'dart:js_interop' is not available on this platform".

In google3 we have the "platforms" list which solves this.

Could we have something similar in analysis_options? (I saw analysis_options and not pubspec, because I can imagine having CLI scripts in tool for a web project).

[srawlins]

Of course, I'd really prefer to have some existing mechanism be able to answer this question (an existing field in the pubspec? Some existing Flutter configuration? The presence of a file?

Barring that, we could add support in analysis_options.yaml, or maybe do something clever. Could we track whether dart:html is already imported by any other file in the AnalysisContext? 🤔

[DanTup]

Could we track whether dart:html is already imported by any other file in the AnalysisContext? 🤔

Presence of dart:html in some files might mean it's safe to suggest from dart:html, but I don't know if the opposite is true (or at least, ideal). Conditional imports might also confuse things further... DevTools imports dart:html in some places that are used in conditional imports but it definitely doesn't want dart:html imports across the rest of the project.

[srawlins]

Yeah conditional imports would have to be taken into account, and as you mentioned earlier, maybe you have a web app, but use dart:io in the tool/ directory, etc. I don't think it could be made foolproof.

[jacob314]

At this point I am comfortable completely disabling auto-importing dart:html as while the library is not deprecated yet, it doesn't work with WASM and will be deprecated at some point.

[devoncarew]

Done by @scheglov in https://dart-review.googlesource.com/c/sdk/+/348081 (as per #54610) :)

[jacob314]

Thanks @scheglov!