DEV Community: Dávid Szabó

Node.js TypeScript monorepo via NPM workspaces

Dávid Szabó — Sun, 14 Aug 2022 21:01:59 +0000

Monorepos are all the rage right now. Modern projects are all using NX to set up a monorepo. But why would you introduce such a complex tool into your tech stack when something simple is often enough?

Both Yarn and NPM include workspace management in their feature-set. Thus you can manage multiple projects in one workspace. In addition, one of the tools is always available in your project, so why not use it?

The fantastic project

You are working on a fantastic project that you happened to name fantastic. How creative, isn't it?

fantastic is a command line application that will showcase how to set up a TypeScript monorepo using NPM workspaces. The fantastic project was a massive success as a CLI application, and many users wanted to have a graphical user interface to use it. So you decided to create a web interface. Your code currently lives in a single module containing the core logic and the CLI entry-point.

Therefore you decided to separate the project into three separate packages:

core - this package contains the core logic of your fantastic project
web - provides a web interface that interacts with the core package
cli - provides a command line interface that interacts with the core package

Initialize the project

Let's create an empty directory and initialize an NPM package:

mkdir fantastic
cd fantastic
npm init -y

Now create the packages:

npm init -y --scope @fantastic -w packages/core
npm init -y --scope @fantastic -w packages/web
npm init -y --scope @fantastic -w packages/cli

Define the dependencies between the packages:

npm install @fantastic/core -w @fantastic/web
npm install @fantastic/core -w @fantastic/cli

Test it!

Now that we have the foundation in place, let's add some code to test it:

packages/core/index.js

console.log("Hello from Core!");

packages/web/index.js

require("@fantastic/core");
console.log("Hello from Web!");

packages/cli/index.js

require("@fantastic/core");
console.log("Hello from CLI!");

Running the CLI outputs the following:

node packages/cli/index.js

Hello from Core!
Hello from CLI!

This confirms that the setup is working fine.

Here comes TypeScript

Time to turn this project from JavaScript to TypeScript!

First of all, install typescript as a dev dependency in the workspace project:

npm install -D typescript

Every package requires its own tsconfig.json file. Since the fantastic project uses the same configuration for all the three packages, create a common tsconfig.base.json file in the root directory.

tsconfig.base.json

{
  "compilerOptions": {
    "incremental": true,
    "target": "es2020",
    "module": "commonjs",
    "declaration": true,
    "sourceMap": true,
    "strict": true,
    "moduleResolution": "node",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,

    "composite": true
  }
}

This is just a typical tsconfig.json file, except for one compiler option: composite. This option makes it possible for TypeScript to determine if a project has been built yet quickly.

Now you have a common TS config file, but you aren't using it yet. Create a tsconfig.json file in each package's root directory:

packages/core/tsconfig.json

{
  "extends": "../../tsconfig.base.json"
}

The cli and web package is a bit different. You need to list out all your dependencies in the references property:

packages/cli/tsconfig.json and packages/web/tsconfig.json

{
  "extends": "../../tsconfig.base.json",
  "references": [{ "path": "../core" }]
}

Now that independent packages are setup, create the tsconfig.json in the root directory:

tsconfig.json

{
  "files": [],
  "references": [
    { "path": "packages/core" },
    { "path": "packages/cli" },
    { "path": "packages/web" }
  ]
}

Empty files array tells TypeScript to ignore all files except those in the references.

Rename all your .js files to .ts and replace require with import:

require("@fantastic/core");

import "@fantastic/core";

You are ready to compile:

npx tsc --build

--build flag is required because the project contains multiple projects.

Now that you are done with all these changes, test your app again:

$ node packages/cli/index.js
Hello from Core!
Hello from CLI!

$ node packages/web/index.js
Hello from Core!
Hello from Web!

Separate source code and build output

First of all, remove all the build outputs from the previous step. The following command will delete all .js, .js.map, .d.ts and .tsbuildinfo files in the packages directory.

rm packages/**/{*.js,*.js.map,*.d.ts,*.tsbuildinfo}

Having your source code and build output in different directories is a good practice. Therefore, move each package's source code into an src directory, and change the build output directory to dist.

