-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
base: dev
Are you sure you want to change the base?
Conversation
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.
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). |
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. |
A possible alternative would be to feature gate |
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.
wasn't thinking about straight bugs but rather us forgetting to update both branches (based on past mistakes)
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) |
@lucasfernog @Legend-Master any hard feelings? |
Package Changes Through 5a92618There 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 VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
@FabianLars The PR to wry needs to be released first, then I'll update to include it. |
yepyep, idk why i started ci here tbh, probably muscle memory. |
I'm not 100% sure but I believe the old Don't mind inlining it either, I feel like we don't do much on v1 right now anyways and v3 is sorta coming |
if you mean something like |
Yes, that is right, only the config module had to be inlined. |
The subtree involving
kuchikiki
andhtml5ever
holds back a number of dependencies from updating. This PR is a small step towards updating that subtree, which containssyn 1.0
andrand 0.7.3
.This updates just
kuchikiki
andhtml5ever
to the most recent version both are compatible with. The update was not as straightforward as initially assumed. Merging this PR removes the dependency ontauri-utils 1.0
, which was leading to cargo dependency resolution errors, and inlines unstable functions fromschemars
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 updatewry
in the same way is here.