Working with multiple Node.js applications in TypeScript often presents a unique challenge: how to efficiently and effectively share types across different parts of your project.



This is particularly crucial during a transition from JavaScript to TypeScript, where consistency in types is key to high-quality code and error prevention. 



In this guide, we&#8217;ll dive into an elegant solution for this challenge using a monorepo structure and Yarn workspaces.



<h2 class="wp-block-heading">Initialize a New Repository</h2>



Start by creating a new repository to house your entire project. This will serve as the foundation for implementing a monorepo structure. 



A monorepo is a version control repository that holds multiple projects, allowing you to manage them collectively.



<h2 class="wp-block-heading">Set up Yarn</h2>



Yarn is a fast and reliable dependency management tool that supports workspaces, making it an excellent choice for managing a monorepo. If you haven&#8217;t already, install Yarn by running:


<pre class="wp-block-code" aria-describedby="shcb-language-1" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><link rel='stylesheet' id='syntax-highlighting-code-block-css' href='https://cms.arontolentino.com/wp-content/plugins/syntax-highlighting-code-block/vendor/scrivo/highlight-php/styles/night-owl.css?ver=1.4.0' media='all' /><style>.wp-block-code {
	border: 0;
	padding: 0;
	-webkit-text-size-adjust: 100%;
	text-size-adjust: 100%;
}

.wp-block-code > span {
	display: block;
	overflow: auto;
}

.shcb-language {
	border: 0;
	clip: rect(1px, 1px, 1px, 1px);
	-webkit-clip-path: inset(50%);
	clip-path: inset(50%);
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: absolute;
	width: 1px;
	word-wrap: normal;
	word-break: normal;
}

.hljs {
	box-sizing: border-box;
}

.hljs.shcb-code-table {
	display: table;
	width: 100%;
}

.hljs.shcb-code-table > .shcb-loc {
	color: inherit;
	display: table-row;
	width: 100%;
}

.hljs.shcb-code-table .shcb-loc > span {
	display: table-cell;
}

.wp-block-code code.hljs:not(.shcb-wrap-lines) {
	white-space: pre;
}

.wp-block-code code.hljs.shcb-wrap-lines {
	white-space: pre-wrap;
}

.hljs.shcb-line-numbers {
	border-spacing: 0;
	counter-reset: line;
}

.hljs.shcb-line-numbers > .shcb-loc {
	counter-increment: line;
}

.hljs.shcb-line-numbers .shcb-loc > span {
	padding-left: 0.75em;
}

.hljs.shcb-line-numbers .shcb-loc::before {
	border-right: 1px solid #ddd;
	content: counter(line);
	display: table-cell;
	padding: 0 0.75em;
	text-align: right;
	-webkit-user-select: none;
	-moz-user-select: none;
	-ms-user-select: none;
	user-select: none;
	white-space: nowrap;
	width: 1%;
}
</style><code class="hljs language-bash">npm install -g yarn</code>Code language: Bash (bash)</pre>


Then, initialize Yarn in your project:


<pre class="wp-block-code" aria-describedby="shcb-language-2" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><code class="hljs language-bash">yarn init -y</code>Code language: Bash (bash)</pre>


This will generate a <code>package.json</code> file for your monorepo.



<h2 class="wp-block-heading">Create Package Structure</h2>



Let&#8217;s set up our project structure with a practical example. Imagine we are building a platform that includes a web application, an API, and a set of shared TypeScript types. 



We will create directories for each package as follows:


<pre class="wp-block-code" aria-describedby="shcb-language-3" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><style>.hljs > mark.shcb-loc { background-color: #273847; }</style><code class="hljs language-bash shcb-code-table">packages/
 api/
 src/
 package.json
 ...
 web/
 src/
 package.json
 ...
 shared-types/
 src/
 package.json
 ...
package.json
</code>Code language: Bash (bash)</pre>


Each package directory should contain its own <code>package.json</code> file, specifying its dependencies, scripts, and other relevant information.



<h2 class="wp-block-heading">Update Root Package.json</h2>



Open the <code>package.json</code> file in the root of your project and modify it to include an array of packages and set <code>private</code> to <code>true</code>. This ensures that your monorepo packages are not accidentally published to the npm registry:


<pre class="wp-block-code" aria-describedby="shcb-language-4" data-shcb-language-name="JSON / JSON with Comments" data-shcb-language-slug="json"><code class="hljs language-json shcb-code-table shcb-line-numbers">{
 "name": "your-monorepo-name",
 "version": "1.0.0",
 "private": true,
 "workspaces": &#91;
 "packages/*"
 ],
 "scripts": {
 "start": "your-start-script",
 "test": "your-test-script"
 }
}
</code>Code language: JSON / JSON with Comments (json)</pre>


