Missing implementations of `Credential` in `credential_management.dart`

[Schwusch]

From Credential documentation:

/// The **`Credential`** interface of the
/// [Credential Management API](https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API)
/// provides information about an entity (usually a user) normally as a
/// prerequisite to a trust decision.
///
/// `Credential` objects may be of the following types:
///
/// - [FederatedCredential]
/// - [IdentityCredential]
/// - [PasswordCredential]
/// - [PublicKeyCredential]
/// - [OTPCredential]
///
/// ---
///
/// API documentation sourced from
/// [MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/API/Credential).

Only PublicKeyCredential is implemented and available. Before 1.0.0 (at 0.5.0), I was using PasswordCredential, but this is now broken.

[kevmoo]

CC @srujzs

[srujzs]

https://github.com/dart-lang/web/commit/7604578eb538c471d438608673c037121d95dba5 is the CL that removed these interfaces.

The only Credential type that's not marked as experimental is PublicKeyCredential in the MDN compatibility data. Because the web standards continuously evolve and result in a high number of breaking changes for this package, we've decided to emit only non-experimental APIs that are on the standards track. This reduces the number of downstream migrations and makes it easier to move the ecosystem to newer versions of this package.

[Schwusch]

I see the point of avoiding breaking changes. Would it be possible to mark/decorate Apis as experimental? DefinitelyTyped seems to go another route: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types%2Fwebappsec-credential-management%2Findex.d.ts#L182

[srujzs]

Would it be possible to mark/decorate Apis as experimental?

Possibly! package:meta provides one such mechanism. I think it still complicates migrations if people do use those APIs and possibly requires more aggressive pinning. On top of that, the internal monorepo can only use one version, so there's still the migration cost there. We talked about maybe generating a separate package with only the experimental APIs and labeling that whole package as experimental. That could be a possible avenue.

DefinitelyTyped seems to go another route

Are you talking about this bit? Specifically around creating a subfolder in an older version to include the latest version for users who want to use it? It's a really cool idea, but I'm not sure pub infrastructure is set up to allow iterate on older versions once a new version is published. I believe we talked about publishing entirely new packages for each version to maybe support this idea, but that has its own downsides (naming being one of them e.g. package:webv1, package:webv2, etc.).