fix!: allow react v17, v18 and v19 in peerDependencies and mark them as optional

[XhmikosR]

Fixes #363

[snowystinger]

Can this please get reviewed? we've been using quicklink with react 17 and 18, no issues.

[XhmikosR]

@addyosmani could we maybe land this as a feature? The only issue AFAICT is that we don't test v16, so, perhaps, going back to the minimum support react version would be better?

Not sure how to test both.

[XhmikosR]

@addyosmani what should we do with this? I think the next version should be a major bump since it's so long and that would allow us to land breaking changes like this PR and #368.

[addyosmani]

FWIW, I'm okay with this change. I used the automated update branch option (and haven't otherwise merged it as it says WIP)

[XhmikosR]

@addyosmani So, the new version will be a major version bump? That's why this is in still draft.

[addyosmani]

Yeah let's do that. We can tag and publish a new major version given the range of changes and how long it has been.

[XhmikosR]

@addyosmani maybe you forgot to npm publish the new version?

[addyosmani]

@XhmikosR Didn't forget :) I'm currently locked out of my npm publish privs and am working with them to recover. It'll probably take a few days :)

[XhmikosR]

Ah, I see, good luck! I suppose you will update the website after you publish the new version, right?

…

On Fri, May 2, 2025, 19:49 Addy Osmani ***@***.***> wrote: *addyosmani* left a comment (GoogleChromeLabs/quicklink#421) <#421 (comment)> @XhmikosR <https://github.com/XhmikosR> Didn't forget :) I'm currently locked out of my npm publish privs and am working with them to recover. It'll probably take a few days :) — Reply to this email directly, view it on GitHub <#421 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVLNO3WKXZ6X2QRLBTMJD24OO2VAVCNFSM6AAAAABZUADJFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBXGY3TEMZRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[addyosmani]

@XhmikosR Yes! I finally have publish access again and have just published 3.0.0 to npm. I've locally updated the site but looks like I may need to give the CDNs a little more time to populate with the new version as those refs are currently broken otherwise. I'll check tomorrow and see if its safe to deploy the updated site.

[XhmikosR]

@addyosmani nice :) but it looks like the npm package is missing the dist folder :/

[XhmikosR]

https://www.npmjs.com/package/quicklink?activeTab=code

[XhmikosR]

I suggest that you cut a 3.0.1 version and use the npm scripts this time.

[addyosmani]

@XhmikosR On it. Thanks for the catch!

[XhmikosR]

BTW jsDelivr should be updated automatically, which is what we use in v3.0.0 docs.

[XhmikosR]

I'd do this to be safe (untested):

git clean -dfx
npm ci
# manually bump package.json and package-lock.json version to 3.0.1
npm run release

later we should probably switch to npm version and simplify the release script

[addyosmani]

@XhmikosR Sorry for the back/forth!

• 3.0.1 should now be cut. I've verified the dist directory is now also present for the package.
• Quicklink site deploy has been made using 3.0.1 as well this morning

On the second: mostly a personal note for myself - it is no longer possible to deploy the Quicklink site using a non-Google employee account (why there was a delay from my side there). I'll explore spinning up a separate Firebase project that I can add you too as well in the future.

Thanks for your keen notes during the updated rollout!

Regarding open-PRs: I'm going to be heads down for Google I/O over the next two weeks and will have a delay reviewing pull requests that we haven't already landed. I'll be looking to @gilbertococchi in case there's a strong case for new features to land (just from a second opinion perspective). Thanks again for all the help!

[gilbertococchi]

Hello everyone, I am not opposed to release 3.0.1 as is if there is urgency in doing so.

If there are the conditions to wait some more time (perhaps June) I would suggest consider waiting for this issue #442 that @giorgiopellegrino is planning to work on soon.

The proposed logic on #442 could critically increase the effectiveness and the impact of QuickLink usage of Speculation Rules Prerender in the one-to-many use cases.