-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider shipping package:meta
as dart:meta
, similar to dart:js_interop
and dart:ffi
#54879
Comments
I'd say the trend is in the other direction. We're moving The best reason for having a package is that it can make breaking changes. A A package like The The |
I agree. The ability to define annotations that would never be approved for inclusion in the SDK and the ability to make breaking changes are valuable to the community. Not having a package would be detrimental to users. And I think that moving in the direction of moving more functionality out of the |
I thought #53745 (comment) was a compelling user report of the existence of |
Good thing you don't need to use |
@MaryaBelanger Re:
Is this something that we might want to try to address somehow in documentation? |
Sure, I can try. I'll have to take a closer look at where this info might fit to make it as visible as possible (that seems to be the main issue). Opened an issue here if anyone wants to throw their ideas in or discuss it further (will just be using the user report to inform otherwise): dart-lang/site-www#5751 |
Originally,
package:meta
was a compromise (likepackage:js
) to allow faster-iteration and versioned releases out of the SDK, and to (as far as I remember?) bypass arguments around what belongs in the core SDK or not. I believe that both of these rationales are dated and should be revisited.Namely:
package:meta
is part of the SDK (the analyzer)@override
,@deprecated
) that make sense indart:meta
1package:meta
by default as part of it's SDKdart:ffi
,dart:js_interop
, etc) is to move packages that are really SDK-vended into the SDKLuckily I think this would be (mechanically) easy, as
package:meta
could justexport 'dart:meta'
until migrated.Footnotes
But for continuity could continue to be exported in
dart:core
. ↩The text was updated successfully, but these errors were encountered: