Package-maintenance: Next steps on Support levels in Package.json

[mhdawson]

• [x] Make sure we follow our own guidelines in publishing of tool
• [x] Get input from 2 of the 'friendly' module owners
• [x] Update or replace tool in pkgs repo to support agreed structure
• [x] 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
  
  
  
  • [x] Blog outlining the support levels and how to use tool to validate
  
  
• [x] 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.

[Eomm]

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](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.

[ghinks]

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

[Eomm]

Make sure we follow our own guidelines in publishing of tool

These are the steps accomplish by the tool:

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

Has someone contacted the package phobia folks

Nope

[ghinks]

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

[ghinks]

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

[Eomm]

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

[ghinks]

understood.
:)

[ghinks]

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

[Eomm]

Regarding this bullet point:

move the tool over to the node repo?

there is this PR https://github.com/nodejs/admin/issues/343

[Eomm]

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 👍

[styfle]

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

[Eomm]

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 😃)

[Eomm]

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

• valid: https://package-badge.herokuapp.com/backing/package-compliant
• doesn't have support: https://package-badge.herokuapp.com/backing/fastify
• doesn't have support + scoped module: https://package-badge.herokuapp.com/backing/@sindresorhus/df

@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

[TheHollidayInn]

I gave it a shot: https://github.com/Eomm/package-badge/pull/1. Feel free to disregard if I'm way off :P

[mhdawson]

With travel I'll probably only get to moving the repo after JSConfEU.

On another note I got some good feedback that end users would find this useful as part of a presentation at the PowerUP19 conference this week.

[Eomm]

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

[mhdawson]

@Eomm, thanks !

[wesleytodd]

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

[mhdawson]

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.

[Eomm]

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 https://github.com/nodejs/package-maintenance/issues/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:
https://github.com/nodejs/package-maintenance/issues/192#issuecomment-485961111 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?

[wesleytodd]

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?

[mhdawson]

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.

[mhdawson]

PR to integrate with npm funding field: https://github.com/nodejs/package-maintenance/pull/312

[mhdawson]

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.

[mhdawson]

List of modules to get support info into https://github.com/nodejs/package-maintenance/issues/413

[mhdawson]

I'll start with node-addon-api