Forem: jeremiec

Resources to Learn Management as a Software Engineer

jeremiec — Tue, 18 Jun 2024 12:03:00 +0000

Why Learn Management as a Software Engineer?

First, you don't have to. Most companies now understand that it's critical to offer individual contributor tracks for seniors.

This post is for those who want to become better managers, even if pushed by circumstances.
To be frank, coding is pretty easy, and you can overcome most problems with time and collaboration. Sadly, managing humans is a lot more complex, and fixing errors is not a simple git push away.

In my opinion, I started managing a bit too early as I was still heavily maturing (and who still isn't), and even though I wanted to do an excellent job, I had plenty of failures.
Here are a few recommendations so you get a head start and avoid the cost of learning management on people.

Resources to Learn Management

How to Win Friends and Influence People by Dale Carnegie: Yes, I was butt-hurt when my previous CTO suggested this book to me. But once you get past the ego-triggering title, it's a nice book that can be a good reminder regarding a few things you should do: smile a lot, call people by name, etc.
Thanks for the Feedback: The Science and Art of Receiving Feedback Well by Douglas Stone and Sheila Heen: An amazing book both for receiving feedback, a gift for progression. As a leader, you need to show that you are open to feedback and that you take it well. Obviously important in giving feedback and teaching people to use it as a tool for progression.
Engineering Management for the Rest of Us by Sarah Drasner: A great to-the-point book about what engineering management entails, what's your role, etc. https://www.engmanagement.dev/
Trillion Dollar Coach: The Leadership Handbook of Silicon Valley's Bill Campbell by Eric Schmidt, Jonathan Rosenberg, and Alan Eagle: An interesting book about what being a coach means and how to be great at it.

I highly recommend learning about negotiation as well. The best book I found regarding this subject is:

Never Split the Difference: Negotiating as if Your Life Depended on It by Chris Voss and Tahl Raz: An exceptional book about negotiation, not as a taboo technique or some secret skill but more as an everyday activity you always use.

I used to recommend Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher, William L. Ury, and Bruce Patton, but I find it to be less applicable in real interaction, even if some notions are really interesting, like having a no-deal fallback (maybe you don't want to negotiate).

If you have any recommendation, please do comment them below or contact me on twitter.

Cover image by Shiromani Kant.

A tale about migrating a 200 entries Gatsby blog untouched for 3 years to Astro

jeremiec — Sun, 16 Jun 2024 12:19:00 +0000

A little context about the tech blog and the migration

I was working at Theodo, a high-end service company. As part of our diverse missions, we would often have to solve some interesting business challenges using interesting technical solutions.
To share those learnings with the world, we have a technical blog at https://blog.theodo.com/.

Over the years, the blog was migrated from WordPress to Gatsby for blazing fast performance and nice features. Blazing being about a medium 60 lighthouse score for a mostly static site, not very blazing. Sadly, when writing new articles, a slightly annoying 5 minutes boot time was required before any change could be shown. It was about 2 years after we started using Vitejs in production for most SPA clients, and the slowness was terrible.

A nice workaround was to only load the last given month of articles, to reduce Gatsby's internal query resolution in development, allowing a reasonable boot time.

More reasons to quit Gatsby

After a few articles on the blog, I was curious. Could I improve the developer experience while keeping the user experience at least at the same level? I wanted to dive into our Gatsby blog internals to find if I could improve query resolution and dev server boot time. Sadly, after learning about Gatsby and its abstraction of using a GraphQL layer to aggregate all data from any data source, I was at a loss. GraphQL can be great in some cases, like using Relay to send only one request on a client to load a full page worth of data. GraphQL as an abstraction layer to query data over markdown files, not as great. Looking at those queries, it felt like seeing an ant being squashed by a steamroller.

Another aspect of the long build time was our continuous deployment pipeline: the site was deployed on Cloudflare Pages, and the build time was often big enough to encounter timeouts.

Gatsby itself seemed less and less maintained, with very little activity on the main repository.

Lastly, for a blog consisting mainly of text and images, we were shipping the full power of React.js. Quite overkill to toggle a search bar.

Reasons to consider Astro

Astro, on the other hand, had excellent press. Beginning with pristine documentation, including a migrate from Gatsby entry. From a few experiments on other projects, it was quite a solid framework with a great developer experience. Importantly, there was little glass ceiling in terms of framework features: we get to keep React.js and JSX.

An incredibly simpler model regarding markdown files as blog post entry collections with built-in validation of frontmatter, excellent typing, etc.

Built on top of Vite, meaning a faster boot time in development (spoiler: about 20s for 200 entries with no optimizations), meaning fast hot module replacement.

A golden path regarding performance, with the island architecture, meaning no client-side JavaScript for static content.

The migration from Gatsby to Astro

Migrating from StyledComponents to Tailwind

First of all, as the codebase was quite old and as I didn't want to bring more tech than what was required, I started to migrate my few React components on Gatsby from StyledComponent (a great CSS-in-JS solution) to Tailwind CSS. Mostly because I wanted to see if I could measure the impact of moving from CSS-in-JS to pure CSS. The second goal was to allow Astro to run without client-side JS. To do so, I either needed to set up StyledComponent in Astro or migrate to Tailwind. Tailwind is documented and largely used on most projects now, and I was curious about the performance impact.

The migration was actually easier than anticipated. Mostly done in the span of a few days, I had the privilege of allowing myself breaking changes on some design (like using Tailwind prose for blog posts).

One last "find the 7 errors game" later, the migration was live.

For curiosity's sake, I measured the performance of some pages. The verdict was both surprising and anticlimactic. For such simple pages, there was absolutely no difference performance-wise. User experience-wise, I used the opportunity to fix a few flashes of incorrectly styled content (think JS responsive), meaning a slight improvement unrelated to Tailwind.

My biggest known dependency was solved, it was time to write some Astro!

Creating an Astro shell

After a quick setup using Astro create-app and adding React and Tailwind dependencies, it was time to recreate the shell pages. I copied 2 posts and got to work on the main homepage, which is just a basic post listing page. Let's go!

Alright, I copied over my React component pages, commenting Gatsby GraphQL page queries to convert them into Astro content collection syntax... And it's already screaming at me "this blog post has no author"! Quick check: did I forget to copy an author? No, it's indeed missing and not accounted for in Gatsby. Thanks to TypeScript and Astro strict typing, 5 minutes in, I already know of an unaccounted-for edge case.

After working out how to fetch my posts and display them on my homepage, to match the current blog features, I needed some more grunt work. I needed to create post excerpts.

Alright, to do so, I simply needed to render the post and take the first K words of the content. Some sanitizing later and it's done.

I have a few more pages to write: posts by author, by category.

And it's quite simple to write as well: it's just a JS .filter() on a list after all. Astro even documents the use case or better yet, creating filters with an arbitrary list of tags and paginating those.

Okay, just need to create an RSS feed, there is an Astro integration so it's quite trivial.

Migrating data

Okay, so I have a nice blog with 2 posts. I had to adapt those posts a bit to be rendered correctly (edit image path to be relative and not just image slug, think ./my_image.png vs my_image.png which isn't shocking).

And that's where shit hit the fan. Astro (in TypeScript strict mode) is so incredibly much stricter than Gatsby. It's an incredible pain to migrate those files, there are over 200 blog posts and if image names can be automated easily (basic glob + regex stuff), some changes need to be dealt with by hand.

A ton of posts are simply referencing missing images. A quick check on the live blog allows me to verify how Gatsby deals with it. It's simply a broken image, not the best default. Having a "missing image error" blocking the build is a pain when you are migrating all those posts but so incredibly useful to avoid making a typo mistake when contributing.

Some posts are nearly completely opting out of markdown and using a ton of HTML markup to create custom layouts. With Astro, those could just have used MDX, but I'm faced with a migration issue. I need to keep those posts looking similar, but the rework is quite tedious as MDX is quite a strict flavor of markdown. I highly recommend using the VSCode MDX extension which helps quite a bit in detecting broken syntax.

My recommendation is to do those changes using a script. When you have 200+ posts to change, doing this by hand is tedious and error-prone. If a new post is published, you need to import it as well. It's a bit longer to set up first but having a script that does every modification you need directly allows you to check your data migration and play it easily on the latest posts when releasing the migration.

Post data migration nice to have

After migrating the data, I still needed to address a few features that I didn't implement yet:

Search: Using our old search was not possible nor wanted and I found a great static page search in Pagefind. There is even a simple Astro integration to avoid boilerplate code. The search is both faster than before, accessible through the shortcut / and has a nice excerpt as well as a picture for each result. Nice win!
By default, there is no React.js on the client, see results for the impact, but it's clearly a better golden path for static sites. I even chose to only keep JSX as Astro components to opt-in to a very light Alpine.js client-side library for light interactivity like the search/header.
I also needed to keep the infinite scroll on the homepage, authors, and categories pages which allow for scrolling all 200 posts as paginated pages of about 10 posts. To do so, I used partial HTML render routes that I render at build time with Astro (like any other page) and used HTMX to fetch pages on scroll. You can try it by scrolling on the blog homepage to see requests going out when scrolling to load the next page and inject it into the current document.

Result of migrating from Gatsby to Astro

My goal with this migration was to:

✅ Simplify features contribution to the blog: Using basic JS/JSX helps in driving down complexity, TypeScript helps in avoiding edge cases.
✅ At least keep the user experience on par: The blog performance on Lighthouse increased from 69 to a comfortable 99 (migration to Astro + using Partytown for analytics) and a few features/ugly content flash were added/fixed.
✅ Improve developer experience when contributing articles: All posts are rendered in development, page live update is a lot faster on content change, TypeScript helps with typos to avoid missing images.

What I'm less proud of and might have been too much of an experiment:

Using Alpine.js/HTMX:❓ Both are quite simple tools but especially HTMX requires thinking a bit differently about how to update frontend UI. This might make the contribution a bit harder. However, it needs to be weighed against the amount of logic that would have been a React.js hook + component to create such an infinite scrolling with the corresponding REST API routes.

How to generate Typescript interfaces from your Spring Boot backend

jeremiec — Tue, 09 Apr 2024 12:02:00 +0000

Starting a full stack project with Spring Boot and a modern frontend framework like React in Typescript, you rapidly fall into the issue of defining your interfaces twice:

Once on Spring Boot side where you create your response/request DTO for your controllers,
and again on the frontend where you have to write those interfaces again in Typescript this time.

Not only is this poor developer experience, leading to a loss in productivity, it simply leads to bugs as you can easily forget to upload your interfaces on one side.

Great news! Avoiding this pitfall is actually possible and easy ?! with a quick setup, which is the topic of the following guide, let's go!

How can we generate Typescript interfaces from our Spring Boot backend

Advancement in code generation and support of standards like Swagger/Open API to describe REST APIs allow for effective code generation. Meaning we only need to set up a proper Swagger on our backend api in Spring Boot to benefit from interface generation for all our interfaces.

In practice

We will need to expose a Swagger on Spring Boot application and then to configure our code generation tool to target it.

Setting up SpringDoc

To generate our Swagger we will use SpringDoc as SpringFox is outdated and less maintained. (You can even relatively easily migrate from SpringFox to SpringDoc)

Setting up SpringDoc with Maven is classic, get the latest version, add it to your pom:

<!-- Swagger -->
    <dependency>
      <groupId>org.springdoc</groupId>
      <artifactId>springdoc-openapi-ui</artifactId>
      <version>1.6.9</version>
    </dependency>

If you are using some sort of authentication, you will need to allow unauthenticated access to the Swagger, eg:

// ... rest of your auth
 @Override
  public void configure(WebSecurity web) throws Exception {
    // Allow Swagger to be accessed without authentication
    web
      .ignoring()
      .antMatchers("/api-docs")
      .antMatchers("/api-docs/swagger-config")
      .antMatchers("/swagger-ui.html")
      .antMatchers("/swagger-ui/**");

Which you can limit to dev environment if you are not comfortable allowing your backend users to discover your API endpoints using Swagger, to do so use profiles/environment variables as you can easily disable SpringDoc.

Now start or restart your Spring Boot application, you should be able to get your Swagger (JSON) on http://server:port/context-path/v3/api-docs, for the application created for this guide it's: http://localhost:8080/guide/v3/api-docs.

One additional step is to configure your Swagger to regroup enums usage definition (meaning when you use an enum in two DTO you will expose only one enum definition in Swagger instead of duplicating the definition):

@Configuration
public class OpenApiConfig {
  static {
    // use Reusable Enums for Swagger generation:
    // see https://springdoc.org/#how-can-i-apply-enumasref-true-to-all-enums
    io.swagger.v3.core.jackson.ModelResolver.enumsAsRef = true;
  }

  // ... you can also describe your api bellow
  @Bean
  public OpenAPI openAPI() {
    return new OpenAPI()
      .info(
        new Info()
          .title("My shiny API")
          .description("My shiny API description")
          .version("v0.0.1")
      )
      .externalDocs(
        new ExternalDocumentation()
          .description("Documentation")
          .url("https://my.shiny.api.doc/")
          // can simply be a link to a README
      );
  }

This setup is enough for code generation, however I recommend to dive deeper into SpringDoc, it also offers you an UI http://server:port/context-path/swagger-ui.html which can be an excellent way to document your api for your clients.

Setting up Orval

Orval is a recent code generator that propose code generation up to API client generation with the tool of your choice: fetch, Axios, React Query, SWR. For this guide, I will cover interface generation only, however if you are starting a project, I highly recommend setting up client generation as well.

First install Orval as a dev dependency on your project:

npm install orval --save-dev

then create an orval.config.ts file in your frontend:

import { defineConfig } from "orval";

export default defineConfig({
  evo: {
    output: {
      mode: "tags",
      schemas: "model/api",
      mock: false, // enable/disable test mock generation
      // I recommend enabling this option if you generate an api client
      prettier: true, // recommended if you use prettier
      clean: true, // recreate the whole folder (avoid outdated files)
    },
    input: {
      // use your own Swagger url: http://server:port/context-path/v3/api-docs
      target: "http://localhost:8080/guide/v3/api-docs",
    },
  },
});

Once your backend is running, you can generate your interface running npx orval --config ./orval.config.ts.

I recommend setting up a script in package.json:

{
  ...
  "scripts": {
    ...
    "gen:types": "orval --config ./orval.config.ts"
  }
}

That's it! Now you only need to launch this command to update your frontend interface when you modify your backend, no more duplication 🎉

Going further

You can go a bit further as mentioned in passing in this guide:

SpringDoc provides a great UI to self document your API, and you can customize the Swagger generated for your clients,
Orval has many features including client generation, creating mock for your API, I highly recommend looking into it,
the next step would be to automate client side type generation in CI to test that every pull request has up to date types.

How to beautify java code reliably

jeremiec — Wed, 07 Feb 2024 13:50:00 +0000

I recently had to set up code formatting on a spring boot java application. Auto code formatting is important to avoiding useless diffs in source files, reducing noise in code review, allowing reviewers to focus on what matters.

Ideally we want:

Automatic formatting on file save in IDE's (vscode, IntelliJ)
Capacity to run in CI

I wanted to integrate well with vscode and after trying some solution like:

java autoformat, which I couldn't run in CI and that was not really portable between IDEs
maven auto formatting plugin (didn't run on save easily in IDEs)

I ended up, from a friend suggestion, looking into a java prettier plugin. Prettier allowed for an easy integration with most Web IDE, can be configured to format on save for vscode and is trivial to run in CI.

Installing prettier for java

Let's start with the setup in command line:

Install nodejs: (I highly recommend using a node version manager like fnm) and to install a recent node version (current long term support is 16+)
Add a package.json file at the root of your project and add prettier and the java plugin:

{
  "name": "api",
  "version": "0.0.1",
  "private": true,
  "devDependencies": {
    "prettier": "2.5.1",
    "prettier-plugin-java": "1.6.1"
  },
  "engines": {
    "node": "16.x"
  },
  "scripts": {
    "format": "prettier --write \"{,**/}*.{java,yml,yaml,md,json}\"",
    "check-format": "prettier --check \"{,**/}*.{java,yml,yaml,md,json}\"",
    "lint": "npm run check-format"
  }
}

Install the required node_module: npm install

💡 Don't forget to add node_modules to your .gitignore.

💡 I highly recommend adding a .prettierignore that list autogenerated files to avoid formatting those, eg:

node_modules
target

You can now format java code running npm run format 🚀

💡 Do not forget to add node as a dependency for your project installation and to run npm ci in your project installation script for new developers.

We now want to improve developer experience by integrating with IDEs, running the formatter in CLI being impractical.

Monorepo

If you are using a monorepo, I highly recommend setting up prettier in the root of your monorepo instead of setting up prettier in each sub directory.

Integrating with IDEs

vscode

To set up prettier in vscode: add the prettier for java extension to recommended vscode extensions for the project, to do so, you can simply add the id of the extension to: .vscode/extensions.json:

{
  "recommendations": [
    "pivotal.vscode-boot-dev-pack",
    "vscjava.vscode-java-pack",
    "redhat.vscode-xml",
    "sonarsource.sonarlint-vscode",
    "gabrielbb.vscode-lombok",
    "dbaeumer.vscode-eslint",
+   "esbenp.prettier-vscode", // the classic prettier extension
    "shengchen.vscode-checkstyle",
  ]
}

then set up this extension as the default linter for java file in .vscode/settings.json :

{
// rest of your configuration
// automatic format on save, I recommend the save on focus lost option as well
+   "editor.formatOnSave": true,
+   "[java]": {
+       "editor.defaultFormatter": "esbenp.prettier-vscode"
+   }
}

Already we can easily format java code on save:

I highly recommend checking in the .vscode folder in your versioning tool (most likely git) to share this configuration with all developers.

IntelliJ

To integrate with prettier java formatter:

First install the File Watchers IntelliJ plugin
Then configure the plugin Tools/File Watchers:

Name: Prettier-java
File type: Java
Program:  full path to `.bin/prettier` eg: `node_modules/.bin/prettier`
Arguments: --write $FilePathRelativeToProjectRoot$
Output paths to refresh: $FilePathRelativeToProjectRoot
Auto-save edited files to trigger the watcher: check it
Trigger the watcher on external changes: check it

prettier documentation can be found here for IntelliJ integration

Integrate code formatting check in CI

Now we only need to integrate this check in CI, I'm using gitlab for this example, but the principles can be transposed to any other CI.

First we need to add a new job:

stages:
  - build
  - test
  - deploy

# ... rest of the file

# beautify backend files with prettier
lint-back:
  image: node:lts-alpine # We use a node image to run prettier
  stage: test # must match an existing stage
  needs: [] # none required optimization that explain to gitlab ci that this test has no dependency and can start as soon as possible
  script:
    - npm ci
    - npm run lint
# ... rest of the file

now just push your change, and you are all set:

Whisper to your keyboard: Setting up a speech-to-text button

jeremiec — Tue, 06 Feb 2024 13:58:00 +0000

Long story short: I broke my arm while riding my bike and I can't type. Quite the problem as typing is a key part of my daily life as a software engineer. So I decided to add a speech to text button to my keyboard. Here's how I did it.

How to transcript speech to text on linux

First, I looked into how to transcript speech to text on linux. I found a few solutions:

Whisper.cpp: a way to run the OpenAI whisper model locally
OpenAI's API: the original Whisper model as a pay as you go API
Deepgram: a pay as you go service that offers a speech to text API

After testing whisper.cpp on my machine, it was too slow and inaccurate (out of the box), so I decided to use an API and abandoned the idea of running it locally (for now).

So I registered for an OpenAI account and tried their API:

(you can download an example recording here)

FILEPATH="./recording" # path to the recording without extension

curl --request POST \
  --url https://api.openai.com/v1/audio/transcriptions \
  --header "Authorization: Bearer $OPEN_AI_TOKEN" \
  --header 'Content-Type: multipart/form-data' \
  --form file="@$FILEPATH.wav" \
  --form model=whisper-1 \
  --form response_format=text \
  -o "${FILEPATH}.txt"

It's quite magical, already I could transcript my voice to text.

How to record your microphone on linux

This one was a challenge for compatibility and device selection, but basically, what you want to do is record your microphone as a .wav file and save it. (I could not make mp3 encoding work reliably and it was not required)

First use arecord to list your available devices:

arecord -l

Then you should be able to test which input device is your microphone by recording a few samples:

FILEPATH="./recording"
AUDIO_INPUT="hw:0,0" # your microphone device, test with a few devices to find the right one
arecord --device="$AUDIO_INPUT" --format cd "$FILEPATH.wav" --duration=10

How to write the text file emulating a keyboard

This one is quite easy, I used xdotool to emulate a keyboard and write the text file:

FILEPATH="./recording"
perl -pi -e 'chomp if eof' "$FILEPATH.txt" # remove trailing newline if any to avoid sending an extra newline keypress
xdotool type --clearmodifiers --file "$FILEPATH.txt"

Putting it all together: a button to transcript speech to text

Now that we have all the pieces, we can put it all together in a script:

#!/usr/bin/env bash
# usage: exec ./voice-typing.sh twice to start and stop recording
# Dependencies: curl, jq, arecord, xdotool, killall

set -euo pipefail
IFS=$'\n\t'

# Configuration
readonly PID_FILE="${HOME}/.recordpid"
readonly FILE="${HOME}/.voice-type/recording"
readonly MAX_DURATION=15
readonly AUDIO_INPUT='hw:0,0' # Use `arecord -l` to list available devices

start_recording() {
  mkdir -p "$(dirname "$FILE")"
  echo "Starting new recording..."
  nohup arecord --device="$AUDIO_INPUT" --format cd "$FILE.wav" --duration="$MAX_DURATION" &>/dev/null &
  echo $! >"$PID_FILE"
}

stop_recording() {
  echo "Stopping recording..."
  if [ -s "$PID_FILE" ]; then
    local pid
    pid=$(<"$PID_FILE")
    kill "$pid" && wait "$pid" 2>/dev/null || killall -w arecord
    rm -f "$PID_FILE"
    return 0
  fi
  echo "No recording process found."

}

write_transcript() {
  perl -pi -e 'chomp if eof' "$FILE.txt"
  xdotool type --clearmodifiers --file "$FILE.txt"
}

transcribe_with_openai() {
  curl --silent --fail --request POST \
    --url https://api.openai.com/v1/audio/transcriptions \
    --header "Authorization: Bearer $OPEN_AI_TOKEN" \
    --header 'Content-Type: multipart/form-data' \
    --form file="@$FILE.wav" \
    --form model=whisper-1 \
    --form response_format=text \
    -o "${FILE}.txt"
}

main() {
  if [[ -f "$PID_FILE" ]]; then
    stop_recording
    transcribe_with_openai
    write_transcript
  else
    start_recording
  fi
}

main

The script needs to be run twice to start and stop recording. It will then transcript the recording and write the text to the current window.

To trigger it with a button, simply add a keyboard shortcut to run the script in your keyboard configurations settings on your linux distribution.

Conclusion and next steps

It was a fun little project to do, and it's quite useful to be able to type with your voice. I'm not sure I'll keep using it after my arm heals, but it's a nice option to have.

Since using whisper was a little slow, I tried and switched to Deepgram for faster (and sometimes more accurate) transcriptions. I published the complete script on github, you can find it here, it checks for requirements and handles errors a little more gracefully.

Effective nodejs version management for the busy developer

jeremiec — Sun, 04 Feb 2024 12:56:50 +0000

I highly recommend setting up nodejs with a version manager, nvm was and still is a popular option, however, I now recommend and have been using fnm, a simpler and faster alternative to manage my nodejs versions.

Install a nodejs version manager: FNM with automatic version switching

To install fnm, follow the installation steps.

I highly recommend installing the autocompletion, if using zshrc, add this in your ~/.zshrc:

# if fnm is installed, add to path and load autocomplete
if [ -d ~/.fnm ]; then
  path+=~/.fnm
  # setup env and allow for automatic node version change when directories contains `.node-version` or `.nvmrc`
  eval "$(fnm env --shell=zsh --use-on-cd)"
  # shell completion
  source <(fnm completions --shell zsh) > /dev/null 2>&1
  compdef _fnm fnm
fi

Restart your shell to take those changes into account: exec $SHELL -l

Use a nodejs version

Then you can easily install and switch node versions:

node -v
# install a version
fnm install lts/iron
# switch to version
fnm use lts/iron
# you can switch to a set version by number as well (eg. v20.9.0)
node -v

Project setup to promote the correct nodejs version

When using node in a project, I recommend:

Setting up a .nvmrc file at the root of your project to declare the used nodejs version:

lts/iron

Using the same version in your runtime, CI, for example with docker:

FROM node:iron-alpine

In your project package.json, I recommend using the engines field to declare the nodejs version:

{
    "engines": {
        "node": ">=20",
        "pnpm": ">=8"
    }
}

as well as using engine-strict in your .npmrc file:

engine-strict=true

Another option is using a preinstall hook for pnpm.

Bonus using pnpm as a package manager

I also recommend using pnpm as a package manager, it's faster and more efficient than npm or yarn with great capabilities concerning monorepo setup. On recent nodejs versions (v16.13+), you can install it easily with:

corepack enable && corepack prepare pnpm@latest --activate

use engines to enforce usage of pnpm or a preinstall hook:

{
    "engines": {
        "pnpm": ">=8"
    }
}

{
  scripts: {
    "preinstall": "npx only-allow pnpm",
  }
}