Description
TL;DR: If you develop a JavaScript library component that depends on @aspnet/signalr
, we'd like to hear from you!
One open question that we'd like some support from the community on is how to manage the name transition. Here, we'd love feedback from app developers and anyone developing other NPM components that depend upon @aspnet/signalr
.
My biggest concern is if a library component references @aspnet/signalr
at version >=1.0.0
. They are saying they work with versions 1.0 and higher, but the problem is that version 3.0 is not part of that set (because it's a different package name).
We have a few options
- Just stop shipping
@aspnet/signalr
.- Pros: It's easy
- Cons: People using
@aspnet/signalr
don't know that we changed
- Ship one last version of
@aspnet/signalr
(probably version3.0
) and immediately deprecate it on NPM.- Pros: Still pretty easy, clearly tells users they need to update (via the deprecation message)
- Cons: Libraries taking a dependency on
@aspnet/signalr
either have to update, or can't get the new stuff
- Ship
@aspnet/signalr
as a "shim package". This would be a package that has a direct dependency on the matching version of@microsoft/signalr
and re-exports all the types. So it's content would be something like the snippets below- Pros: Nobody is broken
- Cons:
- We have to maintain this package for some undefined period of time.
- If an app is already using the new version (
@microsoft/signalr
) and references a library using@aspnet/signalr
version1.x
(BEFORE the shimming), then they may end up with two copies of the library. The1.x
version of@aspnet/signalr
and the3.x
version of@microsoft/signalr
. Thanks to JavaScript this will probably still work, types can be exchanged just fine.
I think if we did option 3, we'd also mark each release of these shims as deprecated so that NPM users get the warning. That means that if an app did use @microsoft/signalr
and a library it depends on used @aspnet/signalr
you would get a warning indicating you were in a slightly odd state. If you manually installed the shim package @aspnet/signalr
it would fix the odd state since now the library would be using the shim and there'd only be one copy of @microsoft/signalr
@aspnet/signalr
package.json
{
"name": "@aspnet/signalr",
"main": "index.js",
"dependencies": {
"@microsoft/signalr": "[exact same version]"
}
}
@aspnet/signalr
index.ts
export * from "@microsoft/signalr"