Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

501–510 of 570 posts

Re: Node.js adds experimental support for TypeScript

#501

Post by tossandthrow »

jokethrowaway wrote: post #458
oblio wrote: post #219

Earlier quoted context omitted.

Isn't Bun too raw? It's built with Zig, which hasn't even hit 1.0.

You still get segmentation faults. My biggest complain with bun is not having enough safety. If you use frameworks written for node memory usage is very high and performance is meh. If you use frameworks written for bun they smoke anything on node. I'd definitely move over, just to get rid of the whole TypeScript / cjs / esm crap, but: 1. frontend support is poor (next.js / solid.js - I can't run anything fully on bu…

We use Bun in production for the entire stack and has done since v1 - only with minor hikups, that all trvivially has been fixed.

DX is great!

We use vite react ts, yoga, and prisma.

Re: Node.js adds experimental support for TypeScript

#502

Post by joseferben »

WorldMaker wrote: post #392
nfriedly wrote: post #380

Earlier quoted context omitted.

For the old libraries I maintain that are typescript and transpiled into .cjs and .mjs for npm, I'll probably just start shipping all three versions. For a new thing I was writing from scratch, yeah, I might just ship typescript and not bother transpiling. [edit: Apparently not. TS is only for top-level things, not libraries in node_modules according to the sibling comment from satanacchio who I believe is the author…

Why are you still transpiling to .cjs in 2024? ESM is supported in every LTS version of Node now. We can kill CJS, we have the power.

i wish it was that easy. i keep trying to default to esm on node projects but the ecosystem is not there yet, at least in the context of server side nodejs stuff.

Re: Node.js adds experimental support for TypeScript

#503

Post by schwartzworld »

pansa2 wrote: post #34

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them. It's interesting, though, that this approach in Python has led to several (4?) different popular…

Incidentally, this is how the ecmascript proposal for introducing types to JS would work by default. The runtime would ignore the types when running code. If you want type checking, you’d have to reach for external tooling.

Re: Node.js adds experimental support for TypeScript

#504

Post by joseferben »

hajile wrote: post #322
BiteCode_dev wrote: post #212

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them. This mean you can define simple types, and get: - type checking - run time data check - api generation - api document generation Out of a single, standard notation. Right now in JS, things like zod have to d…

If JS ever adds type checking, I hope it doesn't choose Typescript. We need a type system that is actually sound and TS is intentionally unsound. We need a type system that doesn't allow bad coding practices like TS does. We need a type system that enforces program design that allows programs to be fast. We need a Hindley Milner type system. If you want a module to be typed, add a `"use type"`. This should disallow b…

having written ocaml in production for a few years, i think soundness comes at a cost of dev ergonomics. at least with the type systems of today’s industry languages.

it blows my mind weekly how ergonomic and flexible typescript’s type system is. it allows me to write great apis for my team mates.

is it possible for the type checker to end up in an infinite loop or for a junior developer to abuse “as”? absolutely, but it doesn’t really matter in practice.

i wouldn’t want to run typescript in rockets or submarines tho!

Re: Node.js adds experimental support for TypeScript

#505

Post by thanksgiving »

Timon3 wrote: post #468
WorldMaker wrote: post #449

Earlier quoted context omitted.

Most parsers don't actually work with "lines" as a unit, those are for user-formatting. Generally the sort of building blocks you are looking for are more along the lines of "until end of expression" or "until end of statement". What defines an "expression" or a "statement" can be very complex depending on the parser and the language you are trying to parse. In JS, because it is a fun example, "end of statement" is d…

Thanks for the response, but I'm aware of the basics. My question is pointed towards making language parsers resilient towards separately-evolving standards. How would you build a JS parser so that it correctly parses any new TS syntax, without changing behavior of valid code? The example snippet I added is designed to violate the rules I could come up with. I'd specifically like to know: what are better rules to sol…

> How would you build a JS parser so that it correctly parses any new TS syntax, without changing behavior of valid code?

I don't know anything about parsers besides what I learned from that one semester worth of introduction class I took in college but from what I understand of your question, I think the answer is you can't simply because we can't look into the future.

Re: Node.js adds experimental support for TypeScript

#506

Post by afiori »

price wrote: post #497
afiori wrote: post #495

Earlier quoted context omitted.

any and unknown are perfectly sound, if they were the only types then soundness would be automatic. The problem is that you can arbitrarily narrow types (and any can narrow to any type) eg: https://www.typescriptlang.org/play/?#code/DYUwLgBAzg9grgOwC...

