Experimental Features in Stable Packages

[dyladan]

Experimental Features in Stable Packages

[pichlermarc]

A workaround for this is to not consume the /experimental namespace in our SDK packages. We would simply redeclare any types. Given the above example, we would have to declare an ExperimentalContextManager type in the AsyncHooksContextManager package and rely on typescript to recognize the compatible types.

@dyladan and I talked about this offline yesterday:

We have to re-declare types from the API in the consuming packages anyway if the API is used as a peer dependency like >=1.0.0 <1.9.0. As users can use the package with an older version of the API, it might happen that they don't contain the types API types we're using which breaks users (see #4260).

To implement something like this we can go a similar way as proposed by #4622.

[pichlermarc]

Overriding Methods

This requires the addition of a new experimental version of any API that needs experimental functionality. As an example, if we were going to experimentally change the behavior of the startSpan API, we would need to add a new method like experimentalStartSpan or similar because we can't override the existing API.

I think this may also be solvable by the same wrap()-approach. If wrap() is used we use the new behavior on the returned object in place of the old one.

Would you mind providing an example on which change would result in us having to change the API in such a way?

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.