Skip to content

Next steps on Support levels in Package.json #192

Open
Open
Next steps on Support levels in Package.json#192
Assignees
Eomm
Labels
help wantedExtra attention is neededtoolsThis thing need to be implemented
Milestone
Support Levels

Description

@mhdawson
mhdawson
opened on Apr 8, 2019
  • Make sure we follow our own guidelines in publishing of tool
  • Get input from 2 of the 'friendly' module owners
  • Update or replace tool in pkgs repo to support agreed structure
  • Minimal command in support tool to to show support info for package dependencies
  • Add support info to modules within the Node.js org.
  • Evangelise and get additional input
    • Blog outlining the support levels and how to use tool to validate
  • Final review and promote to 'docs' from drafts
  • blog on adding tool to your CI
  • PRs to modules to add in information
  • tool to scan dependencies and provide more comprehensive report on support information
  • facilitate/document how to put badges with support info elements on your package readme.
  • submit feedback top in npm/feedback repo suggesting that support information be shown on the npm page.

Activity

  1. Eomm commented on Apr 9, 2019

    @Eomm
    Eomm
    on Apr 9, 2019
    Member

    Make sure we follow our own guidelines in publishing of tool

    I'll try to do a checklist to check that all is in place.

    blog on adding tool to your CI
    tool to scan dependencies and report on support information

    A new feature for the cli tool!
    Starting from the idea of @ljharb, there are some tools like license-checker --production --onlyAllow='MIT;ISC;BSD-3-Clause;BSD-2-Clause'
    or licensee that can be integrated in a script in the package.json and run when necessary by CI
    in order to check that the dependencies don't change license (or support level for our case).

    PRs to modules to add in information

    Big like!

    move the tool over to the node repo?

    I agree, so working on it will be more productive.
    Can I proceed? @mhdawson I think we need to sync from for permissions and/or timings

    create url on website that generates svg for readme that reports your level and has link to the pages which describe the levels.

    The website could to do:

    • a page to create the code snippet for the badge gettin a npm-module as input (so it will check the existing package.json)
    • a page to list the support attributes of the direct dependencies of the module

    Example built with https://shields.io/

    support backing
    support target
    support response-def

    ![support backing](https://img.shields.io/badge/support%20backing-HOBBY-blue.svg)
![support target](https://img.shields.io/badge/support%20target-ABANDONED-red.svg)
![support response-def](https://img.shields.io/badge/support%20response--ref-REGULAR--7-yellow.svg)

    Talk to package phobia to see if you would information from the new fields. Icon with link to our site that scan dependencies.

    After build the site should be easy to add a link to that site if the maintainer agree with our intents.

  2. ghinks commented on Apr 18, 2019

    @ghinks
    ghinks
    on Apr 18, 2019
    Contributor

    Just had a look at the tool, great job @Eomm. Has someone contacted the package phobia folks if not I can.

  3. Eomm commented on Apr 23, 2019

    @Eomm
    Eomm
    on Apr 23, 2019
    Member

    Make sure we follow our own guidelines in publishing of tool

    These are the steps accomplish by the tool:

    • Version (v1.0.0)
    • License (MIT)
    • Support level in package.json (added)
    • Publish (.npmignore)
    • Testing (tap + coveralls)
    • CI (travis win+linux LTS)
    • Deprecated

    Has someone contacted the package phobia folks

    Nope

  4. ghinks commented on Apr 26, 2019

    @ghinks
    ghinks
    on Apr 26, 2019
    Contributor

    I have just raised an issue with the package phobia team asking for a contact name for the package maintenance team.

  5. ghinks commented on Apr 26, 2019

    @ghinks
    ghinks
    on Apr 26, 2019
    Contributor

    ok, I have a response from the package phobia team. Steven Styfle is our contact. I want to be more precise with our ask. Could I get some clarity on the request we want from the package phobia team. Are we asking them to display badges that represent our package support levels? @Eomm ?

    eg

    support backing
    support target
    support response-def

  6. Eomm commented on Apr 26, 2019

    @Eomm
    Eomm
    on Apr 26, 2019
    Member

    My idea is that, after we build a site as listed in this issue, we could add an icon in that site that link directly to us:

    Example
    image

  7. ghinks commented on Apr 26, 2019

    @ghinks
    ghinks
    on Apr 26, 2019
    Contributor

    understood.
    :)

  8. ghinks commented on Apr 26, 2019

    @ghinks
    ghinks
    on Apr 26, 2019
    Contributor

    @Eomm please feel free to enter the conversation with Steven at package phobia at issue 308 on the phobia github repo.

  9. Eomm
    added
    package-maintenance-agendaAgenda items for package-maintenance team
    on May 6, 2019

  10. Eomm commented on May 13, 2019

    @Eomm
    Eomm
    on May 13, 2019
    Member

    Regarding this bullet point:

    move the tool over to the node repo?

    there is this PR nodejs/admin#343

  11. Eomm commented on May 15, 2019

    @Eomm
    Eomm
    on May 15, 2019
    Member

    Regarding:

    create url on website that generates svg for readme that reports your level and has link
    to the pages which describe the levels.

    I made this poc:
    https://package-badge.herokuapp.com/ repo

    I will list the badges we should provide 👍

  12. Eomm
    self-assigned this
    on May 15, 2019

  13. styfle commented on May 16, 2019

    @styfle
    styfle
    on May 16, 2019
    SponsorMember

    Perhaps you could utilize https://badgen.net if you want to create badges.

  14. Eomm commented on May 16, 2019

    @Eomm
    Eomm
    on May 16, 2019
    Member

    Yeah, the target is like that site: from a package's name get the package.jscon, read the new support tag and build the badges!

    The badge is only a "nice to have" in order to build the really useful stuff:

    • check the supports levels of your package + dependencies
    • spread the knowledge of this initiative (a new green badge in the readme is great 😃)

  15. Eomm commented on May 22, 2019

    @Eomm
    Eomm
    on May 22, 2019
    Member

    Updated the poc (IDK why the badges are always grenn..)

    @nodejs/package-maintenance someone could help me to build a draft gui?
    I think that is necessary:

    • one page as a description of this WG + link to this repo
    • one static page that generates a markdown snipper with the url as above
    • one page that shows the support tag status for all the dependencies (this API is missing right now)

    Here the repo: https://github.com/Eomm/package-badge/tree/poc

  16. 2 remaining items

  17. Eomm commented on Jul 9, 2019

    @Eomm
    Eomm
    on Jul 9, 2019
    Member

    move the tool over to the node repo?

    Done: https://github.com/nodejs/package-compliant

    Invited nodejs-foundation to npm also

    Now we should update it when we will define the new file format of the support file

  18. mhdawson commented on Jul 9, 2019

    @mhdawson
    mhdawson
    on Jul 9, 2019
    MemberAuthor

    @Eomm, thanks !

  19. wesleytodd commented on Aug 25, 2019

    @wesleytodd
    wesleytodd
    on Aug 25, 2019
    Member

    Hey, so as the PR seemed to be in a good state I went and wrote a little helper package. Before I did that I should have looked around here because I would have been reminded of this issue. So, now there are two implementations :)

    My question is, how do we want to move forward? I have a few concerns with "node owned packages". This is basically becomes a "blessed" package. While I think there are some good reasons to do this, it also means that community versions are less likely to exist and might stifle innovation. Is there a precedence for this or are we the first?

    That is the big picture question, but there are tactical issues as well:

    • The version in the node repo has less detail in the json schema, we should probably use a more fleshed out schema definition.
    • The package name package-compliant is not really descriptive of what it does. This is specifically about the new "support" field. This name is not really related in my mind.
    • The version is already >1, but the spec hasn't landed. I think we would want to make the primary implementation line up 1.0.0 with our final version as posted in Support file #220.
    • My package is missing the cli
    • I think any implementation of this should also include a method to get a packages support info (load the pacument or whatever is the right way). Neither has this.

    So with all that, I guess my question is what should I do with my package? I would be happy to contribute it all into the one here if the group thinks that is the best way forward. On the other hand, I think there is some value in the way direction I went.

    I have started progress on three (one not pushed yet) things which are basically ideas from this WG in the pkgjs GitHub Org (I also have the npm scope). If the WG thinks that everything we do should be in the node org, then I can re-assess my direction. I would also be happy to make that Org a community project where we can all take ownership. The longer I write here the more I think this might be worthy of a separate issue altogether....so I will stop for now.

  20. mhdawson commented on Aug 26, 2019

    @mhdawson
    mhdawson
    on Aug 26, 2019
    MemberAuthor

    I'll let @Eomm answer most of the questions since he wrote the first pass of the tool.

    @wesleytodd I don't think everything needs to be in the node organization, but it cases where it will be helpful for it to be we can consider it as an option. The key for me is that it is easy for us to collaborate where it makes sense and that we can easily promote key tools to support the effort. As you said a new issue to discuss the approach on that front would probably make sense.

  21. Eomm commented on Aug 28, 2019

    @Eomm
    Eomm
    on Aug 28, 2019
    Member

    My question is, how do we want to move forward?...

    I think we should focus on one tool right now 😃
    I'm ok to work with yours as well and maybe creating an org as you do could collect many different initiatives (like this one #216 or this one ...etc...) and a faster create-publish-fail, create-publish-fail, create-publish-success that maybe we can't do in the nodejs org 😅
    Am I wrong?

    Is there a precedence for this or are we the first?

    I don't know, looking at the nodejs projects there are a few packages that are not "killer application" let's say

    The version in the node repo has less detail in the json schema

    Yes, it is the very first version of the draft

    This name is not really related in my mind.

    It has been really hard finding that name 🤣 but the thought was that the CLI tool will have many commands, for this reason, I used a generic name

    The version is already >1

    You have right, my thought was to apply all the suggestion we wrote, so I followed this checklist:
    #192 (comment) but now I think I have twisted the versioning.md doc

    My package is missing the cli

    We can add it 💪

    I think any implementation of this should also include a method to get a packages support info

    For sure, but maybe we could create a proposal to npm show directly?

  22. wesleytodd commented on Aug 29, 2019

    @wesleytodd
    wesleytodd
    on Aug 29, 2019
    Member

    faster create-publish-fail, create-publish-fail, create-publish-success that maybe we can't do in the nodejs org

    Agreed, there is some commitment required in putting it into the node org. I think we could also start outside the org and if we finalize something we can move it back in if we think there is value.

    Yes, it is the very first version of the draft

    I figured as much after reading it, sorry if that felt like calling it out :)

    It has been really hard finding that name 🤣 but the thought was that the CLI tool will have many commands, for this reason, I used a generic name

    This is the nice thing about using a scope, you can pick any name which makes sense!

    You have right, my thought was to apply all the suggestion we wrote, so I followed this checklist:
    #192 (comment) but now I think I have twisted the versioning.md doc

    I will open up a PR on that and see what people think, but I have a very clear method for how I start new packages. I think it would be worth adding there and see if people agree with the approach.

    We can add it 💪

    Yeah 🎉

    For sure, but maybe we could create a proposal to npm show directly?

    Well I am always hoping to have a js api which does not require a shell. But maybe the internals of that are in libnpm?

  23. Eomm
    added
    help wantedExtra attention is needed
    toolsThis thing need to be implemented
    on Aug 31, 2019

  24. mhdawson commented on Jan 14, 2020

    @mhdawson
    mhdawson
    on Jan 14, 2020
    MemberAuthor

    Current next actions are:

    • Tweak to reference the funding proposal/fields
      • Idea is to decouple the funding info from the support field, links would be
        References to the funding field.
    • Update pkgs validation tool to support current version (want tooling before we call for input)
    • Broader call for input.

  25. mhdawson commented on Jan 28, 2020

    @mhdawson
    mhdawson
    on Jan 28, 2020
    MemberAuthor

    PR to integrate with npm funding field: #312

  26. mhdawson commented on Mar 24, 2020

    @mhdawson
    mhdawson
    on Mar 24, 2020
    MemberAuthor

    In terms of next steps

    • Tweak to reference the funding proposal/fields
      Idea is to decouple the funding info from the support field, links would be
      References to the funding field.

      • Done

    • Update pkgs validation tool to support current version (want tooling before we call for input)

    *Broader call for input.

  27. mhdawson commented on Oct 6, 2020

    @mhdawson
    mhdawson
    on Oct 6, 2020
    MemberAuthor

    List of modules to get support info into #413

  28. mhdawson commented on Oct 6, 2020

    @mhdawson
    mhdawson
    on Oct 6, 2020
    MemberAuthor

    I'll start with node-addon-api

  29. thescientist13
    added this to the Support Levels milestone on Dec 1, 2020
  30. mhdawson
    removed
    package-maintenance-agendaAgenda items for package-maintenance team
    on Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

help wantedExtra attention is neededtoolsThis thing need to be implemented

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions