-
Notifications
You must be signed in to change notification settings - Fork 145
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future direction support field #241
Comments
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). |
@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. |
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. |
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 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). |
I'm not personally bothered by tons of data being in package.json, fwiw. |
I think many people will be bothered by it. It seems to me we can start by supporting |
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). |
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. |
Right - that’s the reason why, until npm adds a feature or two, package.json is the only place it should go. |
@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 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 How do we anticipate people using the data, wherever developers end up storing it? Is it safe to assume that requests for this data ( 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 |
The more input and questions the better!
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.
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.
"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.
Well, if we do it well I hope that we can do something like
I can see running 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 |
For tracking: the discussion in npm/cli#246 is continuing with a wide feedback from Isaacs |
Also, if anyone here wants to chime in there and provide different viewpoints than the one I am expressing, it would be helpful :) |
The --local option is interesting, although my first thought is that if I was using the tool to verify support levels for the packages I'm going to deploy I would want to ensure I have the latest info. Having said that the info can change immediately after I check it so not having fully up to date info must be ok in some situations as well. |
I am not sure we can get around this, we are just in a world of imperfect information. But anything is better than what we have today. With tooling at least we can monitor and check for changes over time. |
+1 |
Adding this to the agenda since the feedback from npm has a great impact on how to continue in this issue, in order to don't create confusion in the community of course Ref: #241 (comment) |
In our meeting today, we discussed the possibility of leaving BOTH options open, allow people to choose whether they want to drop a link or a valid JSON property within the package.json Is there a reason we absolutely MUST pick one or the other before sharing our recommendation for the general structure of the support property? |
Yes, I remain opposed to allowing anything that's not inline, until such time as npm allows updating of metadata without a version bump. |
This is probably a discussion for another thread, but i feel like if that happens, then that is breaking the contract of that particular version, even if it is metadata and doesn't affect the functionality of what the code does. Sorry for the noise, but just wanted to get this thought out there |
This would have to be metadata separate from the version tarball. |
Surely anyone could write the PR, but the key question is, would they accept it :-) |
@darcyclarke any comments on the suggestion in: #241 (comment) |
@Eomm when you said that there are 2 types of package.json that can be downloaded on August 28th one with meta data how are the mechanisms different to fetch them, I ask as I thought plan old curl https://registry.npmjs.org/expressjs was the only option. ( just part of my background on the blog for support :) ) |
I was referring to this doc. For what I saw, the full version is the double time the lighter's version in the worst case. |
I made a few updates to the google draft document as we suggested. After some time for reflection, which is always good, I am hoping we can reach a compromise. As I do not believe either method could be fully satisfied currently without getting the registry involved. |
I'm personally in favor of the URL and then having the exhaustive support information live outside of the package.
I'll try...
I'm not sure I understand the benefit of doubling up on where this information lives, even in the interim.
I'm a bit concerned with having
Again, I'm not sure if package maintainers would want to keep two copies of the same information up-to-date even in the interim (not sure if that's what's being suggested here). On a separate yet related note, I've filed an I believe that focusing on the monetary opportunities, first, for maintainers helps move the needle forward and aligns with I'd love to discuss this more in tomorrow's meeting with the hope that other active/vocal community members can join or provide their own feedback (ie. @ljharb @feross @arcanis @zkochan). Please let me know if there's anything I need to do to specifically add this as an agenda item. <3 |
We had a great discussion in our meeting today. Following that, @mhdawson and I had a productive chat, and here's what we'd like to propose: a package.json field called
The content of the file will match the schema we’ve already discussed. Here’s the use cases we envision:
These will resolve to the location of a JSON file (called Our recommendation will be to use our tooling to manage The effect of this is that, by default, each publish will contain a snapshot of the support data, but the true source of truth is always a file within the package’s repository (or within an external repository). This supports offline and “no external internet” use cases as best as can be achieved. By using a repository, we are using a known set of protocols (git, svn, etc), and creating a pit of success for folks to both store their support data in version control, and also include a snapshot of it in their published packages, with no additional effort. Our tooling will not allow accessing any arbitrary repository URL by default - to avoid privacy concerns, we will survey npm packages for the most common repository hosts (presumably, github, bitbucket, gitlab, etc), and allow-list these by default. Users of our command line tool will be able to override the allowlist, or bypass it, as desired. In the future, if npm sees value in this field, they could, for example, add validation into |
Thanks for the ping! I'm currently in vacations so attending is difficult, but I appreciate being at least aware of the discussion 👐 The proposal described by @ljharb would solve the main issue I had with this proposal. 👍 My only remark is that the |
@arcanis the intention is to respect the directory field (that the npm website already respects afaik); my comment includes an example of doing so. |
@ljharb that outline looks really great. I thought i had while reading is would it be beneficial to try and get the "common case" creation supported in |
Absolutely it would :-) but that’s something we can do iteratively, after we’ve demonstrated some community adoption of the support field via our own tooling. |
@nodejs/package-maintenance can you chime in on the latest proposal in: #241 (comment). If we can get consensus on this we can move on to the next phase of getting broader input. |
Folks: Just FYI, I have to unsubscribe here. I'm slammed now, but finally getting some desperately needed time off next week. Please feel free to @-mention me if there's some specific place where I can help. But please understand that I won't be responding for the next week or so. |
Is this assuming the "no external internet" has access to the most common repository hosts right? |
No, in those scenarios, they would be relying on the contents of the tarball. |
So should the 3rd use case ("sharing the same support data across multiple repos") download the file on installation? I don't understand when the fetch happen in that scenario |
Yes, ideally - but i don’t think that will be a common use case, and our tooling could still download it prepublish for those making that extra effort. |
Fixes: nodejs#241 (comment) Update to add recommended integration with package.json as outlined in: nodejs#241 (comment)
This was the compliant JSON schema for the previous version. Maybe update that with the changes? |
Yes, I think the direction more stable now and we could improve the pkgjs/support package: do you agree to open some issue there to split the job? |
* doc: update with recommended integration into package.json Fixes: #241 (comment) Update to add recommended integration with package.json as outlined in: #241 (comment)
After the publishing of the draft for
support
field inpackage.json
and the feedback process form the community, the ideas to extend moreover that field are:package-support.json
filereference:
#220 (comment)
https://github.com/nodejs/package-maintenance/pull/220/files#r310909069
The text was updated successfully, but these errors were encountered: