[dart 4.0] Drop support for dart_internal

[munificent]

The move to strong mode made, for example, Iterable<dynamic> no longer a subtype of Iterable<String>. The observable package (and likely a few other corners of the ecosystem) relied on this. To workaround that, we introduced the dart_internal package which gives you a very limited API to extract the type arguments from an Iterable or Map.

This was always intended to be a short-term solution. To that end, the package has a narrow version constraint which we bump every single time a new Dart SDK release comes out, just to give us the ability to remove it in a minor version of the SDK. And yet, here we are many versions later and it's still around.

We had hoped to add real language support for this capability (#4215) when we shipped pattern matching, but it didn't make it in. We mostly seem to get by fine without it, and the complexity is potentially high, so it seems unlikely that we'll add that any time soon.

I believe very little code still relies on the observable package, so I suspect we could simply remove support for dart_internal in Dart 4.0 and the ecosystem will route around its absence.

See go/how-to-update-dart-internal for more background.

[srawlins]

Big +1. If we can get it working internally, I think that would be good enough to call it safe.

[lrhn]

There are two packages using it according to pub

One was created 10 days ago. The other has versions published between 10 and 7 months ago.
Neither should be using the clearly marked as "not for use" package. (I bet some AI coder didn't notice that comment. Which is all the more reason to remove and bury that package.)
(Edit: And I just filed issues against both telling them they shouldn't be using dart_internal.)

Historically the package was used by the streamy and observable packages, but both are discontinued.

The streamy package was last updated 12 years ago and is "not compatible with Dart 3", so it'll probably never be used with a Dart 4 SDK.

The observable package is only four years old. It's not depended on much, but there is a notable dependency from angulardart_components. It's a third party package that us being actively updated.
The observable package is also Dart 2.12, discontinued and the repo is archived, so it's unlikely it'll survive removing 2.12 support.

The change_notifier package is the successor of observable and is community owned. It doesn't use dart_internal. We should make everything switch to that.

Maybe we should just remove dart_internal now, removing the functionality in 3.14, and see what breaks.

We have lingering versions of streamy and observable in internal code. It's not clear if they are still in use, or if they can be migrated to change_notifier. (Don't know if there is any replacement for streamy, 12 years old and nobody made a replacement. Only thing that sucks is that I wanted that name 😁 )
And there is one other use, in code that says it's there only to avoid having streamy generate it. So really streamy again.

So something will break.

Maybe we can move dart_internal into the internal repo, change the SDK to only support that, and stop supporting the public version. That should give us more time to clean up our internal messes without encouraging anyone to keep using the package in the public ecosystem.

[munificent]

Maybe we can move dart_internal into the internal repo, change the SDK to only support that, and stop supporting the public version.

dart_internal is a pub package. It's implemented internally in terms a hidden "dart:" library that only it is allowed to import. But the actual thing users use is a pub package.

Also, the package has always had a narrow SDK constraint whose upper bound is the next minor release of the SDK. (The idea was that that would let us remove the internal "dart:" library in a minor release of the SDK without breaking the package.)

So we could actually externally deprecate this by simply not publishing dart_internal to pub when Dart SDK 3.14 comes out. When users upgrade to Dart 3.14, pub will no longer give them dart_internal.

We could still have a version inside google3 that does work with the latest SDK if it's needed internally.

I'm not sure if I have enough courage to run this experiment, but it's a thing we could do. :) Probably a better path is for someone (likely me) to try dig deeper into the things that are still using dart_internal and try to either actively move them off dart_internal or actively deprecate those things too.