Regarding the previous backend related article and code sharing between backend and frontend, how does your project setup look like?
For example, does the code get compiled using a bundler like webpack? if yes how do you solve the import '../../../../../shared.ts' problem? Or do you use node modules in a monorepo? Compared to other languages I found these questions surprisingly difficult to answer and solutions often quite cumbersome, e.g. if I want to share one small file in my project I don't want to maintain a public npm module for it...
We use a single git repo with no npm packages defined, other than the package.json in the root because we have to put dependencies etc. in there. The directory structure for our source code is dead simple:
src/server
src/client
src/common
For example, the API endpoint definitions are common code, so you'll see stuff like this in client code that uses the API:
import * as quizApi from "../../common/api/pages/quiz"
The ".."s are annoying, but working around them isn't worth the effort. Even when we heavily reorganize the file organization, it only ends up taking a few minutes to mechanically update these imports with a vim macro, or even with sed if it's a perfectly mechanical change.
We run two copies of tsc: one for the client and one for the server, building to build/server and build/client. That results in a weird build directory structure:
If you need separate build settings for client and server, this weirdness is going to show up one way or another. However, we only introduced this build separation in the last month or so. For the first 1.5 years of the project, we got away with a single tsc process and tsconfig.json, with no build separation at all between client and server. If anyone who's newer to TS reads this, I'd encourage looking for simple solutions like that; you can get to the weirder stuff down the road if you need it (and you may never need it!)
Thanks for sharing! We actually tried the same approach but we have a couple of more micro services relying on the same shared code. This has some additional complications, e.g. managing all dependencies for all services in one package.json is a bit messy and preparing a pkg for deployment gets a bit more complicated...
Ahh, if you're taking the microservice path then you're going to have to fight all of that complexity. So far we've stuck to the constraints that I set at the beginning of the project: vanilla Heroku web dynos; exactly one Heroku worker dyno (never 0 or 2); and Postgres is the only data store (no queues etc.)
Ever heard of the "rootDirs" [1] option in tsconfig.json? You can use it to aggregate code files in the various folders as if they were in one flat folder (as far as TS is concerned) while editing. Before building with WebPack, you can copy all the code files into a temporary build folder and then run WebPack on it.
For example, does the code get compiled using a bundler like webpack? if yes how do you solve the import '../../../../../shared.ts' problem? Or do you use node modules in a monorepo? Compared to other languages I found these questions surprisingly difficult to answer and solutions often quite cumbersome, e.g. if I want to share one small file in my project I don't want to maintain a public npm module for it...