Skip to content

Consider migration story for @aspnet/signalr #11688

Closed
@analogrelay

Description

@analogrelay

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

  1. Just stop shipping @aspnet/signalr.
    • Pros: It's easy
    • Cons: People using @aspnet/signalr don't know that we changed
  2. Ship one last version of @aspnet/signalr (probably version 3.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
  3. 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 version 1.x (BEFORE the shimming), then they may end up with two copies of the library. The 1.x version of @aspnet/signalr and the 3.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"

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedThis issue has completed "acceptance" testing (including accessibility)area-signalrIncludes: SignalR clients and servers

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions