Future direction support field

[Eomm]

After the publishing of the draft for support field in package.json and the feedback process form the community, the ideas to extend moreover that field are:

• reference a file via an URL field
• a separate package-support.json file

reference:
#220 (comment)
https://github.com/nodejs/package-maintenance/pull/220/files#r310909069

[ljharb]

I’d want a separate file - so it can be immutably stored in package registries - but only if the file can be updated without a full publish, and also read without downloading the full tarball.

[lholmquist]

I’d want a separate file - so it can be immutably stored in package registries - but only if the file can be updated without a full publish, and also read without downloading the full tarball.

If you are able to change a file without a full publish, wouldn't that make it mutable? since you are changing something inside a particular version(it seems sort of analogous to a force push to master, maybe not as bad, but the same idea).

[ljharb]

@lholmquist it's always "mutable" with the current proposal in the sense that you can just publish another "latest"; what is immutable is the history of edits (which could easily be made programmatically available), and the availability of the file.

[lholmquist]

right, "latest" is mutable since it is really just a pointer to a particular version. but the files that that tag is pointing should be immutable. And if you are able to update a file in a particular version without a full publish/version bump, then i don't think we can say that that version is immutable. I think that is what i was trying to say in my other comment.

If you want to change that file, then i think you need to bump the version, and publish it.

I get there could be a programttic way of reading the history of edits, but that is an extra step that someone could miss, or not know about.

[wesleytodd]

I was working on a json schema for the spec and made this example trying to exercise many of the features of the spec. Imagine this in our package.json 📦 🤦‍♂

I think it is clear that we need an external file. That said, I think there is a strong case for making it relative to the package (so the file must be shipped with the package), not any URL (as @ljharb poitns out leads to issues).

[ljharb]

I'm not personally bothered by tons of data being in package.json, fwiw.

[wesleytodd]

I think many people will be bothered by it. It seems to me we can start by supporting "support": "support.json" style because it is local to the package install. This would allow those who care to separate it out, and not hinder any of our core goals around history and immutable availability.

[Eomm]

The problem is that npm let you download only the package.json (in two sizes, one minimal with less information, and one with all the metadata).
If you want something else you need to download the tarball

[mhdawson]

Adding to @Eomm comment, if a tarball needs to be downloaded then that greatly increases the download required for tools that consume the new information.

[ljharb]

Right - that’s the reason why, until npm adds a feature or two, package.json is the only place it should go.

[kemitchell]

@ljharb, thanks for pointing me here from npm/cli#187. I hope folks don't mind a few stray thoughts and up-to-speed questions.

I think it's safe to say that a great many package consumers rely heavily on URL-based pointers from package.json files already. Specifically, once we know that repository has a GitHub or BitBucket URL, we know that's our best bet for up-to-date information on bugs, changelog, patch submission, and consumer-to-producer comms more generally. When we open the code host page, we can look to README.md---the latest on master, not the one that came from the registry---for CI badges, documentation site links, chat channel buttons, and so on. There's just no guarantee that yesterday's hot new channel will make it to the next version. We've all seen patch releases replacing Slack channels with Gitter, or Gitter with Slack, or Slack with IRC or just issues again. A lot of us have tried a few different sustainability-as-a-service platforms, and forgotten to update some of our packages.

If you're trying to do automated dependency assessment, perhaps by modeling risk on the availability or throughput of support channels, I don't think the pain point is lack of information. Rather, it's that some dev has to sift through all the repo webpages, click all the right links, and tally up all the actually relevant URLs. Much the same story if you're trying to take some kind of action---send thank-you e-mails, send donations, ask for support contracts---across many packages. Some of what PACKAGE-SUPPORT seems to be gunning for is structured data for facilities that haven't been well structured before, like support channels. But big chunks of it, specifically backing, basically map packages to other URLs.

How do we anticipate people using the data, wherever developers end up storing it? Is it safe to assume that requests for this data (npm support?) will be far less frequent than requests to install the packages (npm install)? Is it safe to assume that people will get to specific package versions through their node_modules directories, or will they come to packages as packages, with an assumption they'll keep up-to-date with the latest release?

I suspect the back-and-forth on where to put this data, no matter how it's encoded, reflects unexplored differences in how you imagine the data being consumed. But that's a guess. I'm a recent interloper here. ;-D

[wesleytodd]

I hope folks don't mind a few stray thoughts and up-to-speed questions.

The more input and questions the better!

I think it's safe to say that a great many package consumers rely heavily on URL-based pointers from package.json files already

You make a good point, but I would also like to add the counter argument that many package links are broken. I often click github links which have are a 404, I am sure the other cases are similar. I don't say this as a blocker to the idea, just that it is not a perfect solution.

Some of what PACKAGE-SUPPORT seems to be gunning for is structured data for facilities that haven't been well structured before

Yes this is IMO one of the main goals of this proposal. If we have structure we can write reliable tooling, educate the community on it in a reasonable way, and help a broad range of people instead of each group going in their own direction.

But big chunks of it, specifically backing, basically map packages to other URLs.

"Basically" I agree, but the devil is in the details. I think the structure we have defined gives more than just a list of links. The difference between "I want to donate to projects I use" and "I want to use projects which offer paid support plans" is quite different. Just a list of links does not help answer this question.

For example, I think a company might ask the second question, and IMO getting companies to "pony up" is one of the best ways to raise meaningful financial support for projects. Having this explicitly in the spec is important for this goal IMO.

Is it safe to assume that requests for this data (npm support?) will be far less frequent than requests to install the packages (npm install)?

Well, if we do it well I hope that we can do something like funding was doing where it only showed once and is a relatively clear and clean UX. So if we do that, then we can run npm support on all installs, and it would just show the new or important information to users. Very similar to npm audit's behavior.

Is it safe to assume that people will get to specific package versions through their node_modules directories, or will they come to packages as packages, with an assumption they'll keep up-to-date with the latest release?

I can see running npm support package-name and have it look locally then remotely. I can also see this interaction also being something that always does a network request to get the up-to-date file. Maybe doing npm support --local so that you can run w/o network.

I just think we can evolve the use case over time as we see clear reason. I think the important thing is making sure we don't make any of these impossible in the future. So to me, allowing url's which are not resolved into node_modules excludes the use case of --local, which to me means we should not allow it in the spec for now until we can understand more of the use cases.