25 ms·

Node.js adds experimental support for TypeScript

• satanacchio 2y ago
  Hi I'm the author of the PR, AMA
  • mostafah 2y ago
    Thank you a lot. Great work. I know it’s still experimental, but over time it will have a big impact on developer experience and will simplify the development workflow for a lot of projects.
  • Shacklz 2y ago
    Great work, many thanks! Out of curiosity, what do you see as next steps, and what possible futures do you see for typescript in the node- and overall JS-ecosystem?
    • satanacchio 2y ago
      this is the roadmap https://github.com/nodejs/loaders/issues/217 https://github.com/nodejs/loaders/issues/217. We talked with the typescript team and we will give each other continous feedback on the progression. We made sure to take some precautions in order to avoid breaking the ecosystem. I still think in production, js is the way to go, so users should always transpile their ts files.
      • nilsbunger 2y ago
        Could you expand on why transpiling is the right long-term strategy for production? I get that right now you don't support some TS-specific features like enums. Is that the concern? Those seem like a few legacy exceptions, new TS capabilities will be "just javascript". Not transpiling would be great to reduce toolchain complexity and eliminate the need for sourcemaps just to understand exceptions and debug.
        • satanacchio 2y ago
          The first reason is because if we supported ts features that require transformation (such as enume) we would also need to support sourcemaps, so in the first iteration I decided not to, to avoid being overwhelmed. Right now we replace inline types with whitespace, so locations are preserved. We plan to add those features, probably behind a flag at the beginning. We need to move in small steps and think very carefully, every decision could make a huge impact on the ecosystem so I decided to start with the smalled subset possible.
          • nilsbunger 2y ago
            That all makes sense, it sounds like you haven’t ruled out supporting TS directly in production, but it’s complex and you have to move carefully and you’re not sure if you’ll get all the way there. Is that right ?
• vithalreddy 2y ago
  Simply amazing! I wonder bun and deno support for typescript played a big role here :)
  • yamumsahoe 2y ago
    i do wish nodejs adopts uwebsockets (totally what makes bun fast)
    • WuxiFingerHold 2y ago
      Yes, many aren't aware of that. If nodes webserver performance is not enough, you could always use uwebsocktsjs or hyperexpress with node.
  • matrixhelix 2y ago
    This is why competition is important
• me_vinayakakv 2y ago
  Nice to see Node.js getting parity on this with Deno and Bun
  • Klaster_1 2y ago
    This reminds me of io.js situation, where in the end major fork changes were incorporated into Node. This is why I am comfortable staying with Node and npm for my projects - the features will eventually trickle down anyway.
    • ibash 2y ago
      But in the meantime you suffer for it. How many days have you spent on webpack config? Or the package.json type property? Or yarn/pnpm/etc particulars? I have spent too many. Bun is quite nice.
      • Klaster_1 2y ago
        Very true, rising popularity of deno and bun clearly indicate that new runtimes solve real issues people have. That's why I mentioned "my projects", your experience may vary.
      • crabmusket 2y ago
        Is Bun's bundler on par with webpack for features? You can't escape webpack* if you're targeting frontend. *Or vite, or whatever equivalent.
        • iainmerrick 2y ago
          Using vite is escaping webpack!
    • devjab 2y ago
      This is the “enterprise” approach and it’s a solid one in my book. I do think drop-ins like Bun and PNPM are always great, however, and we’ve adopted both where it has made sense. I don’t think Bun will make sense very often as it’s only when you really need the performance the added maintenance becomes worth it. Especially right now where it’s not exactly stable for a lot of things. PNPM however is often very great compared to NPM and doesn’t add much maintenance as the tooling essentially gives your developers a very similar experience. I’m also not sure the features will eventually “tickle down”. I’m not sure NPM wants to adopt the advantages PNPM gives you as an example, and it’s probably a good thing too considering the basis of NPM is just a really solid system to build on top of which it wouldn’t be if it was very opinionated. One of the big issues Node has today is that it was very opinionated with CommonJS, which made sense at the time, but is a ginormous pain in the butt in the modern world. Though the blame is obviously not with Node alone.
• rockwotj 2y ago
  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.
