☔ Deprecate legacy HTML/JS libraries/packages

[kevmoo]

• Mark legacy dart: libraries as deprecated
• Mark https://pub.dev/packages/js as discontinued
  • Publish https://pub.dev/packages/js with APIs annotated as deprecated
  • Mark pkg:js discontinued once pub.dev rolls to Dart 3.7

[ahmednfwela]

Shouldn't all the missing api issues be solved before deprecating old packages? this way consumers can have a clear migration path.

[srujzs]

That tag covers more than just "missing from package:web but are in the web libraries", so it isn't necessarily an indicator of migrate-ability.

Something would be a blocker if a functionality was exposed before which has no alternative or workaround in either package:web or dart:js_interop(_unsafe) that wasn't intended by design (e.g. dynamic dispatch). On a brief pass, I don't see that as the case for any of those issues. Of course, if something is very confusing or annoying to deal with for users, then we should prioritize those issues and consider that as a blocker.

The motivation behind this is to avoid further proliferation of legacy interop code and eventually get it down to a point where the ecosystem can move forward with Wasm easily.

[ahmednfwela]

the highest impact issue I can think of that needs to be addressed is callback interfaces, e.g. EventListener

package:web defines it as:
typedef EventListener = JSFunction; (incorrect)
while dart:html defines it as:
typedef EventListener = dynamic Function(Event event); (correct)

this means that all customers migrating to package:web instantly lose type safety for EventListener parameters, this affects EVERY SINGLE html element.

[ahmednfwela]

This was also discussed a while back #56358 and I have raised the same concern

[srujzs]

There's a canonical issue for typing JS functions: https://dart-review.googlesource.com/c/sdk/+/401046. There are some downsides to generating typed JSFunctions everywhere in package:web but I think it'd be a net positive.