Skip to content

Update kuchikiki and html5ever #13629

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

Open
wants to merge 5 commits into
base: dev
Choose a base branch
from
Open

Conversation

sftse
Copy link
Contributor

@sftse sftse commented Jun 17, 2025

The subtree involving kuchikiki and html5ever holds back a number of dependencies from updating. This PR is a small step towards updating that subtree, which contains syn 1.0 and rand 0.7.3.

This updates just kuchikiki and html5ever to the most recent version both are compatible with. The update was not as straightforward as initially assumed. Merging this PR removes the dependency on tauri-utils 1.0, which was leading to cargo dependency resolution errors, and inlines unstable functions from schemars that were relied on and no longer exist.

This depends on a private updated version of wry with which it will compile. The PR to update wry in the same way is here.

@sftse sftse requested a review from a team as a code owner June 17, 2025 16:27
@github-project-automation github-project-automation bot moved this to 📬Proposal in Roadmap Jun 17, 2025
sftse added 4 commits June 18, 2025 10:41
tauri-utils/deps: update kuchikiki and html5ever
tauri-runtime-wry/deps: update wry to match kuchikiki and html5ever versions
Without this, cargo resolves the patch version of schemars to one that
does not include the _private module on which tauri-utils v1 depends,
which is a dependency of tauri-cli. As a result of this, the build breaks.
@FabianLars
Copy link
Member

i really appreciate the work you've poured into this, but is this really the only way? What about some feature flags to control the used deps in the v1 crate perhaps?

having to duplicate the code and maintain it in multiple places is something i really really want to avoid (think about more major versions as well).

@sftse
Copy link
Contributor Author

sftse commented Jun 18, 2025

I think that would depend on whether v1 is EOL and no longer supported or still receiving maintenance patches. As more major versions are released it becomes increasingly tedious to patch previous versions to prevent pulling along the old dependencies.

In this case, imho the trade-off is in favor of inlining the module. The majority of the inlined code is type definitions and the probability of a bug there is low.

It may make sense to remove v1 code entirely if v3 is released. This would mean v1 users cannot automatically migrate to v3, which seems reasonable.

@sftse
Copy link
Contributor Author

sftse commented Jun 18, 2025

A possible alternative would be to feature gate html5ever and kuchikiki in tauri-utils v1 and remove its use of private api functions from schemars. But that is a temporary fix, on a long enough time frame all tauri-utils v1 dependencies are likely to become outdated.

@FabianLars
Copy link
Member

I think that would depend on whether v1 is EOL and no longer supported or still receiving maintenance patches. As more major versions are released it becomes increasingly tedious to patch previous versions to prevent pulling along the old dependencies.

What i had in mind was that we've had a few v1 config updates even after v2 was released. But i guess there's a somewhat high chance we'll have to make changes in the migrator anyway.

In this case, imho the trade-off is in favor of inlining the module. The majority of the inlined code is type definitions and the probability of a bug there is low.

wasn't thinking about straight bugs but rather us forgetting to update both branches (based on past mistakes)

It may make sense to remove v1 code entirely if v3 is released. This would mean v1 users cannot automatically migrate to v3, which seems reasonable.

i'm in favor of that at least even ignoring this discussion here.


you know what, i changed my mind. since there isn't really any work being done on v1 anyway anymore. with better MSRV policies in the future we also shouldn't hit issues like this again so in the v3 cli we may not have to inline the v2 config (or with 1.77 we may have to wait for v4)

@FabianLars
Copy link
Member

@lucasfernog @Legend-Master any hard feelings?

Copy link
Contributor

Package Changes Through 5a92618

There are 8 changes which include tauri-bundler with minor, tauri-cli with minor, tauri-codegen with minor, tauri-utils with minor, @tauri-apps/cli with minor, tauri with minor, @tauri-apps/api with minor, tauri-runtime-wry with patch

Planned Package Versions

The following package releases are the planned based on the context of changes in this pull request.

package current next
@tauri-apps/api 2.5.0 2.6.0
tauri-utils 2.4.0 2.5.0
tauri-bundler 2.4.0 2.5.0
tauri-runtime 2.6.0 2.6.1
tauri-runtime-wry 2.6.0 2.6.1
tauri-codegen 2.2.0 2.3.0
tauri-macros 2.2.0 2.2.1
tauri-plugin 2.2.0 2.2.1
tauri-build 2.2.0 2.2.1
tauri 2.5.1 2.6.0
@tauri-apps/cli 2.5.0 2.6.0
tauri-cli 2.5.0 2.6.0

Add another change file through the GitHub UI by following this link.


Read about change files or the docs at github.com/jbolda/covector

@sftse
Copy link
Contributor Author

sftse commented Jun 18, 2025

@FabianLars The PR to wry needs to be released first, then I'll update to include it.

@FabianLars
Copy link
Member

yepyep, idk why i started ci here tbh, probably muscle memory.

@Legend-Master
Copy link
Contributor

Legend-Master commented Jun 18, 2025

I'm not 100% sure but I believe the old tauri-utils was only pulled in for the config files, would it make sense to feature gate things? (considering these 2 dependencies are gated with html-manipulation in v2) (to be honest I feel like it might deserve its own crate 😂)

Don't mind inlining it either, I feel like we don't do much on v1 right now anyways and v3 is sorta coming

@FabianLars
Copy link
Member

(to be honest I feel like it might deserve its own crate 😂)

if you mean something like tauri-config then that thought struck me a few times the last few weeks as well. I think the utils crate does too much.
i think the acl module would be a good target for another crate as well but didn't really look at it (nor did i work in it ever).

@sftse
Copy link
Contributor Author

sftse commented Jun 18, 2025

I'm not 100% sure but I believe the old tauri-utils was only pulled in for the config files, would it make sense to feature gate things? (to be honest I feel like it might deserve its own crate 😂)

Yes, that is right, only the config module had to be inlined.
I'm cautious about feature flags as exponentially many combinations need to be tested and when dependency resolution does not work as expected it can be quite time consuming to fix. Doing this upgrade with the inline code would have been trivial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📬Proposal
Development

Successfully merging this pull request may close these issues.

3 participants