A place for developers to talk about building on Farcaster.

/dev

building /automod (channel moderation), /glass (no code frames) • uncurated.xyz
• prev @manifoldxyz, twilio

deno does all that at the runtime level with zero dependencies

out of the box Deno supports
typescript
jsx/tsx
bench
compile to executable
coverage
doc gen
fmt
lint
workspaces
jupyter
pkg publishing
task runner
testing
yarn/p/npm compatibility
yarn/p/npm workspaces compatibility
almost all of node core mods (ie `node:http`)
version manager (it upgrades itself)
got tired of typing

https://github.com/o-az
—
https://x.com/awkroot

I use Deno extensively. It’s great but still lots of rough edges. URL imports are great but makes peeking and debugging 3rd party code harder. But thankfully they are bringing native node_modules/ support in Deno 2 (BYONM)

Engineering @neynar. Amusement, wonder, and uncertainty ✴︎ libred.org

- stacktraces are URLs instead of local paths, making it harder to peek into code from the terminal,
- some packages don’t work well with Deno, esp. those using WASM modules (ex. vercel/og)
- WASM imports are not implemented yet
- Deno.land and jsr registry is quite small. Jumping between them and npm is frustrating. 
- the alt is to always fallback to npm registry but then you miss esm-native tree shaking and ts source code preview,
- resolving remote import url to local transpiled code (stored in DENO_DIR)

can you give some rough edges examples?

my experience has been that:
issues that cause me to need to inspect node modules are far less common when in a pure esm environment