Just released reactive-vscode 1.0.0-beta.1, with significant improvements in API design :)
kermanx.com/reactive-vscode
Just released reactive-vscode 1.0.0-beta.1, with significant improvements in API design :)
kermanx.com/reactive-vscode
π Because I think this combination makes development the most efficiency.
I love JavaScript but I also want Rust Syntax. I love Rust but I also want GC.
Bringing Rust syntax to the JavaScript world with
@bikari.top.
Rust syntax + JavaScript runtime = "Rust with GC" (wtf
github.com/kermanx/js.rs
I recently tried to implement a TypeScript type inferrer in ~6k lines of Rust. Most of the hardest features are already supported, but there is still a lot of effort to make it usable - and then Oxlint can use the type information for linting.
Repo: github.com/KermanX/simp...
What if giving tree-shaker the ability to infer TypeScript types - Then oxlint can have partial type informationπ€―
btw, object property mangling is not directly related to tree-shaking π Let's think of a new name to replace the temporary one "Tree Shaker" plz π₯Ή
https://kermanx.github.io/tree-shaker/#N4IglgdgDgrgLiAXCApgDygewE5wAQBmMEAxnGJhHiZgLaxwoAmA+lNplCrgJ4AUxANYRMAdwgAaPAENZUgEaKAlHmAAdKtUoBnfIJQ88AXjxCR4vAH48AcgKZMNvIlvzp2GwG4NeLRF14mPIAVsaqPr6EDi6y0hIRvm7YLoryEQC+3po0/pgANigAdHmYAOZ8QcEA2vo8ALpKWeka6Fi4hMRkFFSVKGQs0traYKUQfLEKyuHZOviVYQDyIX1whYPDo3zA6VLAUZgxsng7qnhJKYrHjRE52vlFJeWVhfaY1zO5BcVlFSGFSe9mhAiKRyJQ8ABhOhQLZ4dicABy0loKCu0182BQcBg2CoAB4mGAAG4APmA8KgSJR6TxAHpCaSmi0MDh8CCuuCAIJQGGxFTqTSY7G4vB4qH0OEcSnIlBGYCxdJ4WkkpkQEASEDsFDaLFIECYmi0FEQJjMdUgJiYACykDABB4SAI0jyOo1ztE0h42gAkhA8pAUI7nTr0kA=
Tree Shaker now supports object property mangling!
Most importantly, (unlike some optimizers), Tree Shaker's object property mangling doesn't require any extra assumptions about the input code.
Demo:
Just found that vue-tsc v2.2.0 was out with TypeScript 5.7 support!
Thank you @johnsoncodehk.bsky.social @bikari.top for the hard work! π₯Ή
github.com/vuejs/langua...
Today I officially found an instructor for the research project of tree-shaker. Having lots to learn to become a real PL guy.
π Slidev v0.50.0 is out!
This version is packed with so many updates, @kermanx.github.io and the team were truly on π₯
π€ Export your slides right from your browser
β‘οΈ Vite 6 and Jiti 2
π Improved VS Code ext
π Dropped Prism.js, fully on @shiki.style
π A lot of bug fixes
github.com/slidevjs/sli...
π Hey Python Folks! @kermanx.github.io Just made the Python Runner for Slidev, which allows you to edit and execute actual Python snippets during your presentation!
Give it a try, and we are excited to hear your ways of using it!
github.com/KermanX/slid...
Despite this problem, it's making progress! It was made 3.4x faster 4 days agoπ₯°
codspeed.io/KermanX/tree...
Another option is to use a new "consumed dependencies" scope for each pure call, but this will make consumable impossible to use a flag to avoid being referred twice (for performance). Because entities can be consumed in a pure call, and later in a non-pure.
I once tried making the return value a "computed" with every consumed thing in the function execution as its dependency, but this is quite tricky and buggy because every consumed dependency have to be attached to something in the pure call.
In tree shaking it should be something like "If and only if the return value is retained, retain the function call". However, there is no way to know whether the return value is used or not before completing the analysis of the whole program.
Why is it so hard to support the `@__PURE__` annotation in my tree-shakerπ₯² For DCE, it is just "remove the call if the return value is unused". But for tree shaking, I can't think of a correct & performance-acceptable way to support it.
Interesting π
βΆοΈπ¦