deno VS tsdx

Given that there is a proposal for adding static typing to JavaScript, based off the State of JS survey, and the fact that Deno has been released with first-class TypeScript support, I'd say it's not going anywhere soon.

> My understanding is that packages are not sandboxed, but your entire Deno process is. Meaning that if one part of my app requires full read/write access then any package included in my app also gets it. Is that correct?

Yes. There has been a discussion on per dependency permissions several times but the conclusions is that it would be difficult to implement and get right semantically. See https://github.com/denoland/deno/issues/171

I bring this up because I get to continue to work in open source in my role at Netlify. Edge functions use the amazing Deno project, a modern open-source runtime for JavaScript and Typescript.

You might want to consider adding Deno [1] to the language examples: https://developers.cloudflare.com/workers/platform/languages...

Deno can compile to wasm, so it can plug in through that vertical. But it's just TS on the frontend.

I'm mainly a python person, but Deno's been the most alluring development in the JS ecosystem since typescript for me. Might be helpful to you all to capture some steam from source.

[1]: https://deno.land/

❯ deno run --allow-net --allow-read ./main.ts error: Uncaught (in promise) NotFound: No such file or directory (os error 2), readdir 'middlewares' for await (const item of Deno.readDir(name)) { ^ at async Object.[Symbol.asyncIterator] (deno:runtime/js/30_fs.js:125:16) at async readFolder (https://deno.land/x/[email protected]/bootstrap/middlewares.ts:8:20) at async initializeMiddlewares (https://deno.land/x/[email protected]/bootstrap/middlewares.ts:27:3) at async createApp (https://deno.land/x/[email protected]/mod.ts:19:3)

Deno (in Appwrite Functions)

To answer the first question "learn JS or TS" the answer has to be JS then TS. Nowadays to become a professional web application developer you need both. You first need a firm foundation in JS before adopting TS. After all, the web browser and Node do not understand TS (unlike Deno). When debugging code, you might have access to source maps that link the obfuscated JS code to the TS instructions but sometimes to need to delve deep into the JS and get as close to the JS processor as possible to discover the root cause of issues.

Edge Functions are very much like serverless functions. You can write them using JavaScript or TypeScript, but instead of using Node.js under the hood, they are powered by Deno — an open source runtime built on web standards. With Netlify Edge Functions, you can transform HTTP Requests and Responses, stream server rendered content, and even run full server side rendered applications at The Edge!

Finally the road to make type checking at runtime opt-in has begun. Took them some time (173 releases) to discern arguments from noise ([^1], [^2]). But rather late than never.

[1]: https://github.com/denoland/deno/issues/11340

[2]: https://github.com/denoland/deno/issues/11340

I'd just add the types as a dependency but if you want to bundle them then afaik https://github.com/jaredpalmer/tsdx can do it (though I have never tried).

We've tried to get answers / offer help over (https://github.com/jaredpalmer/tsdx/issues/1058) and over (https://github.com/jaredpalmer/tsdx/issues/1065). But each time we get no response. Each question is ignored.

We will be using TSDX in this guide as it provides all the necessary dependencies. You can change the name currency-symbol-generator to your own package name, as it will generate a package.json with the same name.

TSDX is no longer maintained - but it was really nice! Is there any project out there that does something similar?

My company has a component library that we package up with tsdx, publish to our org's GitHub package registry, and consume in various applications. The library makes some use of icons from a package called @icons/material. Until recently, all icons were used by importing a default export, like:

The origin story of TurboRepo started with this looongstanding open issue on TSDX from Nate Moore:

TSDX is a great package for npm packages like this and even bundles with size-limit to check your gzipped final bundle size. Keeping a tiny package was really important to me so there are 0 dependencies and size-limit made me realise that simplifying all of my checking functions into 1 or 2 core functions that took options would be a better strategy and help reduce the code size.

At first i thought that this was THE solution but looking deeper at the source code, this tool is a wrapper around a wrapper around a wrapper.... Don't get me wrong, it probably works, but it's currently using a rollup configuration that was created in 2018, the package itself has not seen any updates in 17 months and has 106 open issues. Also the owner says himself that he's not able to work that much on it anymore and suggest to use TSDX which in return hasn't been updated in several months, many open issues and extensive customization is recommended with patch-package which already in itself is a red-flag :(

tsdx - Zero-config CLI for TypeScript package development

I've had luck with https://tsdx.io/ for a component library. It's really easy to use and was able to publish to npm (self hosted nexus) pretty seemlessly!