Nice to see this, and important to stay closer to parity with Deno and Bun.
Node.js adds experimental support for TypeScript
341–350 of 570 posts
Re: Node.js adds experimental support for TypeScript
#342One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…
The syntax from the perspective of type stripping has been relatively stable for more versions of Typescript than it was unstable. You had to reach all the way back to 1.5 in part because it's been very stable since about 2.x. The last major shift in syntax was probably Conditional Types in 2.8 adding the ternary if operator in type positions. (The type model if you were to try to typecheck rather than just type-strip has changed a lot since 2.x, but syntax has been generally stable. That's where most of Typescript's innovation has been in the type model/type inferencing rather than in syntax.)
It's still just (early in the process) Stage 1, but the majority of Typescript's type syntax, for the purposes of type stripping (not type checking), is attempting to be somewhat standardized: https://github.com/tc39/proposal-type-annotations
Re: Node.js adds experimental support for TypeScript
#343Earlier quoted context omitted.
The proposal would explicitly treat supported type annotation syntax as comments in the grammar . It is definitely types as comments, even if it is also type erasure. And it would apply to Flow’s type annotation syntax which is also not presently treated as comments, at least for the very large subset of that syntax which overlaps with the proposal.
I meant https://flow.org/en/docs/types/comments/
I know what you meant.
Re: Node.js adds experimental support for TypeScript
#344Earlier quoted context omitted.
Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code)…
Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[f…
of course this created an interoperability nightmare with third party libraries, which irrevocably forked Google's whole JS ecosystem from the community's 20 years ago and turned their codebases into a miserable backwater.
Re: Node.js adds experimental support for TypeScript
#345Side note, but IMO Typescript is too complicated. They should have stuck to a reasonably simple type system but now I see projects with incomprehensible and frankly unmaintainable typescript consisting of extremely complex generics, type conditionals, and type constraints. Basically if you aren't careful you'll find your project metaprogramming in typescript's turing complete meta language...
This is something I've struggled with as a mostly solo dev. I've most often just stuck with vanilla javascript because of course that's good enough, but definitely there have been times where I hoped I had some typing helping me out. Alas, I haven't quite finagled the art of finding a way to use it "just a little bit."
Re: Node.js adds experimental support for TypeScript
#346Earlier quoted context omitted.
> Its better to have no types at all than wrong types. I agree - but the type systems of both Python and TypeScript are unsound, so all type hints can potentially be wrong. That's one reason why I still mostly use untyped Python - I don't think it's worth the effort of writing type annotations if they're just going to sit there and tell lies. Or maybe the unsoundness is just a theoretical issue - are incorrect type h…
Is this “unsound”-ness that you’re referring to because it uses structural typing and not nominal typing? Fwiw I’ve been working with TypeScript for 8+ years now and I’m pretty sure wrong type hints has never been a problem. TS is a God-send for working with a codebase.
No, TypeScript is not unsound because it uses structural typing.
A language has a sound type system if every well-typed program behaves as defined by the language's semantics during execution.
Go is structurally typed, and yet it is sound: code that successfully type checks is guaranteed to abide the semantics of the language.
TypeScript is unsound because code that type checks does not necessarily abide the semantics of the language:
function messUpTheArray(arr: Array): void {
arr.push(3);
}
const strings: Array = ['foo', 'bar'];
messUpTheArray(strings);
const s: string = strings[2];
console.log(s.toLowerCase())
`s` is declared as `string`, but TypeScript is happy to assign a `number` to it. This is a contradiction, and an example of unsoundness.
This code eventually fails at runtime when we try to call `s.toLowerCase()`, as `number` has no such function.
What we're seeing here is that TypeScript will readily accept programs which violate its own rules. Any language that does this, whether nominally typed or structurally typed, is unsound.
Re: Node.js adds experimental support for TypeScript
#347Earlier quoted context omitted.
What do you mean by unsound exactly. I'm asking because there's no accepted definition of what an unsound type system is. What I often see is that the word unsound is used to mean that a type system can accept types different to what has been declared, and in that case there's nothing unsound about ts since it won't allow you to do so.
That’s not correct, there’s several ways the actual type of a value differs from what typescript thinks it is. But soundness isn’t a goal of typescript.
It's maybe useful to note in this discussion for some that "soundness" of a type system is a bit of technical/theoretical jargon that in some cases has specific mathematical definitions and so "unsound" often sounds harsher (connotatively) than it means. The vast majority of type systems are "unsound" for very pragmatic reasons. Developers don't often care to work in a "sound" type systems. Some of the "most sound" type systems we've collectively managed to build are in things like theorem provers and type assertion systems that some of us don't always even consider useful for "real" software development.
Typescript is a bit more unsound than most because of the escape hatch `any` and because of the (intentional) disconnect between compiler and runtime environment. Even though "unsound" sounds like a bad thing to be, it's a big part of why Typescript is so successful.
Re: Node.js adds experimental support for TypeScript
#348I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java. I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem. And surprising…
Gradual typing is the key. The problem with Java is that types are in your face way before you actually need them.
With TS you can prototype with JS and only after you know what you are looking for you can start to add types to find bugs and edge cases and want to get nice code completions for your stuff.
Re: Node.js adds experimental support for TypeScript
#349Earlier quoted context omitted.
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.
the url imports is one the things I don't want.
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:// 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.
Re: Node.js adds experimental support for TypeScript
#350I beg of thee, do not do this. I get that people love typescript but I am already running into a problem where javascript resources are written in typescript by default with nothing for regular javascript. This is the same problem that happened when JQuery hit its peak popularity and an overwhelming amount of resources and guides amounted to "Oh just do this in JQuery"
[deleted]