7 ms·

It's great to see other JS runtimes progressing, I have a continued frustration with the lack of decent TS tooling and ESM support in Node.js. Jest and Mocha b

It's great to see other JS runtimes progressing, I have a continued frustration with the lack of decent TS tooling and ESM support in Node.js. Jest and Mocha both do not support ESM very well out of the box and there is an expectation that you are using babel to transpile to CommonJS for everything to work nicely. (See Jest's _experimental_ support for ESM mocking!). Node.js is only starting to build out a testing framework, and it has a way to go yet until it has any level of feature parity with the established libraries. Then you have the naive assumption that any package written in JS works with TS. Which is true, they do work, but the missing types will always lead you to look for a TS-first alternative. A good example of this is Joi vs Zod for validation, with the latter performing type inference based on your validation parameters, which is great. But it really does feel like you have a subset of a package ecoystem lurking on NPM. I am not that confident Deno is the answer, but I would say those are my biggest frustration writing production grade JS/TS code today.

denysonique 4y ago
Have a look at https://github.com/esbuild-kit/tsx https://github.com/esbuild-kit/tsx tsx is a CLI command (alternative to node) for seamlessly running TypeScript & ESM, in both commonjs & module package types. It's powered by esbuild so it's insanely fast. I also suggest using its alias: esno
ovao 4y ago
One particularly nice aspect to Deno is its built-in test runner. There’s no complex configuration, like grabbing ts-jest, setting up your transform filters, ensuring that you’re injecting `@jest/types` and then almost invariably spending time debugging precisely why it still can’t grok an export keyword. The Node testing ecosystem has its obvious advantages in terms of how much it’s been buttressed by third-party efforts (which makes it incredibly flexible), but just being able to write a TypeScript test file, run `deno test` and just have it work is really a breath of fresh air.
- johnny22 4y ago
  node has a built in test runner too, but i've not used it yet.
  - ovao 4y ago
    Recently stabilized in v18, yes, and it’s pretty great, but it doesn’t support TypeScript without a transpilation step, so you’ll still need to implement a build pipeline before you’re able to run a test. For pure JS projects it’s quite nice though.
    - johnny22 4y ago
      ah indeed. it should :(
nicky0 4y ago
Your point abour the "TypeScript subset" of the package ecosystem is good. However, I've found TS support (native or via @types/) tends to be a strong indicator of package quality.

denysonique 4y ago

Have a look at https://github.com/esbuild-kit/tsx https://github.com/esbuild-kit/tsx tsx is a CLI command (alternative to node) for seamlessly running TypeScript & ESM, in both commonjs & module package types. It's powered by esbuild so it's insanely fast. I also suggest using its alias: esno

ovao 4y ago

One particularly nice aspect to Deno is its built-in test runner. There’s no complex configuration, like grabbing ts-jest, setting up your transform filters, ensuring that you’re injecting `@jest/types` and then almost invariably spending time debugging precisely why it still can’t grok an export keyword. The Node testing ecosystem has its obvious advantages in terms of how much it’s been buttressed by third-party efforts (which makes it incredibly flexible), but just being able to write a TypeScript test file, run `deno test` and just have it work is really a breath of fresh air.

johnny22 4y ago
node has a built in test runner too, but i've not used it yet.
- ovao 4y ago
  Recently stabilized in v18, yes, and it’s pretty great, but it doesn’t support TypeScript without a transpilation step, so you’ll still need to implement a build pipeline before you’re able to run a test. For pure JS projects it’s quite nice though.
  - johnny22 4y ago
    ah indeed. it should :(

nicky0 4y ago

Your point abour the "TypeScript subset" of the package ecosystem is good. However, I've found TS support (native or via @types/) tends to be a strong indicator of package quality.