Thanks for this! Setting up a new Node project in 2023 is: 1 hour setting up the build environment 1 hour setting up linting 1 hour getting webpack to work 1 more hour optimizing everything 3 hours researching Deno / Bun / Vite, then deciding it's not worth it 1 hour wondering if you're better off with plain JS 1 hour remembering what you wanted to build
This guy is always reminding me why I 1. Hate the JS ecosystem with a passion 2. Admire the JS developers that maintain their sanity and build stuff with it
The module field is pretty much abandoned. It's only really used by bundlers. The correct way to tell node how to import your code is to use the "files" and “exports” fields. Not trying to sound like a stackoverflow comment, just wanted to share a thing I picked up after diving into all this stuff recently. Excited to watch the rest, I love your content!
Every year for advent of code, I spend a majority of my time configuring my baseline JS/TS environment rather than working on the coding problems, which is fun because I get to see how much things have changed just like this video hits on 😆 Edit: I'm excited to see this full course and how it evolves ;D 🎉
@@alanbixby I tend to lean into ts-node, but now it's sounding like a nightmare yet again lol; I'll have to look into esbuild kit I guess lol; yet another tool :RIP: They used to say to never use ts-node for production, then you could; all the answers are an answer in one point in time and then never again down the road as they become the "wrong answer" lol I'm just glad to have node 18 here and the older versions dying off 🎉 It's all still a pain though.
@@lsudo tsx is a CLI program, short for typescript execute. it uses esbuild to transpile all imports to js in memory on demand really fast. it also supports jsx/tsx the language extension, which is a bit confusing at first.
Million likes for this video! I spent the entire day debugging until I stumbled upon your video. Turns out, the issue was that I was importing a common JS package without specifying {"type":"module"} in the package.json. Thank you so much! ❤❤❤❤❤
A thousand thank-yous for this! I wish this video were linked in the TypeScript official getting started docs. As an infrequent JavaScript developer starting to dig into the TypeScript ecosystem, the legacy module situation is a huge stumbling block to get past. Love your straightforward presentation.
Thank you! This could not come at a better time. For the life of me I could not get TypeScript working with my GraphQL setup but your review of the tsconfig files cleared up my confusion. My main issue was needing to add the .js file extensions to the imports.
For those that want nodemon to watch over file changes: add "ts-node": { "esm": true } to tsconfig.json And if your shell complains like mine did use ( npx nodemon src/index.ts ) this should work Also add ts-node globally with ( npm i -g ts-node ) really not sure if this is needed but I did it anyway
When you compile you run the .js file and you target the other .js files, typescript won't change your import to ts so you declare it with .js that's why...
@@stxnw when I dont specify the files extension, "esModuleInterop" set to true gives me: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext' When using .ts files, The vscode hints say: "An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.ts(5097)" When I enable it, all errors are gone, but the typescript compiler throws: "error TS5023: Unknown compiler option 'allowImportingTsExtensions'." So weird.
Thanks a lot! ❤ I was able to figure this out the hard way, but I'm glad I stumbled upon this video for a) confirming that I did it correctly and b) future references. Cheers!
Deno NPM compatibility is nearly there! We're so close. Most libraries just work OOTB already. I am running from node with the speed of light my man, at least for my personal projects
It's truly a peculiar experience see how this channel's owner is gradually descending into madness by the hand of web technologies mostly. I just can't look away... keep the hard work
You should make a movie about package managers, only few people know about PNPM for example, but for now it's the fastest and most space efficient solution!
I always find myself having a mini heart attack when watching your videos because you'll occasionally hear a baby crying in the background and I ALWAYS think it's my baby. I'm literally home alone right now and still paused the video to listen out for him crying :')
I need to work with pure javascript to get CommonJS working, because of dynamically use the code and re-import it on runtime is such a blessing as well a curse. But for my project and personal works, it's perfectly fine.
I'm still confused as to why we need to specify file extention when we import. Couldn't node/TS resolve it itself based on the actual file it is importing?
I kind of remember Ryan Dahl spoke about this being needlessly complex to implement and (not so sure if I remember this right) hogs resources. If he were given a chance to do Node all over again he would not do it.
I just use tsc-alias to fix the import file extension after compiling. It's easier and cleaner. And handles the path aliasing. I would recommend using nodenext for moduleresolution, but for the module option to use esnext or commonjs
npm init tst --init Done. Now, my way of doing this is (as a proud developer) is scripting all of this. Hosting CommonJS and ESM project templates on a NodeJS-based, fully automated file server that's using my own database that's using its own virtual file system and cloning it whenever I need. Yes It's overcomplicated for a reason don't argue just accept that life isn't always the way it should be.
It's important to highlight that this is only one way to set up Typescript with Node in 2023. I have different priorities, revolving more around minimizing surprises than around efficiency, so I do almost everything differently, and I don't expect my values to turn around completely next year either. This tutorial is valuable because it's a complete description of an error-free setup, not because the statements within are universally optimal.
It feels like this message is trying to tell us something without actually saying what it is. Or maybe I'm just missing something obvious. Can someone express the "different priorities" in more blunt terms?
For developing nodejs backend, I generally use babel with watch mode and nodemon to have very fast server restart on file save. I'll check this out but I'll probably still prefer sticking with a faster transpiler than tsc
Great video as always. From 3.09 secs to 3.28 secs, your voice sounded different. Is it me or has anyone noticed it? R u well bro. Please stay safe and sound. Looking forward to your next video.
Just yesterday I was dealing with something similar with Fastify and Typescript. I wanted to be using ESM, and went through the whole troubleshooting process to figure out the right tsconfig settings, but due to the way a lot of Fastify packages were exporting their types it broke being able to import the default export from it. I don't know the specifics, but it was just super annoying that this glorified linter was causing such an obnoxious bug for code that worked fine without it. However, Typescript in Deno is a beautiful experience. Largely I think because you don't have to worry about commonJS. Makes me wonder if as Deno gets more popular, the TS Node people will move over to it
@@Zwiebelgian it's not a lot of work to setup a typescript project , cleaner directories I'm not seeing any problem, speed not sure , I've not seen any benchmarking
@@Zwiebelgian yeah, it also has better apis under the Deno. namespace and a std library. You also get less config files, lots of built in stuff like linter so you don’t have to do that yourself, more secure, faster http server, better browser compatibility, the apis mostly use promises (and sync versions) instead of callbacks, you can run code directly from a url, even Ts code and so on The npm support doesn’t work on all packages perfectly just yet but soon:tm:
Who has the error: ERR_UNKNOWN_FILE_EXTENSIONr You need to install tsx instead of ts-node and change it in nodemon.json if you use it, in the exec line, accordingly.
Nah, this is one of the reasons why I use Nest.js - TypeScript by default, no hassle, no cry - just awesome architecture, typescript and more time for playing Witcher 3 after the work is done.
I'd advise using a runner like TSX or Esbuild runner. This strips the types and makes it much less painful to develop. Type checking is gradually moving in the direction of being a CI step rather than part of the build step.
Importing a js file in typescript that doesn't exist on the file system is really confusing and simply weird. It's way better to use a tool like tsc-alias to fix the imports as a compilation step instead of having to change every import of every source file in every project.
Just add the path alias in tsconfig.json for the "@components" or even better, just point "@" to the src folder, so you can "@/anything". Then, install @types/node and @types/express as development dependencies. If you use dotenv and cors, install @types/dotend and @types/cors.
@@LarsRyeJeppesen yeah, there are a lot of issues in Node and TypeScript, and each bundler have its own solutions. But for now, that's the solution and packages like module-alias or better-module-alias. But if you know of a better solution, please comment it instead of being secretive about it. Cheers!
Oh man, how I hate those .js imports inside of a TS file. Hope MS or node comes out with something better ASAP. If not - then DENO could really be the next move for me. Thanks for the video!
can you cover how to really create a backend API with express which can scale? Like express doesn't offer good auto error handling, which just results in a lot of try catch blocks. Everytime I think of starting a backend project, Express is the first thing that comes in mind because it is the most famous one. But writing anything with it feels like practicing or bad code practice. Basically I am asking for a structured way to use express for a backend api.
You can try NestJS. It has the structure you are looking for. It can use fastify or express under the hood. However, you usually work above that unless you need something really specific. Although JS is supported, its best to use typescript. The main point of the framework is program structure. Each part of your app (controllers, services, guards, interceptors, etc) are built to be reused and easily manageable. I could talk more about it but their documentation is pretty good.
why not make a nestjs video? Nest is a framework for building efficient, scalable Node.js server-side applications. It uses modern JavaScript, is built with TypeScript (preserves compatibility with pure JavaScript) and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).
Thanks for this! Setting up a new Node project in 2023 is:
1 hour setting up the build environment
1 hour setting up linting
1 hour getting webpack to work
1 more hour optimizing everything
3 hours researching Deno / Bun / Vite, then deciding it's not worth it
1 hour wondering if you're better off with plain JS
1 hour remembering what you wanted to build
That’s exactly why I skip half of that stuff
How is vite not worth it? 90% of use cases is just install boom works
Ask c++ Devs
Just do bun init
about what ?@@-rate6326
This guy is always reminding me why I
1. Hate the JS ecosystem with a passion
2. Admire the JS developers that maintain their sanity and build stuff with it
Requiring the .js extension from TS was the most stupid TS idea in long time.
@@Caborrrl well, it's technically the spec.
The TS system is very "what the spec is".
Having unsuffixed imports is not valid js.
@@Caborrrl there's a compiler option "esModuleInterop" that fixes it
@@filipmajetic1174 No. The esModulelnterop is not for that or anything related to that. Wtf?
@@shapelessed Just realized my handle is the weird generated one. But I've been there with another stack, same pain.
The module field is pretty much abandoned. It's only really used by bundlers. The correct way to tell node how to import your code is to use the "files" and “exports” fields. Not trying to sound like a stackoverflow comment, just wanted to share a thing I picked up after diving into all this stuff recently. Excited to watch the rest, I love your content!
OMG I literally sat there with this exact issue an hour ago and couldn’t resolve it and this appears in my subscriptions - THANK YOU!!
Every year for advent of code, I spend a majority of my time configuring my baseline JS/TS environment rather than working on the coding problems, which is fun because I get to see how much things have changed just like this video hits on 😆
Edit: I'm excited to see this full course and how it evolves ;D 🎉
Change to Deno. You'll get TS, top-level async, ESM, external modules, linting/formatting with 0 config
@@zettca No. I can't use Deno at work. I wouldn't learn Zig right now for the same reason. Not worth it. I need to know the node ecosystem.
@@codeman99-dev we're talking about AoC, not work.
@@zettca Yes. It is a great opportunity to catch up and learn what is new. It is hard to do that if you jump ship.
@@zettca Just curious, what is AoC?
I feel like it might be a good idea to cover the ts-node package next time which is nice during development
@@vaaski that's basically react my friend
@@vaaski tsx is for react components; we don't need that additional weight here if you're just trying to write some non-frontend code.
@@alanbixby I tend to lean into ts-node, but now it's sounding like a nightmare yet again lol; I'll have to look into esbuild kit I guess lol; yet another tool :RIP:
They used to say to never use ts-node for production, then you could; all the answers are an answer in one point in time and then never again down the road as they become the "wrong answer" lol
I'm just glad to have node 18 here and the older versions dying off 🎉
It's all still a pain though.
@@lsudo No, we're not talking about react or jsx/tsx. Tsx is an npm package, does the same thing as ts-node but it's newer.
@@lsudo tsx is a CLI program, short for typescript execute. it uses esbuild to transpile all imports to js in memory on demand really fast. it also supports jsx/tsx the language extension, which is a bit confusing at first.
Million likes for this video! I spent the entire day debugging until I stumbled upon your video. Turns out, the issue was that I was importing a common JS package without specifying {"type":"module"} in the package.json. Thank you so much! ❤❤❤❤❤
A thousand thank-yous for this! I wish this video were linked in the TypeScript official getting started docs. As an infrequent JavaScript developer starting to dig into the TypeScript ecosystem, the legacy module situation is a huge stumbling block to get past. Love your straightforward presentation.
I spent 3 hours on fixing this. Thank you so much.
Thank you! This could not come at a better time. For the life of me I could not get TypeScript working with my GraphQL setup but your review of the tsconfig files cleared up my confusion. My main issue was needing to add the .js file extensions to the imports.
me tooooo
top notch video, can't wait for the 2024 guide
Did the 2024 guide drop yet? bro left us hanging..
@@nithinrajendran3091 sadly not.. we'll have to wait a few more months
For those that want nodemon to watch over file changes:
add
"ts-node": {
"esm": true
}
to tsconfig.json
And if your shell complains like mine did use ( npx nodemon src/index.ts ) this should work
Also add ts-node globally with ( npm i -g ts-node ) really not sure if this is needed but I did it anyway
You saved me, thank you!
OR us tsup --watch
Why we need to target .js files when they extensions are .ts ? It is so confusing.
You don't. Jeff just doesn't know about the esModuleInterop option on TypeScript.
When you compile you run the .js file and you target the other .js files, typescript won't change your import to ts so you declare it with .js that's why...
@@18.j Wrong
@@stxnw How does TS handle this then?
@@stxnw when I dont specify the files extension, "esModuleInterop" set to true gives me:
Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'
When using .ts files, The vscode hints say:
"An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.ts(5097)"
When I enable it, all errors are gone, but the typescript compiler throws:
"error TS5023: Unknown compiler option 'allowImportingTsExtensions'."
So weird.
Thanks a lot! ❤
I was able to figure this out the hard way, but I'm glad I stumbled upon this video for a) confirming that I did it correctly and b) future references.
Cheers!
Yess!!!! I was hoping to see this video one day on your channel :)
you don't know how much you helped me.. thanks mate
Thanks for the video. very simple explanation. You solved my confusion
Amazing tutorial, It's definitely a good tutorial for beginners, keep up the good work!
Deno NPM compatibility is nearly there! We're so close. Most libraries just work OOTB already. I am running from node with the speed of light my man, at least for my personal projects
You're a magician for sure!!
It's truly a peculiar experience see how this channel's owner is gradually descending into madness by the hand of web technologies mostly.
I just can't look away... keep the hard work
You should make a movie about package managers, only few people know about PNPM for example, but for now it's the fastest and most space efficient solution!
And messy. The amount of time I have spent resolving fcked up symlinks is countless
Excellent tutorial!
Exactly what I needed . Perfect video!
I always find myself having a mini heart attack when watching your videos because you'll occasionally hear a baby crying in the background and I ALWAYS think it's my baby. I'm literally home alone right now and still paused the video to listen out for him crying :')
I need to work with pure javascript to get CommonJS working, because of dynamically use the code and re-import it on runtime is such a blessing as well a curse. But for my project and personal works, it's perfectly fine.
That sounds horrific
That's exactly why I created typescript-project-generator. It will handle all the configs for using TS with Node.js. Give it a try :)
Just soooo coool. Great video man
The video I never knew I needed, thanks Jeff :)
Love it! Looking forward to watching your full course. But please do it for experienced developers too
Awesome video! Any chance there is a pt. 2 coming with jest, eslint, prettier, and husky?
i was here for the module thing, thanks
Great use of
Kudos for the concise & resourceful video 🙌
Madness....... ?
THIS IS JavaScript ecosystem 🔥🔥🔥🔥🔥🔥
Looking forward to part two if this video in a month when all of this changed again :D
Great content as always
Good video.
tsconfig.json (just create the ./scr and ./dist directories):
{
"compilerOptions": {
"target": "ESNext",
"module": "commonjs",
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"strict": true,
"skipLibCheck": true,
"rootDir": "src",
"outDir": "dist",
},
"include": [
"src/**/*.ts"
],
"exclude": [
"node_modules",
"test",
"dist",
]
}
I'm still confused as to why we need to specify file extention when we import. Couldn't node/TS resolve it itself based on the actual file it is importing?
I kind of remember Ryan Dahl spoke about this being needlessly complex to implement and (not so sure if I remember this right) hogs resources. If he were given a chance to do Node all over again he would not do it.
I just use tsc-alias to fix the import file extension after compiling. It's easier and cleaner. And handles the path aliasing. I would recommend using nodenext for moduleresolution, but for the module option to use esnext or commonjs
npm init
tst --init
Done.
Now, my way of doing this is (as a proud developer) is scripting all of this. Hosting CommonJS and ESM project templates on a NodeJS-based, fully automated file server that's using my own database that's using its own virtual file system and cloning it whenever I need.
Yes It's overcomplicated for a reason don't argue just accept that life isn't always the way it should be.
life saver video
Bruh how did you know I was setting up a project to with both esm and cjs you really are a wizard 👀
0:45 javascript at its peak
1) ts-node + nodemon could be very helpful
2) npm i tsconfig@ for certain node version could be helpful, just extends it
no. ts-node is trash
@@stxnw why? And what can replace it?
@@VideoBunt swc-node
ts-node is horrible. Do not use it please
@@VideoBunt tsup (esbuild) in watch mode
evey once in a while i come back and watch this video
Good timing on that video, since advent of code is around the corner ❤
Time travel is real! Jeff is one month ahead of us!😂❤
Great video.
This reminded me of the reason I don't like web dev... too many moving parts just to get a simple webpage to run.
Don't forget to add the "--enable-source-maps" flag when running your compiled code with node, otherwise the sourcemaps will be ignored.
the moth really cheered me up i cant lie
It's important to highlight that this is only one way to set up Typescript with Node in 2023. I have different priorities, revolving more around minimizing surprises than around efficiency, so I do almost everything differently, and I don't expect my values to turn around completely next year either.
This tutorial is valuable because it's a complete description of an error-free setup, not because the statements within are universally optimal.
It feels like this message is trying to tell us something without actually saying what it is. Or maybe I'm just missing something obvious. Can someone express the "different priorities" in more blunt terms?
Or just use ts-node
Thanks a shit ton for this! I wasted so much time fixing the imports with .ts ext.
Lol i needed that exactly 2 days ago xD
For developing nodejs backend, I generally use babel with watch mode and nodemon to have very fast server restart on file save. I'll check this out but I'll probably still prefer sticking with a faster transpiler than tsc
why use babel when u have vite or even the newer tool, rome
@@double-agent-ly Vite for backend? Hmm
For developing frontend I use Vite for very fast hot reload on file save.
Babel is not fast
@@shubitoxXSure faster than tsc, because it just ignores the types, it doesn't type validate the AST like tsc does..
"noEmit": true,
"allowImportingTsExtensions": true,
adding these two will allow you to import ts files as .ts files only.
You forgot about strict mode in tsconfig.json!
This is amazing. Thank you :)
Is it only me who feels like Jeff's voice is changing constantly over the video...?
Great video as always. From 3.09 secs to 3.28 secs, your voice sounded different. Is it me or has anyone noticed it? R u well bro. Please stay safe and sound. Looking forward to your next video.
I have a cold. Nothing serious
I was thinking the same
Just yesterday I was dealing with something similar with Fastify and Typescript. I wanted to be using ESM, and went through the whole troubleshooting process to figure out the right tsconfig settings, but due to the way a lot of Fastify packages were exporting their types it broke being able to import the default export from it. I don't know the specifics, but it was just super annoying that this glorified linter was causing such an obnoxious bug for code that worked fine without it.
However, Typescript in Deno is a beautiful experience. Largely I think because you don't have to worry about commonJS. Makes me wonder if as Deno gets more popular, the TS Node people will move over to it
Except deno breaks your code in ways you can't imagine because of their weird engine
looking forward to that typescript course
Can you make a tutorial on how to host a node app on IIS?
Excellent!
I like the video, I hated the topic, but it was good content
As someone in 2023, I can confirm this is how you setup Node.js with TypeScript
@@minorikoaki No, other way around
No no no, don't use tsc, and don't use ts-node.
@@LarsRyeJeppesen Sorry, in 2023, we still use tsc for some reason... I don't make the rules
Thank you, i was struggling with the tsconfig trying to get the top level await feature working
Super
Thanks for a great tutorial and a perfect argument why not to use JS/TS ; )
Thank you so much!
was hoping you would cover how to run the equivalent of nodemon when a change is made to the typescript source code.
Deno now supports npm (atleast that is what their propaganda says) so now may be a good time to switch
Why ? I just want to know what will you gain ?
@@brucewayne2480 Built-in Typescript support, better speed, cleaner directories. I don‘t actually know, I am not a backend developer
@@Zwiebelgian it's not a lot of work to setup a typescript project , cleaner directories I'm not seeing any problem, speed not sure , I've not seen any benchmarking
@@Zwiebelgian yeah, it also has better apis under the Deno. namespace and a std library. You also get less config files, lots of built in stuff like linter so you don’t have to do that yourself, more secure, faster http server, better browser compatibility, the apis mostly use promises (and sync versions) instead of callbacks, you can run code directly from a url, even Ts code and so on
The npm support doesn’t work on all packages perfectly just yet but soon:tm:
For me personally the sandboxing capabilities are nice
Who has the error: ERR_UNKNOWN_FILE_EXTENSIONr
You need to install tsx instead of ts-node and change it in nodemon.json if you use it, in the exec line, accordingly.
Can you make a video on the T3 Stack from Theo?
Nah, this is one of the reasons why I use Nest.js - TypeScript by default, no hassle, no cry - just awesome architecture, typescript and more time for playing Witcher 3 after the work is done.
I had to do this last week haha
Please make a video on pr-commit hooks
Great, I only needed 3 minutes to give up on frontend dev.
I'd advise using a runner like TSX or Esbuild runner. This strips the types and makes it much less painful to develop. Type checking is gradually moving in the direction of being a CI step rather than part of the build step.
Agree, TSX or Esbuild - or Turbo
Importing a js file in typescript that doesn't exist on the file system is really confusing and simply weird. It's way better to use a tool like tsc-alias to fix the imports as a compilation step instead of having to change every import of every source file in every project.
Yeah I don’t like it
Is there a way to resolve this that works both during compile time and in VSCode?
Very good guide, amazingly frustrating topic.
use full bro
How about a demo on how to make a basic PWA?
Thanks a lot.
tsc? What about Turbo, EsBuild etc? Why use npm when we have pnpm?
Lately I found myself better setting vite-node rather than trying to set all that experimental flags to run my code with modern day devfeatures
Do Babel next.
Maybe quick guide here on how to set eslint?
2023? Getting a little ahead of ourselves aren't we?
Express + TypeScript, please. With nice paths like "import ASDF from @componets/navbar" Please!
Just add the path alias in tsconfig.json for the "@components" or even better, just point "@" to the src folder,
so you can "@/anything".
Then, install @types/node and @types/express as development dependencies.
If you use dotenv and cors, install @types/dotend and @types/cors.
@@angelhdzdev That won't work well in many environments.
@@LarsRyeJeppesen yeah, there are a lot of issues in Node and TypeScript, and each bundler have its own solutions. But for now, that's the solution and packages like module-alias or better-module-alias.
But if you know of a better solution, please comment it instead of being secretive about it.
Cheers!
I went through this a couple of months ago. But there might be some starter templates. At least there should be one.
Thank You
Thanks thanks thanks!!!
Funny how this video is only a day old and I already out of date with the new Node 19 release (which supports imports without the .js file extension)
Oh man, how I hate those .js imports inside of a TS file. Hope MS or node comes out with something better ASAP. If not - then DENO could really be the next move for me. Thanks for the video!
can you cover how to really create a backend API with express which can scale? Like express doesn't offer good auto error handling, which just results in a lot of try catch blocks. Everytime I think of starting a backend project, Express is the first thing that comes in mind because it is the most famous one. But writing anything with it feels like practicing or bad code practice.
Basically I am asking for a structured way to use express for a backend api.
I want this as well
Use fastify.
Use something like joi for body validation and clean architecture to build an app
You can try NestJS. It has the structure you are looking for. It can use fastify or express under the hood. However, you usually work above that unless you need something really specific. Although JS is supported, its best to use typescript.
The main point of the framework is program structure. Each part of your app (controllers, services, guards, interceptors, etc) are built to be reused and easily manageable. I could talk more about it but their documentation is pretty good.
As somebody else already said, NestJS is probably what you're are looking for if you want a robust and fast NodeJS backend framework.
I think you should add the watch option for watching new changes instead of compiling everything manualy
why not make a nestjs video? Nest is a framework for building efficient, scalable Node.js server-side applications. It uses modern JavaScript, is built with TypeScript (preserves compatibility with pure JavaScript) and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).
copy paste dummy
thank you
get well bro
All these typescript problems make me solve with Vite (if Node.js required) or... Deno!