• deanc 2y ago
  So how does this work in practice? Does it strip types and yolo trying to run or will it spit out type errors?
  • TheRealPomax 2y ago
    Why would you describe that "yolo"? If you're writing TS, you already have a TS linter that checks whether code has typing problems or not (at least, I certainly hope you do?). It's not really Node's job to do that linting, its job is to execute the JS that's hiding in the TS. It'd be "handy" if it did, but it'd also be a bit weird when there are already TS linting tools. It'd just hold up landing any sort of TS support that much longer.
  • bentruyman 2y ago
    If you read the third sentence of the PR, it says: > During the transpilation process, no type checking is performed, and types are discarded
  • Shacklz 2y ago
    If I understood correctly they use a wrapper around swc to strip types, without any type-check being performed. Which makes perfect sense to start out with; as typechecking with tsc is rather slow and can easily be delegated to the consumer.
• ofirg 2y ago
  support for typescript as long as you are only using it for type checking, not if you are also using features that are not supported in the javascript version you are targeting.
  • paulddraper 2y ago
    That is what people use TypeScript for generally. If you need JS syntax features that Node.js doesn't support you can use tsc, babel, etc. Because obviously unsupported features are unsupported, whether JS or TS.
  • flohofwoe 2y ago
    > not if you are also using features that are not supported in the javascript version you are targeting. reply This is only 'half-assed' anyway, TS will only emulate new language features on older JS target version, but not any Javascript runtime features (like new Object methods). For the latter you will still need a separate polyfill solution.
• samtheprogram 2y ago
  Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit, I can’t imagine the user experience (or performance) to match Bun’s when it reaches stable.
  • spankalee 2y ago
    Extensions should be required. It's not possible to do path searches over the network like you can on local disk, and network-attached VMs, like browsers, are a very, very important runtime for JavaScript.
    • samtheprogram 2y ago
      That makes sense. I guess since using .js for the relevant imports just works in TypeScript I should be happy then…
    • leipert 2y ago
      Also performance. foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import.
      • simlevesque 2y ago
        > foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Only in the worst case. If it's foo.js there's only one lookup. > Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import. Again, you're only taking into account the worst case.
    • pfg_ 2y ago
      Fortunately, code is generally bundled for browsers to reduce the number of network requests and total size of downloads. And node has access to the filesystem, so it can do path searches just fine if it wants to support existing code.
• spankalee 2y ago
  It's about time for TC39 and Microsoft to standardize TypeScript as part of JavaScript. Not "types as comments" either, but actually TypeScript, minus the non-standard runtime semantics and modulo whatever changes are necessary to integrate the grammar. So many runtimes and tools are integrating TypeScript now, and with multiple implementations, that a real standard is necessary. It'll be much harder to evolve TypeScript because it'll have to stay backwards compatible, but it's grown to that point now, imo.
  • vivzkestrel 2y ago
    its about time google chrome started making a typescript engine maybe? and get rid of JS in phases?
    • jjk7 2y ago
      There are a few optimizations that types can use but 99% of applications wouldn't benefit from them anyways.
      • Shacklz 2y ago
        Taking one link out of the toolchain (tsc) would already be a huge blessing. And naive me hopes for a future where in my web-app I can set a policy that any non-ts, type-incompliant code is not allowed to run. The amount of exceptions I get in the console from terrible garbage-code outside of my control but that I have to include because enterprise is staggering. Would love to have a meta-setting which would just kill them if they can't be arsed to even have a modicum of code-hygiene (sorry for the rant)
        • _flux 2y ago
          Why is taking out the part that actually checks the types at the developer's side a huge blessing? Or if you are hoping to get the benefit of type checking in the browser itself (taking the same sweet time as tsc, but this time on every browser instead of once in the CI), then how long would you want to wait to be able to actually use the new typing functionality described in e.g. the latest TS annoucement? https://devblogs.microsoft.com/typescript/announcing-typescript-5-5/ https://devblogs.microsoft.com/typescript/announcing-typescr... . Because it would take a while until that would then become the standard and then become available in every browser. And you still need to provide the JS versions, because not every browser is going to support TS. In the meanwhile you could just keep using tsc just as before and get access to new functionality immediately. (I imagine you could run tsc in the browser right now if you really wanted to.)
