ensure node support since node 10

[Uzlopak]

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Fdawgs]

But why? Node 10 became EOL almost 4 years ago, and Node 14 nearly 2 years ago.

[Uzlopak]

Unfortunately I think we need to keep up the contract with ajv, which supports node 10 till latest. :/

[Fdawgs]

From looking at the ajv repo, they don't have an engines value in the package.json, and they only test from node 16 onwards in their GitHub Workflows.

No mention of a minimum Node version on the ajv site either 😬

[Uzlopak]

[Fdawgs]

God damn it. Going to make a PR over there then for them to test on node 10+.

[Uzlopak]

@Fdawgs
Maybe they removed it with purpose? Idk. :/

ajv-validator/ajv@43d6164

[Fdawgs]

@Fdawgs Maybe they removed it with purpose? Idk. :/

ajv-validator/ajv@43d6164

You're right, Ajv won't even build with Node 10: https://github.com/ajv-validator/ajv/actions/runs/12629749595/job/35188245130?pr=2522

[Uzlopak]

Maybe we should ajk @epoberezkin to clarify the docs and remove node 10 - 14 as supported environments?

[Fdawgs]

Maybe we should ajk @epoberezkin to clarify the docs and remove node 10 - 14 as supported environments?

ajv-validator/ajv#2523 :)

[climba03003]

To be fair, ajv is using TypeScript and targeting to ES2018 which can be run on node@10.
The CI build failure only tells it cannot be built on old system but it doesn't shows it can't run on old system.

The proper CI should be built on fixed version (maybe 22) first, then run the test on the supported system.

[Fdawgs]

Thanks @climba03003, so i guess best thing to do would be to revert the optional chaining and add Node 10 - 14 to the CI?

[Uzlopak]

@Fdawgs
@climba03003

I think I made the proper changes, to fix it here. How should we progress?

I basically fix also the transient fast-uri dependency of ajv to ensure that it really works.

[climba03003]

Yes, it also affect fastify@4 users.
We can land the optional chaining and bump a major.

[Uzlopak]

@climba03003

I dont think that we should bump a major here and make it depending on the versioning of fastify. This is a library and not a plugin of fastify.

[Fdawgs]

I'll do a quick release, thanks @Uzlopak

[climba03003]

I dont think that we should bump a major here and make it depending on the versioning of fastify. This is a library and not a plugin of fastify.

The question is actually simple, are we continue to support node@10 based on the downstream package (ajv)?
If yes, then remain the same.
If no, we must break some downstream again in order to use latest feature.

[Uzlopak]

@Fdawgs
@climba03003

We should maybe discuss this in contributor discussions, because we have other libraries in our org. Probably we need to decide if specific dependencies have "api contracts" with other projects. Here we have the special case, that we provided fast-uri as replacement of urljs to ajv and basically bound our library to ajv in a strong bound. Maybe we need to document this strong bound in the readme md. Like "this library works with ajv v8" and thus makes it mandatory to support the same range of engines.

Maybe @epoberezkin clarifies, that node 10 is not supported anymore, but this could result in alot of changes in upstream projects. I see issues in angular and stuff.

To be honest, I dont like the idea, that we have to carry projects, were node 12 is used to build the project. The maintainer should then switch to latest node. But this does not answer the question if ajv is purposefully supporting node 10+. Lets see what happens.

[gurgunday]

Nit but parsed.fragment would also cover the length check here if a string indeed exists

[Fdawgs]

@gurgunday Fancy throwing a PR together?