mhagemeister

7 ms·

1.
Speeding up the JavaScript Ecosystem: JavaScript plugins for Rust tools(marvinh.dev)
5 points by mhagemeister 2y ago|1 comments
2.
by mhagemeister 2y ago
This time we're going to look at the challenges and solutions to making JavaScript plugin support for Deno's Rust-based linter performant.
3.
by mhagemeister 2y ago
Author here. That's good feedback. Looks like that part of my article is a bit confusing and I've updated the phrasing a little to hopefully make it less so. You're spot on with all of your points. The isolated declarations f
4.
by mhagemeister 2y ago
Author here. Agree! The whole npm ecosystem is based around npm packages shipping JS files and doing anything else would break it. I've updated the article to hopefully make it less confusing. The takeaway should definitely not to only
5.
by mhagemeister 2y ago
Author here. True, I think I should've worded it better. I work for Deno and it being a JS runtime that is able to run TS natively makes this less of an issue. The problem that a dependency needs a specific TS version hasn't come
6.
by mhagemeister 2y ago
Author here. I should've worded that better. The recommendation is not to stop compiling TS->JS for npm users. The whole npm ecosystem is built around the assumption that you ship JS and doing anything else would break it. In Deno (
7.
by mhagemeister 2y ago
Oh no, I just woke up and saw this comment. It seems to be up again. Apologies for the inconvenience. Looks like the HN hug of death is real! Happy to hear that you like the series!
8.
by mhagemeister 2y ago
Author here. I should've worded that better in the article. The takeaway should not be to publish only TS sources to npm. The whole npm ecosystem is based around the assumption that you ship .js files and doing anything else would brea
9.
by mhagemeister 2y ago
Author here. Unfortunately, I think worded that a bit confusingly in the article. I'm used to working with runtimes that run TS natively and didn't have to care about .d.ts files myself for a long time. From that perspective creat
10.
by mhagemeister 2y ago
Author here. That's a good point and maybe a matter of perspective. I've worked on projects where using tsc to generate .d.ts files took close to an hour. Even 13s would be too long in my opinion. It should be instantaneously. I g
11.
by mhagemeister 2y ago
Author here. Thanks for sharing that feedback. I think I missed the mark by being so used to working with runtimes that natively run TS files, that I forgot that this is not the default for everyone. The article was mostly written from that
12.
by mhagemeister 3y ago
> I'd like tool to generate the whole package root, including a transpiled or generated package.json That's exactly what JSR does. We generate the package.json ourselves.
13.
by mhagemeister 3y ago
I think you're looking for esm.sh . It transpiles both npm and jsr packages for the browser so that they can be used in a simple script tag.
14.
by mhagemeister 3y ago
The performance of type inference matters for runtimes which work with TypeScript files directly, rather then using the transpiled .js + .d.ts files like Deno. This has several benefits in that we can jump to the source on "go to defin
15.
by mhagemeister 3y ago
yup, we added the `jsr` tool mostly so that you don't have to be aware of the @jsr scope that's used under the hood. We're not publishing to npm though, but rather mapping the @jsr scope to the JSR registry in the project&#x2
16.
by mhagemeister 3y ago
We do some basic inference, but that's why we require explicit return types in the public API, see https://jsr.io/docs/about-slow-types . TypeScript itself will ship with a new `isolatedDeclarations` option in the
17.
by mhagemeister 3y ago
> This makes the already complicated module resolution logic in most bundler/packaging tools even more complicated as they must account for the intricacies of another package manager. A house of cards being stacked on another house
18.
by mhagemeister 3y ago
It's not a secret what jest does. There are a few abstractions to jump through, but I find jest's code very readable overall. By default the `workerThreads` option is set to `false`. Then we reach their `WorkerPool` class which po
19.
by mhagemeister 3y ago
Author here. Compilation isn't the problem, loading and instantiating the module graph is. The timings for that are currently not exposed in any runtime afaik.
20.
by mhagemeister 3y ago
Author here. That's fair criticism. Whilst the setup shown in the article is synthetic, the experience is from working on real world projects. I've worked on a bunch of projects which had about 3000-6000 barrel files easily, and t
21.
by mhagemeister 3y ago
They are unfortunately not removed, because the way they are used makes it difficult for bundlers to detect them. Deno encourages you to submit the original sources which can be even in TypeScript if you want. The users are very close to th
22.
by mhagemeister 3y ago
Glad to hear you like it! Those flame graph screenshots are taken from https://www.speedscope.app/ .
23.
by mhagemeister 3y ago
That's a very good point. Didn't know about the grammarly incident. I could definitely see this happening again with the amount of polyfills in npm packages. Polyfills are usually frozen in time and not developed further after the
24.
by mhagemeister 3y ago
Thanks for the kind feedback! It's definitely something in the back of my mind. I feel like I need to collect a little more content to fill a whole book, but I'm enticed by the thought of writing one nonetheless.
25.
by mhagemeister 3y ago
Yeah, engines are a moving target. I'm all for backwards compatibility, but I'm worried about promoting old node versions with known unpatched security issues. Given that eslint itself only supports node >= 12.22.0 it seems lik
26.
by mhagemeister 3y ago
Author here. Thanks for the kind words! It's feedback like this that encourages me to keep writing about it. I share your experiences regarding babel helpers and haven't found a good solution myself. Similar to you, I often patch
27.
by mhagemeister 3y ago
Author here. Good point. Agree that the ideal scenario would be that the end user (or the tools they use) have the final say in which polyfills to load. It's a bit of a bummer that they are shipped as part of npm packages without an ea
28.
by mhagemeister 3y ago
Author here. That mirrors my experience too on working in various projects. The automatic polyfilling story is such a good thing in theory, but reality isn't as rosy and much more polyfills than necessary are included.
29.
by mhagemeister 4y ago
Author here: Thanks for the kind words! I'm in the same boat as you, profiling is a lot of fun! Yeah, the more you look, the more you realize how many projects have the same or similar problems. Hoping that more folks are aware of thos
30.
by mhagemeister 4y ago
Author here. We decided to open the PR nonetheless as people kept asking us about it: https://github.com/estools/esquery/pull/134

More ›