• throwitaway1123 2y ago
  It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.
  • crabmusket 2y ago
    The recently-added test runner is very cool too!
    • SwiftyBug 2y ago
      YES. It was such a joy to be able to ditch Jest completely and run tests natively.
      • joseferben 2y ago
        i tried that but had to revert to vitest, the native test runner feels incomplete atm.
        • crabmusket 2y ago
          What is missing for your use case or workflow?
          • sureIy 2y ago
            Probably a bunch of assertion types and general DX. Node:test is just a feature, Vitest is a whole product. The former might be enough for small packages but nowhere near useful for anything non-trivial.
            • crabmusket 2y ago
              Fair enough. We still use Jest at work for exactly those reasons. In my personal projects, I prefer to minimise dependencies rather than get every DX benefit I can.
          • 2y ago
• just-tom 2y ago
  Nice, but without support for Enums, for me it's mostly useless.
  • Shacklz 2y ago
    In our codebase we started to disallow enums in favour of string literal types, and once folks get over the ingrained "this needs to be an enum" (coming mostly from other languages like Java), it's not much missed. Enums are one of the very few things in typescript that seem to not have turned out that well, but it's relatively easy to work without them with string-literable types and such, derived from some const in case they're also needed at runtime.
    • shepherdjerred 2y ago
      100% agree. Coming from Java I really wanted an Enum type, but string literals/discriminated unions fill that niche just fine.
    • bythreads 2y ago
      agree enums in typescript are the devil
      • revskill 2y ago
        Could u explain why ?
  • deleted 2y ago
    [deleted]
  • azangru 2y ago
    There are union types for strings; and there are plain javascript objects (typed as const) if "namespace.name" syntax is desired. With these available, what is the point of enums?
    • silverwind 2y ago
      Namespaces are also not supported as per https://github.com/nodejs/node/blob/main/doc/api/typescript.md#unsupported-typescript-features https://github.com/nodejs/node/blob/main/doc/api/typescript..... I for one can can live without all these features and will be banning via eslint.
• Shacklz 2y ago
  I'm honestly giddy. This could be the (slow) beginning of a new era, where "JS with types" is finally a native thing. I'm even willing to forgive all the mess that CJS vs. ESM is if they manage to pull this off. I hope this sees widespread adoption/usage, which might finally cause some movement to integrate TS into ecmascript after all. Some dynamically-typed language fanatics (which are, in my opinion, completely detached from the reality that static types are what the vast majority of devs want) still have an iron grip on TC39, this might be the start of their end. And good riddance.
  • yashap 2y ago
    Yeah, my personal experience is that easily 95% of devs I work with/have met in person, if not closer to 99%, prefer statically typed languages. Maybe that’s a biased sample, but I do think the overall preference among devs is very strong. I also see JS slowly, more-or-less becoming TypeScript over time.
    • tstrimple 2y ago
      My days of being a real software developer are long behind me. So I'm totally willing to accept that I'm wrong here. But when I build a POC in particular, there's a LOT of power and flexibility granted by not giving a fuck about types. Suddenly I can accept non well defined data types (depending on my implementation) and can persist data that otherwise would have taken code changes and approval processes to accept. I do believe there is a place for types, but to type all the things is folly. There are capabilities within JavaScript to handle both.
      • iamsaitam 2y ago
        The malicious beauty of typescript is that at any point you can just declare something "any" and voilá, the guard rails are off.
        • leshenka 2y ago
          It’s fine to have an escape hatch when you can’t figure/don't care about types (yes sometimes you should use unknown but that’s another topic) But at least TS forces (if enabled by strict flag) you to explicitly mark all those places. You can always revisit them later. Case in point: I’ve written A LOT of redux-saga code and figuring out types for that was exceptionally difficult for me. Sprinkled all that with a ton of anys. Had a few bugs but not anything serious. Finally rewriting all that slop with async-await and am really happy about it
• pansa2 2y ago
  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 type checkers, which AFAIK all use the same type hint syntax but apply different semantics. However for JavaScript, TypeScript seems to have become the one-and-only popular type checker. In Python, I've even heard of people writing types in source code but never checking them, essentially using type hints as a more convenient syntax for comments. Support for ignoring types in Node.js would make that approach possible in JavaScript as well.
  • winter_blue 2y ago
    Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.
    • mattnewton 2y ago
      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).
      • LoganDark 2y ago
        Oh, Closure Compiler is such a throwback. I still remember staring at the project page on Google Code. Isn't it like two decades old or even older by this point? Is it still alive?
        • mdhb 2y ago
          The compiler itself lives on but it works with TypeScript now rather than the JSDoc comments style approach which is officially EOL AFAIK.
