Don't trigger `avoid_web_libraries_in_flutter` in files ending with `_web.dart`

[parlough]

Currently avoid_web_libraries_in_flutter is not triggered if a Flutter web plugin context is added. However this mechanism doesn't fit all uses of web libraries.

As an example, various DevTools' packages use a lot of web libraries without this declaration, resulting in them adding a lot of ignore comments. However, a majority of these files have a name ending with _web.dart.

I think that's a pretty clear opt-in to wanting access to the underlying web platform. So I propose we don't trigger the lint in that case, and suggest it as a standard naming scheme for files that access the web platform in a multi-platform Flutter app.

This will be particularly helpful as I'd like to expand the lint to include the new replacement web libraries, but some code has been migrated to them without the ignore. This will reduce new cases of the lint triggering.

Draft implementation CL: https://dart-review.googlesource.com/c/sdk/+/349180

[bwilkerson]

@goderbauer @kevmoo As potentially interested parties.

[goderbauer]

I am not that familiar with how and when web libraries should be used in Flutter. Maybe @yjbanov can comment?

[kevmoo]

_web.dart is a nice convention. I can buy it. It's hard to imagine a case where someone wants to name a library XYZ_web.dart and not want it to be "web stuff".

[kevmoo]

These kinds of magic conventions, in general, make me nervous though. I guess if we document it clearly in the lint?

[parlough]

These kinds of magic conventions, in general, make me nervous though.

Yeah I was hoping this one was more clear than some other magic conventions with it involving the filename, which is generally quite visible. Likely even more so than the pubspec's plugin configuration which can be quite far away from a developer's current context, or modified by a different developer. Hopefully updated documentation can help too :)

I guess if we document it clearly in the lint?

I agree! You can see my proposed documentation in https://dart-review.googlesource.com/c/sdk/+/349180.

[parlough]

After some synchronous discussion, there's feeling that accidental imports of dart:html when writing Flutter code was perhaps the primary motivator for this lint. Now that dart:html is not suggested if not imported already, this lint might not be as necessary.

There's also the fact that it's alone in avoiding platform handling, as there is no equivalent lint for dart:io and similar.

I'd still like to hear what the Flutter web team thinks, but I'm leaning towards not expanding this lint to cover the new libraries (dart:js_interop, dart:js_interop_unsafe, etc), nor adding new mechanisms to avoid it.

Then in a world without dart:html, we can deprecate this lint and remove it from package:flutter_lints.

There is still value in helping developers use conditional imports correctly and isolating platform-specific code, but any solution should likely be designed from the bottom-up to account for all platforms, not just web.

Let me know your thoughts :)

[bwilkerson]

@yjbanov Friendly ping. Your opinion would be welcome here.

[kevmoo]

@bwilkerson – I think we're okay to move forward here!

[kevmoo]

Although we should talk about what's considered a web library with the new things coming along. Maybe that should be a new issue...

[bwilkerson]

I'm ok with changing the lint, but I do want to have a clear definition of the semantics we should implement before we start. And I want to know what the end-state looks like, even if we're expecting to be in this intermediate state for long enough to make supporting it valuable to users. Happy to get there in whatever way works best for you.