That's true but misleading: if "any" and "unknown" were the only types, then "any" would be indistinguishable from "unknown" and you'd really have just the one type. Which makes the type system sound because it doesn't say anything. If your type system has at least two types that aren't the same as each other, then adding "any" makes it unsound right there. The essence of "any" is that it lets you take a value of one…

a typing of any cannot be unsound because it is always correct, narrowing any can be unsound.

Re: Node.js adds experimental support for TypeScript

#507

Post by haskman »

lolinder wrote: post #440
nyssos wrote: post #404

Earlier quoted context omitted.

> Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application? Sure. The usual Java-style variance nonsense is probably the most common source, but I see you're not bothered by that, so the next worst thing is likely object spreading. Here's an anonymized version of something that cropped up in code review earlier this week: const incomingValue: { name:…

I mean... yes, there's a footgun there where you have to know to spread first and then add the new properties. That's just a good practice in the general case: an intermediate type that fully described the data wouldn't have saved you from overwriting it unless you actually looked closely at the type signature. And yes, TypeScript types are "at least these properties" and not "exactly these properties". That is by de…

Look into "Row types" and how PureScript, Haskell, and Elm (to a limited extent) do it.

'{foo :: Int | bar} is a record with a known property 'foo' and some unspecified properties 'bar'. You cannot pass a `{foo :: Int, bar :: Int}` into a function that expects `{foo :: Int}`.

A function that accepts any record with a field foo, changes foo, keeping other properties intact has the type

    {foo :: Int | bar} -> {foo :: Int | bar}

Re: Node.js adds experimental support for TypeScript

#508

Post by wiseowise »

sgammon wrote: post #171
quonn wrote: post #159

Earlier quoted context omitted.

Kotlin is much closer to Java than to TypeScript even in terms of flexibility.

Sure, but Kotlin is to Java as TypeScript is to JavaScript, which is the point I am making.

That’s not even remotely true.

TypeScript is a direct superset of JavaScript. Any valid JS is a valid TypeScript.

If Kotlin is what TS to JS, then so is Groovy, Scala, Clojure and other JVM languages.

Re: Node.js adds experimental support for TypeScript

#509

Post by butwhynotTSR »

pshc wrote: post #420
parasense wrote: post #401

Earlier quoted context omitted.

Paired characters... That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes...…

So many different pairs are available. I like Asian corner brackets 「」and French guillemets « ». The angle brackets 〈〉 are popular in CS/math papers I think, though they might be confused with .

I have had access to « » before, which led me to doing a double take when I first encountered a Which brings us to the philosophical question about paired characters: If we were to pick paired characters from a key set not available on everyone's keyboard, why must the paired characters even be used in real languages? Is that not actually actively detrimental when we end up needing the characters for real? Is this not why we even have escape characters to begin with?

Plus, must they be a part of anyone's real keyboard to begin with? What makes 「」any more valid than ¿? Could we not have saved ourselves a lot of mental strain if we solved it earlier on with a full set of truly uncommon characters?

I can imagine an alternate history, where some programming language in the late 70's made their editors with simple shortcuts (such as Ctrl+A for "array block") to input barely-if-ever-used yet low code character such as † or ‡, which would never be used outside of a string. And nowadays, with modern IDE's, we wouldn't even see those characters half the time. It would be syntax sugar, with blocks types stated in gutters and data types represented with colors or text.

Re: Node.js adds experimental support for TypeScript

#510

Post by pas »

apatheticonion wrote: post #488

I wonder how this handles import resolution. type: module requires file extensions and does not support importing folders like most people are used to so it will not be compatible with most existing Typescript code. Will it transform esm import syntax into require statements? I'd prefer it break existing code to enforce correctness

There's a "dedicated thread" on the question here https://github.com/nodejs/loaders/issues/214

There are about 100 messages in the comments on the linked PR all about the import extensions compatibility/consequences :)

There's a "roadmap doc" here https://github.com/nodejs/loaders/issues/217 that states "No .js extension for .ts files."

> I'd prefer it break existing code to enforce correctness

That seems to be the goal and intent (from TS and Node team too https://github.com/nodejs/node/pull/53725#issuecomment-22301... )

> Will it transform esm import syntax into require statements?

IIUC no

see the docs about which module system Node picks for the loaded files https://github.com/nodejs/node/blob/main/doc/api/typescript.... ("Node.js will not convert from one module system to another")

Post reply on HN