Replace <code>"your-monorepo-name"</code>, <code>"your-start-script"</code>, and <code>"your-test-script"</code> with your actual monorepo name and scripts.



<h2 class="wp-block-heading">Define Typescript Types</h2>



Inside the <code>shared-types</code> package, define the TypeScript types you want to share. For example, create a file named <code>types.ts</code> with the following content:


<pre class="wp-block-code" aria-describedby="shcb-language-5" data-shcb-language-name="TypeScript" data-shcb-language-slug="typescript"><code class="hljs language-typescript shcb-code-table shcb-line-numbers">// packages/shared-types/src/index.ts
export interface User {
 id: string;
 username: string;
 email: string;
}
</code>Code language: TypeScript (typescript)</pre>


<h2 class="wp-block-heading">Build Shared-Types Package</h2>



Before linking the <code>shared-types</code> package to other packages, build it to ensure TypeScript types are generated. Add a build script to the <code>shared-types/package.json</code> file:


<pre class="wp-block-code" aria-describedby="shcb-language-6" data-shcb-language-name="JSON / JSON with Comments" data-shcb-language-slug="json"><code class="hljs language-json">{
 "name": "shared-types",
 "version": "1.0.0",
 "main": "dist/index.js",
 "types": "dist/index.d.ts",
 "files": &#91;
 "dist"
 ],
 "scripts": {
 "build": "tsc",
 "build:watch": "tsc --watch "
 },
 "devDependencies": {
 "typescript": "^5.3.3"
 }
}</code>Code language: JSON / JSON with Comments (json)</pre>


Run the build script:


<pre class="wp-block-code"><code class="hljs">cd packages/shared-types
yarn build</code></pre>


This will compile the TypeScript files and generate the necessary declarations. Alternatively, you can also run the build script in watch mode where it will auto-detect file changes and rebuild the package on the go:


<pre class="wp-block-code"><code class="hljs">cd packages/shared-types
yarn build:watch</code></pre>


<h2 class="wp-block-heading">Link Shared-Types Package to Web Package</h2>



Now, navigate to the <code>web</code> package and link the <code>shared-types</code> package:


<pre class="wp-block-code" aria-describedby="shcb-language-7" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><code class="hljs language-bash">cd packages/web
yarn add link:/../shared-types</code>Code language: Bash (bash)</pre>


This command establishes a symbolic link between the <code>web</code> package and the <code>shared-types</code> package, allowing the web application to access the shared types seamlessly.



<h2 class="wp-block-heading">Link Shared-Types Package to API Package</h2>



Repeat the linking process for the API package. Navigate to the <code>api</code> package and run:


<pre class="wp-block-code" aria-describedby="shcb-language-8" data-shcb-language-name="Bash" data-shcb-language-slug="bash"><code class="hljs language-bash">cd packages/api
yarn add link:/../shared-types</code>Code language: Bash (bash)</pre>


This links the <code>api</code> package to the <code>shared-types</code> package, enabling it to also leverage the shared TypeScript types. 



<h2 class="wp-block-heading">Example: Using Shared Types in Web and API Packages</h2>



Now, let&#8217;s see how you can use the <code>User</code> interface from the <code>shared-types</code> package in both the <code>web</code> and <code>api</code> packages.



In the <code>web</code> package, you can import the <code>User</code> interface like this:


<pre class="wp-block-code" aria-describedby="shcb-language-9" data-shcb-language-name="TypeScript" data-shcb-language-slug="typescript"><code class="hljs language-typescript">// packages/web/src/app.ts
import { User } from 'shared-types';

