They're now in our documentation to make them easier to find. There's a whole collection of annotated examples on how use Deno. Take them as-is or use them as a reference when you're developing.
Blog Post: I wrote about my struggles trying to open up outgoing net requests in a safe way for #Dropserver apps using #Deno's permissions. It didn't go well 😭
Here's me trying to make sure we ship as secure as possible software, and there's someone who doesn't know how to use an npm ignore file to not ship their shitty docker files in their modules #node#npm
So many #npm projects have a lot of crap in node_modules that are really not needed when deploying apps - SO MANY DOT FILES. I built a script that will clear them all out recursively, just leaving required files. Will probably add *.ts when creating containers.
I've been thinking about restarting work on #Tapir. Development stopped because I hit a wall with the database system. Writing Tapir in #Deno was a long sequence of yak-shaving without much payoff; most of my dev time was spent implementing JSON-LD, Web Signatures, and a database layer that should have been a library if Deno had better Node compatibility at the time.
It's been a while, and the Deno ecosystem has improved a lot. Drizzle looks promising as an ORM layer (better than my hacked-together one), and more Fediverse projects in Deno are popping up (#Fedify looks really cool!). But I'm rethinking Deno.
There were 3 things that drew me to Deno initially:
Ease of install (just run the app from a URL)
Cloud platforms (Deno Deploy w/ Deno KV)
JavaScript (I know the language, and it has a big ecosystem)
#Fedify's tutorial, which previously assumed you were using #Deno, can now be followed using #Node.js and #Bun! (What is Fedify? It's an ActivityPub server framework.)
However, they are written for Fedify 0.8.0, which hasn't been released yet. You can test it with the pre-release version, 0.8.0-dev.164, though.
🚀 Much faster language server
🐢 Key improvements in node:worker_threads and node:vm
💾 Snappy startups with V8 code caching
☁️ New "deno serve" subcommand
🚨 Updates regarding Deno 2
OK, I should really change all my projects that use #npm/#yarn to use #pnpm. If you barely use Node then it's probably not worth it, but for a webdev it now seems like a no-brainer.
@zurmikopa it seems like in any situation where you have multiple node_modules directories pnpm is a no-brainer, because it reuses existing modules instead of having duplicates.
Considering that every year we have a new ambitious replacement for #npm in the JavaScript world, @naderman and @seldaek apparently did a very good job when building and maintaining #composer for #php. Thanks a lot to you two and everyone else involved.
@muhdiekuh Agreed! I also like to believe the #PHP ecosystem aged out of the "prove how clever & right you are" phase. 😅 We're all out here like,
"amazing, thank you, now I can work faster" not "huh, bet I can do better, hold my beer".
We recently launched JSR, a new open source package registry for all of JavaScript (and TypeScript!)
In this post, Luca Casonato dives into how we built JSR to be:
🏅 reliable (100% SLO)
😀 simple to use for publishers and consumers
📦 compatible with NPM
Why would you use #DDEV instead of a #Node or #Python server directly?
There are significant advantages to using a containerized setup like DDEV. We go over them in this article, and include a step-by-step guide to set it up.
@andy_blum helps introduce DDEV to a new audience that may not know about how useful it can be!
Best addition to any #Node package.json, #PHP composer.json or other dependency managers file would be a mandatory „why“ field for each single dependency which requires a minimum number of sensible words.
Could make devs think twice before adding and help (me) when upgrading projects after some time.
Also this is probably the reason I dislike JSON for configuration as I cannot add comments.
Browsing old git commits sometimes helps to find out reasons for dependencies but I also want to understand the same for the tree.
Every dependency in addition to the base framework you might use is a cost and it adds up.
So I would love to see the „cost“ of a dependency before even installing it. Several times I added one and removed it again after seeing what it came with.
@sebobo i think that in PHP this is a lot easier, since you can rapidly find where that code is used due to autoloading definitions, and also because you have tools like Composer Unused to check for unused packages..
Creating new projects in #Deno Deploy is now easier:
⭐️Automatic framework detection
⭐️Optional build step support
⭐️Transparent build and deploy step
⭐️Seamless CI/CD setup via GitHub Actions
@clacke@hongminhee Nope. My point was that the term was inaccurate, and we already have better ones in the context of software development and elsewhere. “Pre-release” typically implies availability to a limited audience.
And don’t lecture me about “most software people.” I’ve been doing this longer than either of you.
Announcement post for #Deno 1.42 talks about Deno 2 as "long anticipated, many times delayed". No kidding!
Still I really appreciate the "DENO_FUTURE=1" env var that removes the deprecated APIs so you can test your code ahead of even a preview release. Nice touch @deno_land .
I just did some prep work for V2 in #Dropserver so I'll def give that a shot. I wonder if they also remove deprecated Typescript types? 🤔
