#server.js -> server.ts entrypoint?

1 messages · Page 1 of 1 (latest)

hot echo
#

Hey all,

I'd like to modify the entrypoint of my application, which is using express. In the getting started example, there's an example of how to run the server.js file using node, but in the loader context (https://remix.run/docs/en/main/route/loader#context) docs, this file is server.ts.

Whats the best way to run this given it's a TS file?

rich solstice
# hot echo Hey all, I'd like to modify the entrypoint of my application, which is using ex...

The overall best way is to look at the epic-stack by Kent c Dodds where he has a proper server.ts file that he builds into a server.js manually on his own which I believe personally is the “most correct” way to do it but also has the most added complexity.

The simplest and fastest way to do it that’s also reasonably effective is to just use something like tsx that will directly run your ts files like they’re js files.

hot echo
#

Thanks!

The simplest and fastest way to do it that’s also reasonably effective is to just use something like tsx that will directly run your ts files like they’re js files.

So a server.tsx file - don't I have the same issue though as I'd need to compile this to run it?

hot echo
#
frigid zinc
#

I had the same issue and also ended up using tsx to run the server.ts file.

I also tried to create a bundle with esbuild but for some reason it was failing at runtime.

oak juniper
#

The simplest way it to use esbuild to compile server.ts

Here's my template that does this https://github.com/kiliman/remix-vite-express

"scripts": {
  "build": "remix vite:build && npm run build:server",
  "build:server": "esbuild server.ts --platform=node --outdir=build/server",
  "start": "node build/server/server.js"
}
rich solstice
oak juniper
#

I don't include the --bundle flag in esbuild. It simply compiles server.ts and lets it import from node_modules as needed.

fallen drift
#

btw, i'm a server.ts user too. we tried both ways but decided running with tsx is the best way in prod rather than to do another compile step.

#

but caveat we use k8s and pm2 which kind of negates the need for super fast start up times.

#

(because neither k8s or pm2 will switch traffic until the server is confirmed to be running)

oak juniper
#

True, but if you're using Docker, then you'll need to include tsx and all it's dependencies as a regular dependency instead of a devDependency. This forces the production image to be larger than it needs to be. My Dockerfile typically uses a build layer that gets removed in the final image.