>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.

▲

marcjschmidt 4 days ago | parent [-]

Except 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 4 days ago \| parent \| next [-]
		You 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 4 days ago \| parent \| prev [-]
		This 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.