fix: spelling in ./lib and ./test/lib

[jsoref]

Spelling errors hurt usability/readability

References

[wraithgar]

@jsoref I'm not sure how automated these are but one thing that may be of interest to you if you have the energy for it is comment length wrapping.

Originally our linting enforced a HARD limit of 80 characters for every line. That limit was later relaxed to 100 characters. This was primarily because of code quality: the longer a line of code is the harder it is to work out what every part of it does, and also it's more likely to be too complicated and prone to bugs. Unfortunately this limit was also applied to comments. We consulted with quite a few a11y folks, especially those who are knowledgeable about screen readers, and learned that wrapping comments makes them MUCH less accessible. We have since updated our linting rules to allow for lines of unlimited length when doing things like generating strings, and comments.

So, the linting allows comments to be long now, but we didn't go back and clean them up. We do that as we see them. It's a tough thing to automate because some comments still need to be multiple lines for various reasons. If this is something inside your umbrella of interest we'd welcome PRs that cleaned these up. We know it's a lot of work, so don't feel pressured to do it.

[jsoref]

A bit about my tooling (check-spelling):

1. Everything is line oriented.
2. Analytics is very automated. See https://github.com/check-spelling-sandbox/npm-cli/actions/runs/18107826182 for a sense of what it's doing.
3. Fixing is only sort of automated. Mostly if there's a literal string that can be replaced with another literal string, then I can replace one with the other and have some tooling to do that and make a commit.
4. For everything else, I'm just using whatever editor I have (which these days is usually VSCode unless it trips on something in which case I'll probably use vi or perl).

Because everything in my tooling is line oriented, my tooling can't help you (at best it could warn if it found something that it suspected was a wrapped line that should probably be unwrapped, and I'm not even sure it could do that because it's line oriented... it'd be a pretty painful pattern to try to write).

I split things out here because it seemed like it'd be worth it to help a bit more -- a number of my PRs of the scale of what this combined series would of been have recently been unceremoniously killed with claims that I did something wrong and I didn't want to risk that for this project. (I've also been accused of being AI more times than I want to count of late...)

In general, I'm mostly just working on my tooling or applying fixes to repositories and then moving to the next repository (while working on this repository, I fixed a bunch of bugs in my tooling although I don't think they specifically related to this repository, I was just doing it concurrently).

OpenRewrite is probably your best bet for the problem you're describing. I've worked w/ them a bit but haven't actively used their tooling. I am fairly confident that their tooling isn't line oriented which means it should be able to help.

I'm definitely doing more here than I would for a totally random project -- I use npm and the npm ecosystem so it makes sense for me to contribute, plus even if I wasn't directly using npm, a large portion of the other random projects to which I make PRs do, so fixing bugs in npm is valuable for me effectively daily.

Within limits, a somewhat stupid perl expression might be able to help, if it could find the beginning of a multiline comment and decide that it isn't a multi-paragraph comment. As long as it could also find the end of the comment and then do some vaguely simple work to fold whitespace.

It's an interesting problem. If you gave me two or three specific examples of cases you'd want unwrapped as well as two or three examples of cases you don't want unwrapped, I'd be open to looking into it. Note that I have very little time for most of the rest of this month for various reasons, so I definitely can't guarantee any particular response time. If you use slack/irc/discord/signal, I could look into things there (we could also just create a discussion/ticket and I could iterate there, although for things like this, I'd probably prefer something that isn't github until I have something vaguely workable).

[jsoref]

@wraithgar btw, does this apply to markdown?

my general preference is one line per sentence, as opposed to randomly splitting lines at columns:

cli/docs/lib/content/configuring-npm/package-json.md

Lines 505 to 508 in 51e3ec8

	Because of the way the `bin` directive works, specifying both a `bin` path
	and setting `directories.bin` is an error. If you want to specify
	individual files, use `bin`, and for all the files in an existing `bin`
	directory, use `directories.bin`.

Because of the way the `bin` directive works, specifying both a `bin` path  and setting `directories.bin` is an error.
If you want to specify individual files, use `bin`, and for all the files in an existing `bin` directory, use `directories.bin`. 

That makes blame better when people want to fix things (in this case, the tooling doesn't like the way the and would prefer the way that the).

[wraithgar]

Yes it applies to markdown. Anything intended for a human to read, as opposed to something intended for the computer to parse.