const user: User = {
 id: '123',
 username: 'john_doe',
 email: 'john.doe@example.com',
};</code>Code language: TypeScript (typescript)</pre>


Similarly, in the <code>api</code> package:


<pre class="wp-block-code" aria-describedby="shcb-language-10" data-shcb-language-name="TypeScript" data-shcb-language-slug="typescript"><code class="hljs language-typescript">// packages/api/src/controllers/userController.ts
import { User } from 'shared-types';

const getUserById = (userId: string): User =&gt; {
 // Logic to fetch user by userId
 return {
 id: userId,
 username: 'retrieved_username',
 email: 'retrieved_user@example.com',
 };
};</code>Code language: TypeScript (typescript)</pre>


<h2 class="wp-block-heading">Conclusion</h2>



Adopting a monorepo structure and leveraging Yarn workspaces for your TypeScript-based Node.js applications brings numerous benefits. 



It simplifies type sharing, fosters consistent code quality, and enhances overall project maintainability. 



With this guide, you&#8217;re well-equipped to streamline your development process. Embark on this journey towards a more organized and efficient coding experience. Happy coding!

This post guides you through using monorepos and Yarn workspaces for effective type sharing in Node.js projects. Learn to set up and link packages for consistent code quality and simplified project maintenance.

How to Share TypeScript Types Between Node.js Projects using a Monorepo and Yarn Workspaces

<h2 class="wp-block-heading">1. Create opportunities for yourself that allow you to be free from any constraints.</h2>



As a software developer, I am in a unique position to tackle problems with my own hands. It&#8217;s not uncommon for a single developer to create value for millions of people around the world.



If I end up working with a group of people that allows me to tackle a problem more effectively, that&#8217;s even better. However, I don&#8217;t need to wait to be hired by company X to solve for problem Y.



It&#8217;s my responsibility to always be on the lookout for problems to solve and create solutions for them. I have the freedom to act at any point in time wherever I may be.



<h2 class="wp-block-heading">2.Solve for problems that you understand and believe in. It&#8217;s okay to say no to everything else.</h2>



If I don&#8217;t understand or believe in the problem I am solving, I most likely won&#8217;t be able to sustain the amount of time and effort required to create effective solutions.



It&#8217;s my responsibility to ask the right questions to fully understand the root of a problem and decide from there if I can commit to being part of the solution or not.



<h2 class="wp-block-heading">3. Make an effort to take something complex and make it simple.</h2>



Ironically, it&#8217;s often more difficult to create a solution that is simple rather than complex. You have to be able to understand every level of complexity and break it down into simpler steps for everyone involved in the process.



This applies to UI/UX, software architecture, database design, and almost everything that goes into developing a solution.



<h2 class="wp-block-heading">4. Nothing is perfect. Create a baseline and improve from there.</h2>



It&#8217;s easy to hold off on putting your work out there when you think there are still a million ways you can improve it.



In reality, the majority of those improvements do not create as much value as you think they would to your users.



You must filter through the noise and focus on the essentials. Start testing your solutions by putting your work out there and getting feedback as soon as possible.



Embrace the idea of incremental improvements. Your solution will always be in a state of constant change.



<h2 class="wp-block-heading">5. Pass on your knowledge to anyone who will listen.</h2>



Coming from a family of non-technology professionals, I didn&#8217;t get exposed to the world of software as early as I would&#8217;ve hoped. While the majority of software developers started writing code during their teenage years, I didn&#8217;t write my first line of code until I was 23 and that&#8217;s okay.



Before I became a software developer, I managed to drop out of business school twice, build 2 unsuccessful businesses, go into product/project management, work for an EdTech company, and work for a digital agency.



Everything I learned along the way allows me to see both the business and technology sides of product development. It&#8217;s not society&#8217;s traditional way of learning but I wouldn&#8217;t have it any other way.



Having been through all that, it&#8217;s now my responsibility to share my experiences with people who are in the same position as me before and hopefully encourage them to pursue software development no matter what their previous life was.

A growing collection of public statements stating my views and intentions as a software developer.

I build full-stack JavaScript applications.

Latest from the blog