dsherret.bsky.social
Software developer at Deno. Also working on ts-morph, dprint, and more (https://github.com/dsherret)
87 posts
1,286 followers
69 following
Regular Contributor
Active Commenter
comment in response to
post
Yeah, essentially just `node.text += "?bytes"`. I'm pretty sure it's going to break when TS does some refactorings, but I'll deal with fixing that in the future.
comment in response to
post
We use TS via the API so we can resolve specifiers based on their location. That said, once resolved, TS will cache the lookups keyed by specifier and node resolution mode only (github.com/microsoft/Ty...). To work around this, we trick TS into thinking each import attribute is a unique specifier.
comment in response to
post
We're probably going to do it later to improve node compatibility, but JS loaders are not so great because it creates a decent amount of extra complexity, is slower, and is not as portable or standard.
comment in response to
post
Couple things: github.com/whatwg/html/... github.com/tc39/proposa...
Also, probably waiting on github.com/tc39/proposa...
comment in response to
post
Yup.
comment in response to
post
Oof that's terrible. Sorry to hear!
comment in response to
post
I skip stairs going down. I've wondered when and how I'll find out I can no longer do that.
comment in response to
post
bsky.app/profile/dshe...
comment in response to
post
It's very untested and probably won't work in many scenarios, but it's a start. Bugs can be reported here: github.com/denoland/rol...
comment in response to
post
That sucks! Sorry to hear that :(
comment in response to
post
This is crazy and I'm sorry to hear. I hope you'll find a way to continue contributing to the ecosystem.
comment in response to
post
Nice. Thanks!
comment in response to
post
I've only found rust-lang.github.io/rust-clippy/... which seems to only error when there's a single variant left and not multiple.
comment in response to
post
In the past I did something similar for dprint here... basically if there's a graph then it's almost always useful to have an easy way to visualize it: x.com/DavidSherret...
comment in response to
post
Deno's npm resolution uses a one directional graph and maintains a reverse path through the graph for where it's currently resolving (shown as the red line).
comment in response to
post
I think there needs to be something more restrictive that allows for doing isolated work in parallel while having native and js (non-parallel) targets. I was thinking about this earlier and did a bit of work exploring. The problem is use cases are small.
comment in response to
post
Also, this was C# WinForms. While there I created a development only ctrl+i tool for inspecting/modifying controls at runtime that I was quite proud.
comment in response to
post
In real life, this wouldn't be used for surgery though. You'd plan your trajectory using this pre-op then export it to the surgical navigation software for surgery (which I also worked on and it reused a lot of the code seen here, but it had live tracking of the surgeon's tools)
comment in response to
post
Not a vite plugin, but this is done here and minifies the d.ts files: github.com/dsherret/ts-...
comment in response to
post
It would be too expensive and unsustainable to make jsr a cdn in addition to a registry in my opinion. It’s something someone could build on top of the registry. Related issue: github.com/denoland/den...
comment in response to
post
Ways to mitigate that are to use a frozen lockfile (docs.deno.com/runtime/fund...) or Deno's permission system.
comment in response to
post
A contributor recently added a dependency graph: jsr.io/@david/path/...
I should note that within Deno it's possible for packages to escape this static analysis and use a non-statically analyzable dynamic import to import from any package on JSR (not outside JSR, because it errors for that).
comment in response to
post
Wow, it installing from a fork is very bad.
comment in response to
post
Another reminder that the npm client just installs dependencies from anywhere: x.com/DavidSherret...
comment in response to
post
I submitted this in a report to npm, but it was closed as being an intentional design decision. Previously I submitted a report about how the dependencies tab showed these dependencies as being npm packages (not remote ones) and I guess the fix was to just not show them at all.
comment in response to
post
When it's only that they're all the same, but when there's __esModule = true then Bun behaves incompatibly with Node.
comment in response to
post
It's a confusing topic. Just to be clear, Deno used to do that, but decided to align with Node for better Node compatibility. Here's the output of that today.
comment in response to
post
My criticism of Bun here is it has by design (bun.sh/blog/commonj...) decided not to be compatible with Node's ESM/CJS interop, which creates scenarios where npm pkgs don't work across all runtimes without changing code. Pkg authors need to be aware of this when importing certain cjs pkgs from esm.
comment in response to
post
It would have been nice if Node designed it that way, but from my understanding it wasn't done because they found it wasn't always statically analyzable (not sure I agree with that decision). Deno initially respected __esModule at the npm package boundary, but we were persuaded to align with Node.
comment in response to
post
To get `add` to be the default import in esm, the cjs needs to do `module.exports = add`. This is regardless of the __esModule property. Node decided not to respect that convention. I'm not sure if that was the right move, but it's the way things are.
comment in response to
post
To clarify what's going on here, the cjs has `exports.default = add`. That's like doing `const obj = { default: add }; module.exports = obj;`. The way Node was designed is the default import is what's assigned to `module.exports`, so obj becomes the default import and thus `.default` is necessary.
comment in response to
post
For stuff like importing `export = function (){}` in esm, I'm not sure what could have been a better solution. Maybe an imperfect solution like importing a specially named named export?
comment in response to
post
IIRC default imports were specifically added for ESM/CJS interop because of stuff like `export = function(){}`. Part of the problem was many years of using esm imports/exports via babel/typescript in cjs files. In retrospect, maybe they should have banned default exports in those fake es modules.
comment in response to
post
Any npm package doing this will error in Bun and any pkg author that gets it to work in Bun will get reports of errors from their Node/Deno users. Package authors are going to have to inspect the default and namespace import to get certain scenarios working across all runtimes.
comment in response to
post
@kt3k.org thought of a clever way to get a Uint8Array<ArrayBuffer> type in TS 5.7 and Uint8Array type in <TS 5.7. Much better to rely on this than the above.
comment in response to
post
This seems to work in all 5.x versions with all script targets.
comment in response to
post
Or I guess also check for non-existent globals, but all this won't work with certain lib options.