search

nodejs / package-maintenance

Repository for work for discussion of helping with maintenance of key packages in the ecosystem.
Other
410 stars 145 forks source link

Next steps on Support levels in Package.json #192

Open mhdawson opened 5 years ago

mhdawson commented 5 years ago
Eomm commented 5 years ago

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:

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.

ghinks commented 5 years ago

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

Eomm commented 5 years ago

Make sure we follow our own guidelines in publishing of tool

These are the steps accomplish by the tool:

Has someone contacted the package phobia folks

Nope

ghinks commented 5 years ago

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

ghinks commented 5 years ago

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

Eomm commented 5 years ago

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

ghinks commented 5 years ago

understood. :)

ghinks commented 5 years ago

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

Eomm commented 5 years ago

Regarding this bullet point:

move the tool over to the node repo?

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

Eomm commented 5 years ago

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 commented 5 years ago

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

Eomm commented 5 years ago

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:

Eomm commented 5 years ago

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:

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

TheHollidayInn commented 5 years ago

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

mhdawson commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@Eomm, thanks !

wesleytodd commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Current next actions are:

mhdawson commented 4 years ago

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

mhdawson commented 4 years ago

In terms of next steps

*Broader call for input.

mhdawson commented 4 years ago

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

mhdawson commented 4 years ago

I'll start with node-addon-api