Conversation
| @@ -0,0 +1 @@ | |||
| 24 No newline at end of file | |||
There was a problem hiding this comment.
Decided to add this file since a lot of our other repos have it.
| "@types/express": "^5.0.3", | ||
| "@types/mocha": "^10.0.0", | ||
| "@types/node": "^22.0.2", | ||
| "@types/node": "^24.10.13", |
There was a problem hiding this comment.
@types/node is not in the dependabot ignore list. It should be set to ignore majors. That way we get the updates we want without having noise from the ones we don't.
There was a problem hiding this comment.
I'm not sure I agree. @types/node should be mostly backwards compatible, even across major versions, so accepting latest version should be fine even if we're not running our code on the latest version.
There was a problem hiding this comment.
Oh, this is not the devtools repo where we build the binaries. So this is less impactful.
Regardless, the types should be what we build and test on. Not "some potential future version" which will inevitably have new APIs as well.
"Mostly backwards compatible" is the key phrase, particularly the "mostly" part. To build reliable software we need to analyze and know what is on the platform we build to. We shouldn't rely on sheer dumb luck that things work out.
There was a problem hiding this comment.
The tests running successfully should be enough to know if the newest types are sufficient. It's only a dev dependency. We can pull this discussion into an issue rather than this pr if you'd like.
|
LGTM modulo other comments. |
The lockfile got out of sync, in a very odd way. I think npm broke something in a minor in relation to how lockfiles get generated. ## The Problem When [jsonLd](#1280) was updated, something about it [broke the builds](https://github.com/dequelabs/axe-core-npm/actions/runs/22229286256/job/64304204390). But only after getting up to the publish point. The [Node 24](#1281) upgrade got in fine, because it was probably slightly out of sync with `develop`. ## The Solution Update to latest npm with `npm install -g npm` and then `npm install` to refresh the lockfile. Now encoding shows up. This 100% did not work before with an older NPM. So there is a break somewhere in expectations. I narrowed it down to [npm 11.10.1](https://github.com/npm/cli/releases/tag/v11.10.1) that is where `encoding` started to get pulled in. Due to some "hosting" in that changelog, I'm wondering if this is a break from them moving dependencies around. No QA Required
3 participants
No QA required