Extend your packages/*/tsconfig.json files with the following snippet:

  "compilerOptions": {
    "rootDir": "src",
    "outDir": "dist"
  },

As an example, this is how the packages/web/tsconfig.json looks now:

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "rootDir": "src",
    "outDir": "dist"
  },
  "references": [{ "path": "../core" }]
}

This tells TypeScript that your source code files are in the src directory, and the build output should go into the dist directory. These are relative to your tsconfig.json file.

Move your index.ts files into the respective src directory. At this point, you should have the following directory tree:

├── package-lock.json
├── package.json
├── packages
│   ├── cli
│   │   ├── package.json
│   │   ├── src
│   │   │   └── index.ts
│   │   └── tsconfig.json
│   ├── core
│   │   ├── package.json
│   │   ├── src
│   │   │   └── index.ts
│   │   └── tsconfig.json
│   └── web
│       ├── package.json
│       ├── src
│       │   └── index.ts
│       └── tsconfig.json
├── tsconfig.base.json
└── tsconfig.json

Before building your project, adjust the main property in the package.json of each package. Change index.js to dist/index.js since that's where it lives now.

Now build your project and run your CLI app:

npx tsc --build
node packages/cli/dist/index.js

You should see the usual output:

Hello from Core!
Hello from CLI!

You've done it! Good Job!

Now that you have laid the foundation for your project, go on and create something extraordinary!

The project's source code is available on GitHub. The repository contains a few little changes. Feel free to explore!

If you would like to learn more about NPM workspaces and TypeScript, check out these links:

PS. NX is an awesome tool! But sometimes, it's better to use the tools you already have at your disposal. Please take your time to decide whether to use NX or NPM / Yarn workspaces.

My feelings about Go after spending a weekend together

Dávid Szabó — Wed, 17 Feb 2021 17:36:16 +0000

David Szabo

@david_szabo97

A #weekend with #golang:
- ❤️Love it!
- 😐Syntax is meh (I grew up on C, Java, JS, PHP) Switching up the order of the variable name and type is strange at first.
- 😍😍Goroutines, channels
- 🥴Passing Context everywhere
- 😍Built-in Tooling (test runner, formatting, linting)

08:42 AM - 16 Feb 2021

TLDR;

I had a great weekend following the Learn Go with Tests online book. I spent about 15 hours going through the whole book and fire up a few practice projects.

I know it’s not a lot to come to a conclusion, but I had enough experience with other languages to find the pros and cons of the language. As we all know, the biggest and most exciting features of Go area the goroutines and channels. It’s built for concurrency and it’s so stupid simple to work with it.

Go comes with its own little problems. You need to pass Context around, down to the deepest of your call stack. At the time of this post, Go doesn’t have generics, it’s on the way though. Check out the last blog post about it on Golang blog for yourself. Don’t get excited about the syntax though…


// Print prints the elements of any slice.
// Print has a type parameter T and has a single (non-type)
// parameter s which is a slice of that type parameter.
func Print[T interface{}](s []T) {
    // same as above
}

What’s the fuss about the syntax?

I’m a JavaScript developer who switched from C, Java, C#, PHP languages in this particular order. If you ever worked with those languages – and I bet you did -, then you know the drill :


type variableName = value;

function functionName(MyType $val) {}

public static void main(String[] args) {}

You know, going left to right. Type to variable name. Then Go comes to the show and…


func SayHelloToThePeople(people []Person) (hellos []string) {}

Left to right, then right to left. Like, what in the name of Gopher is happening here?

I guess you get it now

Maybe the problem lies in me, I should’ve gone down the route of exotic languages rather than the mainstream ones.

After all, as a full-time JS developer, I’m not sure if these two languages can live together in one muscle. As you get used to writing out type variableName then suddenly switching to variableName []type really twitches my muscle memories. Practice makes perfect though.

Simplicity of Go

Did you know Go only has 25 keywords? We got 32 in C, 54 in Java, 54 in PHP, 59 in JavaScript, and 102 in C#. That’s according to a mid-2017 reddit post. God knows how many keywords now C# got… Anyway, I was lazy to look it up on my own so probably those numbers are off – according to my one minute Google research C# only got 79 keywords. You still get the point, right? Go has few keywords and they managed to stuff the magic of Go – concurrency – into those few keywords.

Let’s talk about the included batteries, in my opinion that’s still something that belongs to the simplicity section. Go comes with all the fun stuff without any external dependencies. Let’s see what we got here:

Code formatting (gofmt)
Code linting (golint)
More code static checks (go vet)
Tests (go test)
Test coverage (go test -cover, go test -coverprofile=coverprofile.out, go tool cover)
An awesome standard library

If you are just starting with Go then you probably don’t need to do anything other than just installing Go. That’s a huge plus for me. Whenever I fire up a new JS project I need to go through setting up a linter, a formatter, a test runner, and many many dependencies (depends on the project though).

I’m sure you are familiar with this

Our modern world of programming is very bloated I must say. I miss the good old days of just putting together a few PHP files and uploading them via FTP.

What’s next?

Well, Go 2 is coming and I’m thrilled but scared at the same time. Hopefully Go 2 will follow what Go 1 started.

Let’s hope this won’t happen. Source: Reddit

I’m hoping for the best regarding the future of Go. I love the current state of the language and I’ll probably continue learning it and putting together a few projects with it.

Index-naming-hell, what is it and how to avoid it

Dávid Szabó — Thu, 24 Dec 2020 22:55:00 +0000

I used to fall into the same trap…

Look at all those index files

This is how it looks like in the explorer

This works great and in practice it’s easy to use. You can just do


import MyComponent from './components/MyComponent

but when you are editing them in your editor it’s ugly and takes up too much space. It also wrecks quick file navigation since all your files are named… guess what – index.

In this case it’s fine to add some redundancy. If your component is called BirthdayItem, then feel free to rename all your files to BirthdayItem with the proper extension then create an index file that exports your component. So you don’t need to


import MyComponent from './components/MyComponent/MyComponent

Let’s see how it looks in action:

A lot better, now you can actually see what you are editing

Explorer is clean as well

As you can see both the open editors and explorer is a lot more readable. Quick file search also reacts better and easier to find what you are looking for.

Now let’s talk about Intellisense. Whenever I type BirthdayList, VS Code wants to import it from ./components/BirthdayList/BirthdayList. Before the restructure it imported it from the directory like this ./components/BirthdayList. You can clearly see that the latter is the better one. You might think about using the following code and you will get the bad result – just like me.


export { default } from "./BirthdayList";

How do we fix this? In my codebases I try to avoid export default as much as possible. So you can either do it by importing then reexporting as default, like this:


import BirthdayList from "./BirthdayList";
export default BirthdayList;

But as I said, I’d rather avoid export default at all costs:


import BirthdayList from "./BirthdayList";
export { BirthdayList };

This way you will get awesome autocompletion and auto imports without the filename.

Monster - Frontend exercise project

Dávid Szabó — Tue, 28 Apr 2020 22:07:26 +0000

Hey everyone! Recently started my own YouTube channel in Hungarian.
I've created a few videos about learning projects, but they are in Hungarian so I can't share it with the world. But... My dear friend translated the text to English so everyone can enjoy these exercises!

English version can be found here:
https://github.com/david-szabo97/dv-mini-project-monsters/blob/master/README.en.md

All the files you need to complete the project are in the repository.

(How) Do you improve your creativity/designer skills?

Dávid Szabó — Sat, 19 Jan 2019 19:20:11 +0000

Hey dev.to-ers!

I was wondering how other people overcome creativity problems as being a programmer.

I have a few sideprojects and I have no idea how to start creating a logo or user interface for them.

Recently I have been playing around in adobe illustator, putting together a few logos and web designs.... and I LOVE DOING IT!

What's a proper way to get into the graphic/design world as programmer?
Does it worth it?
How do you get graphics for your hobby projects?

Open Checklist - React (Preact)

Dávid Szabó — Sat, 25 Aug 2018 20:19:34 +0000

Hi guys,

It's late here and I'm lazy to write anything here.

I just pushed my new open source project live and I just finished making it compatible on mobile. It is meant to be used on desktop so I didn't have mobile in mind. So the UX on mobile is crap.

You can create new sections by typing ":" at the end of the task's name. For example "Goals:" will create a new section as seen on the image below.

I'm open to any suggestions, feel free to post issues on Github.

Link to web app: https://checklist.messedcode.com

david-szabo97 / open-checklist

Simple checklist (todo list) built upon Preact + Redux

Open Checklist

CLI Commands

# install dependencies
npm install

# serve with hot reload at localhost:8080
npm run dev

# build for production with minification
npm run build

# test the production build locally
npm run serve

# run tests with jest and preact-render-spy
npm run test

For detailed explanation on how things work, checkout the CLI Readme.

View on GitHub

Checklist - Animation showoff

Dávid Szabó — Sat, 04 Aug 2018 18:31:11 +0000

Soon I'll release this web app on GitHub! But first, a quick question to everyone:

Do you like the animation? :)
Imagine you are using this web app to create a to-do list or checklist. Would the animation annoy you or you like it?

Soon releasing a new open source project: Checklist

Dávid Szabó — Wed, 01 Aug 2018 13:28:26 +0000

David Szabo

@messedcode_dave

@_developit You know why I love Preact? Because it's compatible with React. And do you know why I love React? Because it has HUNDREDS of open source libs I can leverage and build things crazy fast. Soon releasing as an open source project ;)

13:25 PM - 01 Aug 2018

Keep tuned. Feel free to criticise :)

REST API - Yet Another UI

Dávid Szabó — Mon, 09 Jul 2018 09:01:13 +0000

I'm working on my new product and it's my task to develop the backend.
It's not a complicated tech stack, we are going only with a few pieces for an MVP:

MongoDB <-> Node.js <-> React Native (Android & iOS)

It's been a while since I've worked on a not small project. I'm trying to decouple the Service Layer from the "Web Service (Layer)" (REST API), and I just realized something:

REST API is just a UI

This might be a bit silly or bold statement, but if you think about it then it makes sense in my opinion. When I realized that, the tech stack changed:

MongoDB <-> Core (Node.js) <-> REST API (Node.js) <-> React Native (Android & iOS)

All of these pieces are decoupled.
I might be stupid, but this is a serious realization for me.

I just wanted to share this with you guys and would like to hear what you think.
We never stop learning and hopefully you will write something that will make me realize something very important.

Github Guesser - A Starry Game - 2 weeks of data

Dávid Szabó — Thu, 21 Jun 2018 21:09:29 +0000

Hey devs!

In my last post, I promised that I will come back with some stats about my simple game: Github Guesser.
I wanted to wait until we reach 20k plays, but seems like the game is losing interest so I would rather not wait until that! (We are at 19k by the way)

All of the stats I am showing you here are from
7 Jun 2018 - 21 Jun 2018

I have posted about Github Guesser on 3 different platforms: Twitter, Reddit and dev.to. Github Guesser is also available on GitHub so that also drove some traffic to the site. I have one post on Reddit and about 11 tweets on Twitter and one tweet which mentions it by the creator of Preact: Jason Miller (@_developit ) (Thanks a lot!). Lastly, I have two posts about it on dev.to. (This will be the third)

Total visitors: 1182, 41 stars on GitHub

Top 10 countries - most guesses

The game has been played from 85 different countries!

Here is the top 10, sorted by guesses

Country	Starts	Guesses	Corrects	Wrongs
United States	218	2417	1557	860
Brazil	104	1603	1047	556
France	118	1512	943	569
Germany	95	1343	845	498
United Kingdom	90	1127	703	424
India	63	922	584	338
Spain	50	622	394	228
Sweden	37	460	304	156
Finland	47	428	270	158
Denmark	15	424	292	132

Top 3 browsers (93.32% of total visitors)

Browser	Visitors
Chrome	843
Safari	183
Firefox	76

Top 5 operating systems (99.5% of total visitors)

Operating System	Visitors
Macintosh	380
Android	283
Windows	219
iOS	170
Linux	124

Devices

Device	Visitors
Desktop	729
Mobile	403
Tablet	50

Main sources of visitors

Source	Visitors
Direct	442
Twitter	341
dev.to	290
GitHub	95
Reddit	19

It's a really simple game: You need to guess which GitHub repository has more stars, based on the given information! Just click / touch the one you think is more popular and in a moment you will know whether you won or lost!

You can find the game here: Github Guesser
(plain link if you prefer that: https://githubguesser.messedcode.com/)

You can find the source code here:
https://github.com/david-szabo97/github-guesser

PS Have you met Static yet?
PPS You can find my blog at https://messedcode.com

Github Guesser - A Starry Game - Release #2

Dávid Szabó — Fri, 08 Jun 2018 15:20:32 +0000

Hey devs!

I am happy to announce that I've released the second version of my new pet project.

AND THE SOURCE CODE IS AVAILABLE, feel free to criticism my crap code and make this project better together!!!!! Love you guys, I am coming back with some stats soon!!!

You can find the game here: Github Guesser
(plain link if you prefer that: https://githubguesser.messedcode.com/)

You can find the source code here:
https://github.com/david-szabo97/github-guesser

I am planning a few features to be released in the next few weeks:

Login using Github so you can track your stats
Backend: Uploading stats
Backend: Pull repositories
Frontend: Show how many people won or lost the combination you just finished

GOT ANY IDEAS? Share it!!!!

PS Have you met Static yet?
PPS You can find my blog at https://messedcode.com

Github Guesser - A Starry Game

Dávid Szabó — Thu, 07 Jun 2018 07:45:33 +0000

UPDATE Release #2 is OUT!
https://dev.to/davidszabo97/github-guesser---a-starry-game---release-2-20g3

Hey devs!

I am happy to announce that I am releasing the very first version of my new pet project.

You can find the game here: Github Guesser
(plain link if you prefer that: https://githubguesser.messedcode.com/)

Soon I will release the source code too on GitHub.
The repository is already initialize if you are interested in watching or starring it: https://github.com/david-szabo97/github-guesser

I am planning a few features to be released in the next few weeks:

Login using Github so you can track your stats
Backend: Uploading stats
Backend: Pull repositories
Frontend: Show how many people won or lost the combination you just finished

GOT ANY IDEAS? Share it!!!!

PS Have you met Static yet?
PPS You can find my blog at https://messedcode.com