• commercialnix 2y ago
  https://rescript-lang.org/ https://rescript-lang.org/
  • garbagepatch 2y ago
    Looks very similar to Reason ML, another language that compiles to Js: https://reasonml.github.io/docs/en/getting-started https://reasonml.github.io/docs/en/getting-started
    • hajile 2y ago
      ReScript was an outgrowth of ReasonML and basically split the community killing both of them.
      • mardifoufs 2y ago
        What was the reason behind the split?
      • commercialnix 2y ago
        I was not aware of this. I did see ReScript covertly bring some sanity to some NodeJS projects, and more than once. So this history of the project is worth digging into. Thank you for surfacing this insight.
• skybrian 2y ago
  It would be nice for debugging if at least simple npms could just bundle their .ts files without any processing, so we could see the comments and types as they existed in the git repo. Apps can always minify them later. (I use Deno, but also use some npms.)
  • flohofwoe 2y ago
    You can simply create npm packages which contain only the 'unprocessed' TS source files (or really any type of files - for instance I experimented with using npm as package for C/C++ projects in the past, it works just fine). Pre-bundling or compiling from TS to JS is just a convention. And in case of bundling not a good one IMHO, because bundling should only be a final step in the top-level project. One good reason to compile the package content to .js/.d.js/.map files is that the resulting package is usable both in JS and TS projects.
    • skybrian 2y ago
      The nice thing about this change to Node.js (when it’s no longer experimental) is that you could just distribute .ts files and JS projects could use them.
      • deleted 2y ago
        [deleted]
• storafrid 2y ago
  I have mixed feelings about this. While I do use TS with Node.js today and absolutely like the concept, its type system is still far from something mature and stable like C#. We keep running into ceilings (EDIT: lack of completeness/depth, not lack of complexity) all the time, and TypeScript questions on Stack Overflow is basically a library of workarounds. Mostly bad ones. So if I worked on Node.js I would prefer it to evolve more before actually marrying and having kids with it. But at the same time, I like the direction Node.js is taking.
  • Zamicol 2y ago
    Well said. Bearing that in mind, we've found that JSDoc is a reasonable substitution for some TypeScript applications; however, JSDoc has limitations that we've ran into frequently as well.
  • coffeemug 2y ago
    What's an example of a ceiling? Out of all the mass-market programming languages, TS arguably has the most advanced type system in the world. It's a modern marvel that they got it working on top of Javascript.
    • mdhb 2y ago
      I don’t know what you mean here by advanced? If you mean the sheer amount of fuckery they have to do in order to make it work with JS perhaps you have a point. If you mean expressiveness or consistent or soundness then no, it’s actually very bad compared to almost anything else and I think the longer it goes on the more it starts to feel like a house of cards. The upside I guess is that whenever Safari decides to get their shit together Web Assembly is well placed to get us out of the scenario where we are forced to use JS and as an extension Typescript at all for most things and actually good language choices with reliable type systems like Dart, Kotlin and C# all become viable options. There is no way I’d choose JavaScript over those other options in the majority of scenarios unless I was forced to.
      • wiseowise 2y ago
• rglover 2y ago
  Didn't expect types to come to JavaScript like this (native or without a separate compiler), but I love the idea.
• CodeCompost 2y ago
  Ok that's cool, but how about adding native support to browsers?
  • dimava 2y ago
    Stage 1 https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations So maybe we'll have support in another five years ... Or maybe we'll have "Support in another five years" in five years, who knows
• harshitaneja 2y ago
  I 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 surprisingly even though rust is on a different end of the language spectrum but yet it offers a similar feel. Edit: JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.
  • dagenix 2y ago
    Java does jit
    • harshitaneja 2y ago
      Yes, JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.
      • sgammon 2y ago
        Native Java via GraalVM starts up in milliseconds.
        • wiseowise 2y ago
          And it has to go through slow compilation step. With Node you can have a cake and eat it too.
          • sgammon 2y ago
            It does not "have" to go through such a step, by the way, because you can simply run such code on the JVM.
• throw156754228 2y ago
  I see it just strips the typings. So if I attach the debugger I'm still going to see javascript right?
  • zarzavat 2y ago
    Presumably it would also generate a source map to allow debuggers to work properly, like tsc does.
    • throw156754228 2y ago
      What is 'it' here in your sentence above?
