#How to import types from sibling typescript project?
14 messages · Page 1 of 1 (latest)
`!sandiford:module`:
"module" in tsconfig today usually refers to your environment rather than the module type you want to use.
If you are using recent versions of Node, use "module": "Node16". This will automatically set "moduleResolution" to the same value, so it's not necessary to set "moduleResolution". To control the module type, in package.json set "type": "module" for ESM or "type": "commonjs" (or don't set "type") for CJS.
For Bun or code that will be bundled before being run, use "module": "preserve".
For Deno use "module": "ES...".
"module": "commonjs" refers to a pure CommonJS environment without new features like import() and is almost never appropriate.
!:paths-are*
`!t6:paths-are-not-magic`:
The paths and baseUrl compiler options don't cause any remapping of imports paths, they only inform TS of existing mappings, which you'll have to setup with some other tool.
baseUrl is a pretty well-supported option (e.g. using the NODE_PATH environment variable with node or resolve.modules with webpack).
paths can be trickier to setup, (especially with node see this for node), and you may find it to not be worth the effort.
You'll need to import it using the name you used in dependencies. It won't work with @ imports
Generally though you should not be importing anything except types from the API to the frontend. The API may depend on node/server features not available in browser
You can use inport type { } ... to enforce this
Hmm, I use this a lot, it works, I wonder what the issue is
client-api and api are both server side, so safe to load each other?
I would not try to load api/src/test/database/database. When you run in production mode you'll need to compile api/src to api/dist and so client-api will load files from api/dist. I suggest that you match this in your code, and compile your api project with tsc so you have the dist files.
I don't know if tsx can support loading from src of another project, and it would break in production anyway.
And also build .d.ts files with "declarations": true in tsconfig of api. You might be able to make TS look at the .ts sources files using projectReferences config https://www.typescriptlang.org/docs/handbook/project-references.html but I've never tried this myself.
How to split up a large TypeScript project
or maybe paths
You'll be loading types from src but runtime files from dist, so not sure it's a very good idea, would be a mismatch if you forgot to build api.