We're going to walk through how to set up Typescript in your project. Through this, we'll get a bit of exposure into how browser runtimes run Javascript/Typescript code differently than the Node runtime.

We'll want to use ESModules: by adding "type": "module", to our package.json

ESModules are using import x from 'y' / export default z CommonJS const x = require('y') / module.exports = z

CommonJS is an old module system, that's still around due to backwards compatability. Technically, anything that can be done with ESM, can be done with CommonJS. But ESM is part of ECMAScript, the official JS spec, and will be supported moving forward.

Major libraries still use CommonJS, because it's backward compatible and is therefore the most stable.

Setting up Typescript

npm install typescript --save-dev you could optionally, make a tsconfig.json file. you could run npx tsc --init, or you could do waht I do and just manually make a tsconfig.json file. The reason being that npx tsc --init genrates a typescript config, that for me, is too verbose and exhaustive.

You can add "paths": { "@/": [""] } if you want to compilerOptions, but make sure that you configure your bundler supports it.

This would be needed, at a minimum, for basic Typescript lint errors to go away. { "compilerOptions": { "target": "ESNext", "module": "ESNext", "outDir": "dist", "rootDir": "src" "moduleResolution": "node", }, "include": ["src"] }

We'll also install tsx, which will let us run Typescript files directly in Node, without compiling to Javascript first. tsx will be important for specifically executing our server code. We could alternative install ts-node, but tsx seems to be more popular these days.

Minimalist building

With regular Javascript code, we previously demonstrated how we can use the 'node' command, and then require a file, in order to execute the file.

Using tsx, the flow is the same - we enter the tsx REPL using: npx tsx

Then we can execute the file by going: await import('./src/index.ts')

Using tsx, we could also set up a 'start' script in package.json, and then run that. We'll configure this as so:

"scripts": { "start": "npx tsx src/index.ts" },

Making your app work with the web

As we saw, we can run Typescript files locally using the tsx REPL. But web browsers, on the other hand, can't run Typescript natively. For the web, we need a bundler, which converts Typescript to Javascript. Because we're using typescript, we need this extra compilation layer.

Webpack used to be the go to, but it's big, not the easiest to configure. Vite is really popular these days, and it's really easy to set up.

Using Vite

Before Vite, to render an interactive website with a frontend, we would locally double click our index.html file and as long as we do

The second we do , which matches ESModule type executions, those API calls will fail, because browsers treat ESModules (modules) as running on the http:// protocol, not file:// protocol.

To test locally, but run on the http:// protocol, we need a (local) server, which will allow us to serves your files over HTTP.

fetch() requires a valid http(s) origin.

Browsers block file:// origins from making network requests.

Web browsers will automatically try to route a user to a http destination. But we're running on the filesystem, not http (yet!).

With Vite, Vite opens a development server locally on our computer, which allows us to run our front end, and incorporate Javascript code. Having a development server to execute the front end is important, because -- this gives us a HTTP protocol. By default, browsers don't let us use file:// as an origin, and click around, import/export other modules.

When we have a local server and our site is served from http://localhost:3000.index.html, it knows that if we have a utils/something.js, it will be located at http://localhost:3000/utils/comething.js.

Remember that we're in a web browser. file:// means it's in the file system, and browsers aren't meant to work with file systems.

In the old days people used global scripts

We're using ESModules to bring in scripts, and that requires a real HTTP server to load properly in the browser. The browser treats ESModules imports as http requests.