Skip to content

npm i cloudevents #215

Closed
Closed

Description

@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.

Activity

  1. lholmquist commented on Jun 8, 2020

    @lholmquist
    Contributor

    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.

  2. grant commented on Jun 8, 2020

    @grant
    MemberAuthor

    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.

  3. lholmquist commented on Jun 8, 2020

    @lholmquist
    Contributor

    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

  4. lholmquist commented on Jun 8, 2020

    @lholmquist
    Contributor

    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"

  5. lance commented on Jun 8, 2020

    @lance
    Member

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

  6. grant commented on Jun 8, 2020

    @grant
    MemberAuthor

    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.

  7. lholmquist commented on Jun 8, 2020

    @lholmquist
    Contributor

    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.

  8. grant commented on Jun 8, 2020

    @grant
    MemberAuthor

    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.

  9. lance commented on Jun 9, 2020

    @lance
    Member

    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.

  10. grant commented on Jun 9, 2020

    @grant
    MemberAuthor

    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.

  11. added
    version/3.xIssues related to the 3.0 release of this library
    on Jun 11, 2020
  12. added a commit that references this issue on Jul 23, 2020
    730b0e8
  13. added a commit that references this issue on Jul 24, 2020
    565f867
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    version/3.xIssues related to the 3.0 release of this library

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions