5 ms·
It looks like this works by stripping away the type information, so at best it saves you a transpilation pass and doesn't improve safety.
by tempodox 1y ago
It looks like this works by stripping away the type information, so at best it saves you a transpilation pass and doesn't improve safety.
- resonious 1y agoNot needing a separate compile step just to run some script sounds great to me. I will run tsc if I want a type check.
- primering 1y agoThere is always a compile step (JS -> Bytecode -> Machine code). The question is only if it is visible to you or not. They could have made it totally transparent to you by fully support TS including type checking under the hood including support full TS and not this subset of it, but decided not to do so. There is nothing inherently great to have less compile steps if you are not even aware of it. See v8 how many compile and optimizations steps they have - You don't care, because you don't see it. The only problem of TS is, you will always be able to see it because of it being slow. I think running TS without type checks is almost entirely pointless.
- resonious 1y agoThe point is I don't have to deal with the index.js blob that gets produced by running the compile step myself. Worse yet the source maps. It's significantly less steps so pretty helpful I'd say.
- medv 1y agoExactly! Type checking can be long and costly.
- deleted 1y ago[deleted]
- akkad33 1y agoOcaml does it fast
- mattlondon 1y agoYeah agreed - saying "node can execute typescript files" is a bit misleading. More accurate would be "node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript" I suspect this would only handle the most rudimentary and basic typescript files. Once you start using the type system more extensively I suspect this will blow-up in your face. It's kinda a shame. What a missed opportunity to do it properly (rather than relying on third party plugins etc) Edit: if you are just using typescript for type checking at build time (i.e. the most basic rudimentary typescript files) the sure fine this may help you. But typescript also generates JavaScript code for missing features e.g. proper class access modifiers, generics, interfaces, type aliases, enums, decorators etc etc. typescript generates JS code to handle all that, so you're going to have a bad time if node just replaces it with the space character at run time.
- koito17 1y agoTypeScript 5.8 added a configuration option[1], where the compiler emits errors when using language features that result in code generation (e.g. enums). It's expected that people wanting to run TypeScript through "erase-only" transpilers will use this option. Of course, everyone else is free to use enums, decorators, class parameters, etc., but for quick prototyping or writing simple scripts in TypeScript, Bun has been good enough for me, and I assume Node will be "good enough" as well. [1] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-8.html#the---erasablesyntaxonly-option https://www.typescriptlang.org/docs/handbook/release-notes/t...
- sdfhbdf 1y ago> node can find-and-replace type information with spaces from .ts files and try and executing them as if they were plain JavaScript That’s what all the other tools like ts-node and tsx do already. I’m not sure what more are you expecting to do? Typescript is build time type checked, there is no runtime component to TypeScript. If you want type checking you run tsc. I think this is a great step in the right direction by node. It will save transpiration on the server and improve stack traves and whatnot. > Once you start using the type system more extensively I suspect this will blow-up in your face. I don’t see why. There isn’t any more runtime information in “complex” TypeSceipt types than in simple ones. It’s all build time - see above. > What a missed opportunity to do it properly Please explain in more detail what “doing it properly” means to you. Including the typechecker? If so that wouldn’t make sense - they would be competing with TypeScript itself, they shouldn’t, all the “third party plugins” rely on tsc for type checking.
- ryuuseijin 1y agoI'm using tsx for a project to achieve the same effect. As you said, it saves you from having to set up a build/transpilation step, which is very useful for development. Tsx has a --watch feature built in as well, which allows me to run a server from the typescript source files and automatically restart on changes. Maybe with nodemon and this new node improvement this can now done without tsx. To check types at runtime (if that can even be done in a useful way?) it would have to be built into v8, and I suppose that would be a whole rewrite.
- lbltavares 1y agoYes, it can't parse enums, for example.
- beart 1y agoI think enums are on their way out, and erasable syntax is one of the main reasons. https://dev.to/ivanzm123/dont-use-enums-in-typescript-they-are-very-dangerous-57bh https://dev.to/ivanzm123/dont-use-enums-in-typescript-they-a... They added an optional flag to disable enums (and a few other features) in 5.8 https://www.totaltypescript.com/erasable-syntax-only https://www.totaltypescript.com/erasable-syntax-only
- dust42 1y agoIt is available behind an experimental flag: --experimental-transform-types
- sdfhbdf 1y agoTypeScript never promised improving safety, maybe it’s a common misconception. But TypeScript has no runtime mode or information. You were always at the mercy of running and not ignoring the typechecker. Nothing stopped you from running ts-node or tsx on code with egregious type errors. TypeScript is more like a linter in that regard.
- MrJohz 1y agoI think it's not fair to say that Typescript isn't about improving safety, just that the mechanism isn't the same as with other languages. Typescript had always allowed you to ignore the type checker (in fact, the default configuration will always attempt to emit compiled Javascript, even if the source Typescript has type errors). But if you run the type checker on every commit (via e.g. CI or a precommit hook), then you can be sure that the code you release is correctly typed, which will not guarantee it is safe, but makes it more likely. I agree that it's better to think of Typescript as a linter that needs specialised annotations to work, rather than a type system like you might find in Java or Rust.
- tkzed49 1y ago> TypeScript is more like a linter that's exactly the point--GP is pointing out that node can't do that part
- madeofpalk 1y agoWhich is why the title is "Node can now execute Typescript files" and not lint, check, or even run TypeScript files.
- nine_k 1y agoOne of Typescript's design goals is that removing all type-related parts of the source text should yield a valid JavaScript file. A typescript compiler does not generate code (unlike, say, PureScript). You can run a typechecker (such as tsc) that check various properties of your code statically, relying on the type information. It is then erased. The same applies, say, to Python: type annotations are ignored at runtime. Somehow similarly, Java's type information is also partly erased in the bytecode; in particular, all the information about parametrized types. (This is to say nothing about actual machine code.)
- 9rx 1y ago> A typescript compiler does not generate code Except for where it does: Enums, namespaces, parameter properties, etc.
- mirekrusin 1y agoJust use erasableSyntaxOnly = true and you're fine.
- mmmmbbbhb 1y agoHadn't heard of that. Thanks
- MrJohz 1y agoThis is true but these are also old features, and the TS team have stated that they will not add any more features like those, and to a certain extent regret adding them initially (particularly decorators, which iirc were added because the Angular framework wanted to use them). You can also see that these features aren't really being updated to match recent Typescript developments (parameter properties can't do true private properties, const enums don't work with isolated modules, etc). I don't think those features are ever going to go away, because they've been around for so long and are so widely used. But I generally use erasableSyntaxOnly in new projects, because I find it's useful when my typescript source matches the generated Javascript code as much as possible.
- stevage 1y ago>so at best it saves you a transpilation pass and doesn't improve safety. That's a bit misleading. Node being able to run TS code does not "improve safety", because that's not where the type checking happens. You can do type checking in your editor, or various other points in your toolchain. Node being able to run TS code reduces the friction in writing TS code, which indirectly helps with type safety.
- primering 1y agoExcept it doesn't. In anything serious, you have to wait for a full type check to happen before you run your TS code. Why would you run code that has not been checked yet and could throw very weird errors like undefined property access? That just doesn't make sense. Yes, you can wait for your editor in your current open file, if you are lucky and the change in the open file doesn't break anything downstream in another file that is not yet open. In best case you have such simple code that nothing breaks, and in worst case, you have to still run it with type-checking - on top of running it in type-stripping-mode, because you got weird errors in runtime. This is a net negative. This whole situation is there because we are trying to workaround the slow TSC. It's not a feature, it's something we actively work around. We try to whitewash now the obviously less useful "solution" of running code without its core features enabled: type checking. To me this is insane.
- SCdF 1y agoYou can tsc on the code and then ship that git hash if it passes. You don't need to run it every single time the code executes, nothing of value is gained, because nothing has changed.
- MrJohz 1y agoThis is not my experience at all. In my experience, it's often quite useful being able to run code that doesn't fully type-check, as long as I do make sure everything's correct by the time I commit it. For example, I might be refactoring a module with some tests, and make a change that breaks the tests and some code in some other module. At this point, I often go in this order: 1. See that the tests aren't type checking correctly (usually for an obvious reason like adding an extra parameter or something). 2. Fix the tests using the type hints. 3. Run the tests to make sure my refactoring made sense and didn't break anything unexpected at runtime. 4. Fix all the uses in other modules. Step 3 requires me to be able to run code that doesn't type-check correctly, and that's a useful feature. There's also similar cases where I want to see how something looks in the UI even if it's not properly hooked up yet and causing type errors - I can check that part of the UI works and that it throws the correct runtime error (equivalent to whatever error typescript has). I've also had cases where I've cast things to `unknown` because I don't want to figure out the type just yet, and then written an implementation that is filled with typescript errors but will work at runtime as a mini proof of concept, only to later go back and get the types right. I shall think you're underestimating how important fast cycle times are. When I'm developing, I normally have my linter, tsc, the dev server (tsx or vite), and the test runner all running simultaneously in watch mode. At any one point, I'm probably only interested in the output from one of these tools (the type checker until the types are all correct, then maybe the test runner until everything's green there). But if I run all of them at once, then they all run optimistically, and the tool I'm interested in is more likely to give me immediate feedback. That's really useful! Even with the new 10x typescript compiler, I'd still rather my tests start running immediately rather than waiting for another process to start and finish before they get going.
- reactordev 1y agoTypescript mission is to strip itself of typing, what’s your point? Typescript will never be Java, you’ll never have runtime reflection.
- rand0m4r 1y agoI agree, that said if the main reason people use TypeScript is security they should use a decent programming language instead.