• zarzavat 2y ago
  One 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 < bar & baz > ( x )`. In TypeScript 1.5 this parsed as (foo<bar) & (baz > (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo<(bar & baz)>(x) which desugared to foo(x). I realise I’m going back in time here but it’s a nice simple example. If you want to continue to use new TypeScript features you are going to need to keep compiling to JS, or else keep your node version up to date. For people who like to stick on node LTS releases this may be an unacceptable compromise.
  • spoiler 2y ago
    It's possible that internal SWC version will be versioned alongside Node, meaning TS syntax support won't drift. Or am I missing something?
    • thecopy 2y ago
      TypeScript evolves independent of Node, and the syntax you can use depends on your `typescript` version in the `package.json`
      • re-thc 2y ago
        Not if SWC or your tooling doesn't support it.
    • satanacchio 2y ago
      yes but can also be upgraded separately as npm package
  • the_gipsy 2y ago
    You would also have to update your compiler. I guess you could phrase this as: you can't update your TS versions independently from your node.js version. But that's probably not an issue.
• sgammon 2y ago
  Really glad to see this
• alabhyajindal 2y ago
  What next? Renaming Node.js to Node.ts? I understand that built in TS support is very nice as provided by Bun. But I feel doing this in Node is going to take a long time.
• gaptoothclan 2y ago
  A long time ago I started converted to using node js for backend work, seemed to offer many benefits over writing code in PHP without bringing many problems of Java. I found node to be somewhat clunky and a language where you had to bolt it together to get the language you wanted. Eventually started writing golang and it felt much easier to write, sometimes way more verbose but the type safety just made coding simpler. Typescript seemed like a good option but was just another bolt on, I am not sure what value you gain by using Typescript over Golang, you have nice defined types which is great but it does not solve other issues with the language that are resolved in golang (also solved in deno). One large benefit of using node over golang is the speed of prototyping something which I think having to use type script largely negates, so I can not really decide if this is a good step forwards or is making node loose some qualities that made it a good choice in other ways.
  • _joel 2y ago
    I guess if you already know Javascript, or have inhouse experience vs. learning Go. We use it with cdktf as previous fe experience, seemed logical vs. Go
    • gaptoothclan 2y ago
      sorry was going to add that there are probably more javascript developers in the jobs market, although there is a limit to the usefulness of these developers. In the company I worked at we were fairly small and did not have huge applications running on node, so it made that journey easier
  • __alias 2y ago
    I mean the obvious answer is language familiarity, If your projects frontend code is in javascript/typescript ( which it is ), then using node is an easy choice. Shared libraries, shared types, etc etc
    • fulafel 2y ago
      Lots of people do of course use other languages for the frontend. (Or go for thin frontends, ala HTMX )
• BiteCode_dev 2y ago
  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 do: const mySchema = z.string(); Which is basically reinventing what typescript is already doing.
  • aitchnyu 2y ago
    Does this mean Node can know if an exception is subclass of ValueError or an object is instance of SomeClass? I'm a TS newb, I thought types outside of array, object, number, string arent present in JS and Zod and typeguard functions return plain objects with "trust me bro".
    • LelouBil 2y ago
      You are right, they aren't. In the JavaScript languages which is what gets actually executed, there are no typescript types. The parent commenter was talking about a way for nodejs to provide, via an API, the content of type annotations on fields/functions/variables like in python. However, in python the type annotations are a property of the object at run time, whereas they are completely stripped before execution for typescript. So I'm not sure how it would work except by changing the typescript philosophy of "not changing runtime execution"
    • gampleman 2y ago
      In JS, classes do retain runtime information. So the `instanceof` is a real runtime operator that works by checking the prototype chain of an object. So checking subclasses can be done at runtime. However, in TS other type information is erased at compile time. So if you write type Foo = "a" | "b"; the runtime code will see that just as a plain string.
  • bythreads 2y ago
    That's not entirely true. `z.string()` in Zod offers more than just type safety akin to TypeScript. TypeScript provides compile-time type checking, while Zod adds runtime validation and parsing. For those unfamiliar: `z.string()` effectively converts `mySchema` into a functional schema capable of parsing and validation. For example: `mySchema.parse("some data")` returns successfully. `mySchema.parse(321)` throws an exception. I've used it in places where you need runtime validation and in process verification - it works pretty well for that and you can extract the types from it via : const A = z.string(); type A = z.infer<typeof A>; // string Meaning if you define your types in zod first, and infer their types from that you get compile and runtime type checking. --- It a bit of an overkill for nimble and fast code bases though - but works wonders for situations where in process proofing needs to be done, and in all honesty it isn't that big of a task to do this.
• jvanveen 2y ago
  I just switched to Bun for typescript support, a free bundler and better performance. Iojs flashback all over :)
  • XCSme 2y ago
    Does Bun always work for you? For me, none of my projects worked to run "bun install" on.
• DrMiaow 2y ago
  Without some kind of transformation on `enum` isn't this mostly useless? `enum` is heavily used in many TypeScript code-bases.
• cryptica 2y ago
  It's interesting how TypeScript beat Flow in terms of popularity, and yet everyone is now calling for TypeScript to be more like Flow (to focus on plain type checking instead of transpilation; just strip out the type annotations)... And most of those people don't even know about the existence of Flow. The sad thing about the tech sector is that you can be right about something and yet still lose the hype-wagon popularity contest. Then your competitor copies your original idea... The exact same idea which they had previously claimed was inferior. It seems that the idea was inferior purely on the basis that it wasn't their idea. As soon as they've appropriated the idea, suddenly it's the best idea in the world.
• zaphod420 2y ago
  I would rather raw dog JavaScript than write Typescript. Typescript is an abomination.
  • halfmatthalfcat 2y ago
    Thank god you’re in the minority with that opinion
    • deleted 2y ago
      [deleted]
• nthngy 2y ago
  IMAO writing (hard-coding) TypeScript is deprecated and a waste of time. With all tech available nowadays it is possible to do the entire type check automatically in the IDE, even more so now with the help of AI. It's just a matter of time when we stop hard-coding type info. Better invest time and money in getting the IDE's work better for us.
• zelphirkalt 2y ago
  If this means, that one day I don't need to use a bundler any longer to make a website using TypeScript, I am all for it.
  • ivanjermakov 2y ago
    For that browser needs to understand ts natively. Otherwise, transpilation has to be done: by tsc, bun, or by something else.
• umvi 2y ago
  Side 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...
  • ChicagoBoy11 2y ago
    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."
  • andrewmcwatters 2y ago
    TypeScript in its current usage reminds me of Hello, World! or FizzBuzz Enterprise Edition. There's almost more code dedicated to typing than the actual running software itself in some codebases I've seen. The authors trick you with reasonable examples on https://www.typescriptlang.org https://www.typescriptlang.org, but in the wild, you have these ridiculous codebases that couldn't control themselves and they have this insane ratio of multiple declaration files to actual source files and you have to ask yourself, "Are you writing software to get something actually done, or do you just like write type definitions?" Even people who write in C++ don't go to the lengths that TypeScript users do. It's super weird and cult-like.
    • umvi 2y ago
      To be clear, I do like the type-checking benefits of TypeScript, but it requires some discipline to keep it simple. Get one unchecked TS astronaut on the team and the TypeScript can get complex and esoteric very quickly.
    • sureIy 2y ago
      I also get lost in types sometimes, but the point of types is that they help you. Typescript lets you just use `as any` and `as unknown` as you please, but you want complex constraints you will need complex types. There are some type libraries that parse GraphQL queries and CSS selectors. They’re crazy to look at but they’re hugely helpful.
• jdeaton 2y ago
  Isn't the whole idea of TS that you just convert to JS to run it
  • WorldMaker 2y ago
    Yes. The question is where you do the conversion and how much of a conversion to do. This allows a key conversion (type stripping) directly at load time by Node rather than needing an extra step (an external type stripper such as Typescript or esbuild) sometime before passing the file to node for loading.
• 65n56nm5665m56 2y ago
  I 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 2y ago
    [deleted]
  • lolrsten349 2y ago
    Tell me you're out of touch without telling me that you're out of touch. jQuery was so popular because writing anymore than a few lines of vanilla JavaScript was an *awful* experience due to all differences in browsers. When things eventually standardized-ish and jQuery became unnecessary, other libraries/ecosystems popped up (e.g. React/JSX) to make writing webapps easier because writing anymore than a few lines of vanilla JavaScript was still an *awful* experience. When webapps grew in size and scope, other "transpiled" languages popped up (e.g. TypeScript) because writing anymore than a few lines of vanilla JavaScript is *still an awful* experience. We're stuck with JavaScript due to past decisions, but let's not pretend it's actually a good tool. If it were we wouldn't need 50,000 tools/frameworks/transpiled languages to hide how terrible it is.
    • sureIy 2y ago
      JavaScript is not terrible and I don’t understand where you got that from. Since ES2015 came out, it’s actually rather pleasant.
      • alxndr 2y ago
        In the first decade of this millennium, writing JS was a pretty frustrating, and JQuery papered over a lot of the nastiness.
  • pansa2 2y ago
    > 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 That's definitely a potential issue - JavaScript is the fundamental standard, not JQuery and not TypeScript. Certainly there are situations where maximum forward-compatibility is important (learning resources are a good example) and for those, vanilla JavaScript is the best choice. All of the old resources that relied on JQuery are now hopelessly outdated, whereas the contemporary ones that used plain JavaScript are as valid now as when they were written. I'm sure the same will be true of TypeScript vs JavaScript when the next big thing comes along.
• tracker1 2y ago
  Nice to see this, and important to stay closer to parity with Deno and Bun.
• hpeter 2y ago
  So, how much slower is it than running js?
• torginus 2y ago
  I might be ignorant but wasn't there a plan to add Typescript support to the browser itself? In which case wouldn't V8 support TS directly without needing to transpile?
  • herpdyderp 2y ago
    Yes. That is noted in the PR: > There is a TC39 proposal for type annotations Which links to https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations It is a long ways off though.
  • jokoon 2y ago
    all browsers would have to agree, the language would have to be very well defined and well supported across all those browsers. that would be a lot of work I would rather see new WASM features instead
• unilynx 2y ago
  If this feature ever becomes the default (ie not behind a flag) - how will the NPM ecosystem respond? Will contributors still bother to build CJS end EJS versions when publishing a NPM module, or just slap an 'engine: nodejs >= 25' on the package.json and stop bothering with the build step before pushing to NPM ? I personally would very much prefer if NPM modules that have their original code in TS and are currently transpiling would stop shipping dist/.cjs so I unambiguously know where to put my debugger/console.log statements. And it would probably be very tempting to NPM contributors to not have to bother with a build step anymore. But won't this start a ripple effect through NPM where everyone will start to assume very quickly 'everyone accepts TS files' - it only takes one of your dependencies for this effect to ripple through? It seems to me that nodejs can't move this outside an opt-in-experimental-flag without the whole community implicitly expecting all consumers to accept TS files before you know it. And if they do, it will be just months before Firefox and Safari will be force to accept it too, so all JS compilers will have to discard TS type annotations Which I would personally be happy with - we're building transcompiling steps into NPM modules that convert the ts code into js and d.ts just to support some hypothetical JS user even though we're using TS on the including side. But if node accepts .ts files we could just remove those transpiling steps without ever noticing it... so what's stopping NPM publishers from publishing js/d.ts files without noticing they broke anything?
  • rnmkr 2y ago
    I would love to ship my source code (.ts) to npm. But Typescript team was very much against this, as there'll be tsconfig issues and other performance issues. But still fingers crossed.
  • nfriedly 2y ago
    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 of the PR that added TS support and a member of the Node.js Technical Steering Committee]
• winrid 2y ago
  anyone know, for example where this is already done with Bun, how this impacts startup times with large applications?
• brundolf 2y ago
  I feel like Deno and Bun have lit a fire under the Node team to finally modernize things people have been desperately wanting for years. Great to see!
• RadixDLT 2y ago
  Oh, great, people love JavaScript. What a shock.
• olalonde 2y ago
  It just took 3 weeks to merge this? Seems really fast by Node.js standards. I assume it was discussed before the PR was opened?
• dangoodmanUT 2y ago
  NodeJS is the ChatGPT of JS. Eventuall they add the feature something else has, and then everyone uses it again instead of the other thing.
• low_tech_punk 2y ago
  Is there a slippery slope? Node -> Browser
• apatheticonion 2y ago
  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
  • pas 2y ago
    There's a "dedicated thread" on the question here https://github.com/nodejs/loaders/issues/214 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 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-2230113189 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.md#type-stripping https://github.com/nodejs/node/blob/main/doc/api/typescript.... ("Node.js will not convert from one module system to another")
• rendall 2y ago
  Love this. Next on my wish list road map is tail end recursion