5 ms·

My favorite deno feature is coming to node directly. Awesome! Maybe this means I don't always have to install esbuild to strip types - very excited how this wi

My favorite deno feature is coming to node directly. Awesome! Maybe this means I don't always have to install esbuild to strip types - very excited how this will make writing scripts in TypeScript that much easier to use. I lately have been prefering Python for one off scripts, but I do think personally TypeScript > Python wrt types. And larger scripts really benefit from types especially when looking at them again after a few months.

yamumsahoe 2y ago
correction: the only deno future that i want
- sholladay 2y ago
  Deno has so many other great features. Most web standard APIs are available in Deno, for example. It can do URL imports. It has a built in linter, formatter, and test framework. Built in documentation generator. A much better built in web server. Node is copying many of these features to varying degrees of success. But Deno is evolving, too.
  - johnny22 2y ago
    the url imports is one the things I don't want.
    - niklasmtj 2y ago
      There are also the `npm:`, `node:` and `jsr:` specifiers now. So you don't have to use the URL imports if you don't feel them.
    - sholladay 2y ago
      You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the module version into the URL so that the version can be stored separately, alongside the module name. Popular hosts with well-known URL structures could have their URLs automatically templated so you only have to specify the host and not the rest of the URL. In other words, the tooling could be better, but the fundamentals of URL imports are sound, IMO.
      - zzo38computer 2y ago
        I disagree. It should not default to "https:// https://" (I think defaulting to local files would be better). Furthermore, I think that it should be made so that the "hashed:" scheme that I had invented (in the Scorpion protocol/file-format specification document, although this scheme can be used independently of that) can also be usable. And, popular hosts with well-known URL structures automatically templating also I would disagree, although it might do to allow any expressions in place of the string literals and then add functions for abbreviations of some of those URLs, if that would help (although I still think it is unnecessary).
      - johnny22 2y ago
        yes, I would prefer to use a centralized registry indeed. However, that's not actually what i'm talking about here. Even just decoupling the import from the package is enough. You can already do this by by pointing a package in package.json to a remote tarball or git repo.
  - throwitaway1123 2y ago
    Node supports URL imports via the --experimental-network-imports command line option. There's also a built in test runner now.
- WuxiFingerHold 2y ago
  ... and obviously the only one you know. Kidding aside: You should really take an hour and check out the manual and std lib (https://jsr.io/@std https://jsr.io/@std). I was surprised how far Deno has come. A lot of pretty useful stuff you would otherwise need tons of NPM modules for.
yamumsahoe 2y ago
btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx. https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx
- jessym 2y ago
  I second this. The tsx library is zero config and always "just works" in my experience, which puts it miles ahead of ts-node, imo.
- iansinnott 2y ago
  Seconded again. While tsx usually just works ts-node almost never just works. tsx is perhaps unfortunately named though so it may confuse people at first since it has nothing to do with jsx syntax.
  - jimvdv 2y ago
    Thank you for bringing this up, I almost ignored this project since I assumed it had something to do with TypeScript + JSX. The JS ecosystem sure struggles with naming things.
    - tommica 2y ago
      The _programming_ ecosystem sure struggles with naming things.
      - jimvdv 2y ago
        Fair enough
    - nikeee 2y ago
      I own the npm package node-ts, which has thousands of installs per week just because people confuse it with ts-node. I didn't intend to typo-squat. Actually, my package is older than ts-node and was just a pun because it is an API for TeamSpeak written in TypeScript.
medv 2y ago
Have you tried https://github.com/google/zx https://github.com/google/zx?
- tnzk 2y ago
  This seems very interesting approach to scripting. Does it basically provides with an alias to child_process.exec as $ and besides that I can write in the same way I'd do in Node? > Node.js standard library requires additional hassle before using I read the hassle as having to setup Node runtime in advance, but zx requires npm to install so I'm not sure.

yamumsahoe 2y ago

correction: the only deno future that i want

sholladay 2y ago
Deno has so many other great features. Most web standard APIs are available in Deno, for example. It can do URL imports. It has a built in linter, formatter, and test framework. Built in documentation generator. A much better built in web server. Node is copying many of these features to varying degrees of success. But Deno is evolving, too.
- johnny22 2y ago
  the url imports is one the things I don't want.
  - niklasmtj 2y ago
    There are also the `npm:`, `node:` and `jsr:` specifiers now. So you don't have to use the URL imports if you don't feel them.
  - sholladay 2y ago
    You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the module version into the URL so that the version can be stored separately, alongside the module name. Popular hosts with well-known URL structures could have their URLs automatically templated so you only have to specify the host and not the rest of the URL. In other words, the tooling could be better, but the fundamentals of URL imports are sound, IMO.
    - zzo38computer 2y ago
      I disagree. It should not default to "https:// https://" (I think defaulting to local files would be better). Furthermore, I think that it should be made so that the "hashed:" scheme that I had invented (in the Scorpion protocol/file-format specification document, although this scheme can be used independently of that) can also be usable. And, popular hosts with well-known URL structures automatically templating also I would disagree, although it might do to allow any expressions in place of the string literals and then add functions for abbreviations of some of those URLs, if that would help (although I still think it is unnecessary).
    - johnny22 2y ago
      yes, I would prefer to use a centralized registry indeed. However, that's not actually what i'm talking about here. Even just decoupling the import from the package is enough. You can already do this by by pointing a package in package.json to a remote tarball or git repo.
- throwitaway1123 2y ago
  Node supports URL imports via the --experimental-network-imports command line option. There's also a built in test runner now.
WuxiFingerHold 2y ago
... and obviously the only one you know. Kidding aside: You should really take an hour and check out the manual and std lib (https://jsr.io/@std https://jsr.io/@std). I was surprised how far Deno has come. A lot of pretty useful stuff you would otherwise need tons of NPM modules for.

yamumsahoe 2y ago

btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx. https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx

jessym 2y ago
I second this. The tsx library is zero config and always "just works" in my experience, which puts it miles ahead of ts-node, imo.
iansinnott 2y ago
Seconded again. While tsx usually just works ts-node almost never just works. tsx is perhaps unfortunately named though so it may confuse people at first since it has nothing to do with jsx syntax.
- jimvdv 2y ago
  Thank you for bringing this up, I almost ignored this project since I assumed it had something to do with TypeScript + JSX. The JS ecosystem sure struggles with naming things.
  - tommica 2y ago
    The _programming_ ecosystem sure struggles with naming things.
    - jimvdv 2y ago
      Fair enough
  - nikeee 2y ago
    I own the npm package node-ts, which has thousands of installs per week just because people confuse it with ts-node. I didn't intend to typo-squat. Actually, my package is older than ts-node and was just a pun because it is an API for TeamSpeak written in TypeScript.

medv 2y ago

Have you tried https://github.com/google/zx https://github.com/google/zx?

tnzk 2y ago
This seems very interesting approach to scripting. Does it basically provides with an alias to child_process.exec as $ and besides that I can write in the same way I'd do in Node? > Node.js standard library requires additional hassle before using I read the hassle as having to setup Node runtime in advance, but zx requires npm to install so I'm not sure.