Utilize NPM @dapr

[XavierGeerinck]

Describe the proposal

We have now been granted access to the @dapr organization on NPM.

I propose to start using it under @dapr/dapr instead of dapr-client

Since this is a critical change, I propose on maintaining both in the release pipeline where we in the build.yml process setup an extra step that modifies package.json and swaps the name for @dapr/dapr and releases with the new NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN_DAPR }} env variable

[XavierGeerinck]

@shubham1172 @paulyuk @amulyavarote thoughts?

[shubham1172]

Should we use npm-deprecate and stop releasing new dapr-client packages (immediately or after a few releases)? Reference https://stackoverflow.com/questions/28371669/renaming-a-published-npm-module

Till then we can keep the new one, i.e. @dapr/dapr in package.json and write a helper function to publish simultaneously to dapr-client.

[XavierGeerinck]

Sounds interesting! Looking forward to others their comments

[tanvigour]

I like the idea of npm-deprecate for smooth transition although since this access was granted very recently, if we plan on doing this quickly we may not need to go npm-deprecate route. But overall I think using dapr/dapr instead of dapr-client would feel more in sync with rest of our stuff.

[shubham1172]

@tanvigour but then the existing projects that use dapr-client will break, right? Unless we tell them in advance that we are moving to another name completely from XYZ date onwards, they won't have time to change their code.

[tanvigour]

it depends on the rate of adoption. If we already have more than handful users, yes we do not need go npm-deprecate route

[XavierGeerinck]

I would follow @shubham1172 his idea, allowing people to adopt gradually as NPM packages like to remain on a version.

Personally, I would maintain the dapr-client for around 6 months or until we are able to measure 0 download rate on it

[shubham1172]

@XavierGeerinck I can think of two options for maintaining dapr-client, once it is deprecated and before we unpublish it:

1. Create a new branch from the next release for dapr-client and only push security updates/bug fixes for the next 6 months.
2. Keep updating dapr-client with the same stuff as @dapr/dapr

[XavierGeerinck]

You can never unpublish a package :) but I agree on those points

[shubham1172]

I also remember the same, but I stumbled upon this https://docs.npmjs.com/unpublishing-packages-from-the-registry
Looks like it is possible, given the following conditions:

[shubham1172]

@paulyuk can you please confirm on this plan and what dates will be ideal for deprecation and unpublishing?

[paulyuk]

Hi there. This sounds like a breaking change. The way I would do that is provide a new version and allow users time to adopt it. I agree with Xavier we should use data/telemetry to measure people moving off of the current version. We need to make this change very clear and visible too IMO.

Now in terms of how to do this best in NPM this will be my first time. I would weigh what Xavier recommends heavily. We can also consult with the experts in VS Code too.

[shubham1172]

Proposed next steps:

1. Release the new package and announce deprecation plans (say after 6 months)
   • Both the packages will receive the same updates
   • For announcements, add to README, pin a GH issue, mention on Discord, Twitter
   • Add a warning message in old package's build to announce intention/date/plan of action for consumers
2. On deprecation date, use npm-deprecate to announce archival of the old package (say after 12 months)
   • Till archival date, the deprecated package will only receive major updates
3. Monitor the downloads and spread more words if we still see active downloads for the old package. Finally stop pushing any updates to it and archive the package (change the npm-deprecate message to reflect the same).

Thoughts on this? Also cc @yaron2 for ideas.