npm i cloudevents

[grant]

We should make it really as simple as possible to use this module.

Expected

npm i cloudevents

Actual

npm install cloudevents-sdk

Not sure who's publishing the npm module, happy to give cloudevents for publishing source in this repo.

Python, Ruby, C# all don't use cloudevents-sdk, just cloudevents.

[lholmquist]

I would argue that it would create more confusion if the name changed now.

I would suggest that you, @grant , deprecate that module and point your readme to this repo.

[grant]

I don't think it would create confusion. There are only 13 dependents, and few downloads/m. What changed now?

History aside, what would you ideally install?:

cloudevents
cloudevents-sdk

I'd rather show npm i cloudevents on stage.

[lholmquist]

The problem is the history and older versions that are currently published for the cloudevents module. Those versions are not "cloudevents-sdk" versions.

I can see a user getting burned by this, if they switch, and then need a previous version, for whatever reason, and it not working because they forgot about the name change. What about new users who never knew the history of changing names?

Also, what real value does this name change bring, other than saving a couple key strokes? You usually only ever install things once anyway

[lholmquist]

There are only 13 dependents, and few downloads/m. What changed now?

That only counts other modules that depend on this module, not applications that are not published on npm. Also i don't think 3k+ downloads a week is "a few"

[lance]

I'm with @lholmquist on this. I don't think it would be wise to change the module name after two major version releases.

[grant]

There are 0 dependents on the other package and it's easy to mirror npm versions. I've done this before. The user impact would be 13 repos would get npm warnings when installing asking them to change the dependency, which would be easy and non-breaking.

We're really at the start of this repo and I'd like to make the decision now. Please answer this question:

History aside, what would you ideally install?:

cloudevents
cloudevents-sdk

I couldn't have done this before because we didn't agree to publish TypeScript types in this repo.

[lholmquist]

The user impact would be 13 repos would get npm warnings when installing asking them to change the dependency, which would be easy and non-breaking

As you soon as you ask someone to change the name of something it is a breaking change.

and i still don't know why you think it is only 13 repos. that's only the modules that depend on this module. based on that weekly download count, it looks like many more users would be affected.

As for the warning, it is nice to say that users read them, but the fact is, someone will do an npm install and not pay attention to any message.

My vote is to keep the name the way it is.

[grant]

Hi @lance, @lholmquist, Can you please answer this question?

History aside, what would you ideally install?:

cloudevents
cloudevents-sdk

Like TypeScript support, I'm asking for us to be open. I understand the long-term impact and wish for this change. This name doesn't align with other repos. It would be a better name and would align with other SDK names like Python, Ruby, C#, etc.

[lance]

You have not provided any compelling reason to change the name of this module beyond an aesthetic desire to reduce typing by four characters. I don't think that justifies this change. This module name perfectly aligns with the Rust module. Maybe we should change the names of the Python and C# modules to better align with JavaScript and Rust.

[grant]

You have not provided any compelling reason to change the name of this module beyond an aesthetic desire to reduce typing by four characters.

But this module is not an SDK. This is not a "software development kit". The set of 7 languages is the SDK, the kit. This library is a small library for handling CloudEvents, part of the SDK. The CloudEvents SDK is meant to refer to a collection of multiple libraries in different languages, not an individual language library.

Moreover, this name with "-sdk" is not idiomatic for JavaScript and Node. It would be more acceptable for other languages like Java.

The only real example of a npm package using "-sdk" was AWS' SDK, which is not comparable to this library. That package is really a set of tools for multiple APIs and is aptly named.

---

Here are more data points:

Look at:
https://www.npmjs.com/

Search SDK in npm:
https://www.npmjs.com/search?q=-sdk

Read about SDK on Wikipedia referencing multiple tools:
https://en.wikipedia.org/wiki/Software_development_kit

---

This whole repo used Java-like constructs like builder patters. Using -sdk is one of the historical parts that I would like to fix now. It's doable like moving to TypeScript. I'd like strong counterarguments for saying no, it's not idiomatic or better due to the above arguments.