serde_v8 improvements to avoid hitting unimplemented codepaths #13915
Conversation
|
|
…ndle Javascript Map objects properly & Handle chars and bytes without panicking
It makes it difficult to integrate it with other projects. Deno itself is not affected as cargo will still honer the fixed version definitions from the other crates.
|
@AaronO please review |
arthurprs
changed the title
|
I updated the PR to fix the merge conflicts and to account for other recent PRs. |
|
@arthurprs sorry for late response, please rebase and we'll merge it |
arthurprs
force-pushed
the
main
branch
3 times, most recently
from
4a47fac
to
6db684a
Compare
|
No problem. The PR is now merged with the upstream repo. |
| # Stay on 1.6 to avoid a dependency cycle in ahash https://github.com/tkaitchuck/aHash/issues/95 | ||
| # Projects not depending on ahash are unafected as cargo will pull any 1.X that is >= 1.6. | ||
| indexmap = "1.6" |
There was a problem hiding this comment.
I believe so, there hasn't been much movement trying to break this dependency cycle tkaitchuck/aHash#95. Luckily it doesn't pose any significant problems for Deno.
There was a problem hiding this comment.
Right, but we were already on v1.8.1, so why downgrade?
There was a problem hiding this comment.
This is not a real downgrade but a downgrade of the "minimum" minor version for 1.*. deno cargo.lock still defines 1.8.1 and will go up as needed as long as it's < 2.
At the same time, if we don't downgrade the minimum minor version any crate depending on deno_core (like the project I'm trying to use deno in) also uses ahash (or any of the other problematic dependencies) it won't compile as cargo won't be able solve the dependency cycle.
I've made some chances in order to avoid silent data loss and hitting unimplemented code paths, some of it might be opinionated though. Let me know what you think.
Rusty v8 related
There are also some changes wrt. deno-core dependencies so it's easier to use outside of deno.