DEV Community: Yassin Eldeeb 🦀

The Dark Side of Grinding: Burnout, Balance, and Identity

Yassin Eldeeb 🦀 — Mon, 24 Mar 2025 04:12:13 +0000

🧠 What is happiness, really?

Ask different people, get different answers.
For some, it’s building. For others, it’s connection.
For many, it’s a quiet feeling of peace that sneaks up on you between chaotic moments.

But underneath it all, our emotions are deeply biological.

Happiness, fulfillment, motivation — they’re not random. They’re chemical.

We feel it through a balance of four key brain chemicals:

Dopamine: the buzz of chasing goals and progress
Serotonin: grounded peace, confidence, self-worth
Oxytocin: emotional connection, closeness, trust
Endorphins: physical joy, stress relief, laughter

“When all four are in sync, we feel unstoppable. But when one takes over — like the dopamine from grinding or the oxytocin from social validation— everything goes off-balance.”

This is the story of how I’ve felt each of those states at the extreme — and what it taught me about building a life that actually works.

💨 Phase 1: The Rebel Dopamine Spike

During school years, I felt most alive doing all the wrong things.

Skipping school. Stealing money from parents. Smoking. Hanging out with the worst influences.

We were wild — and it felt amazing.

Adrenaline. Dopamine. Brotherhood.The bond with those friends? That was oxytocin, in a weird way.

It was all toxic, sure — but in the moment, it made me feel seen. Alive. Important. And that’s what every kid wants.

Until I got caught.
And everything collapsed.

💻 Phase 2: The Lone Builder Era

The crash triggered a transformation — but not a graceful one.

My world kind of collapsed.

Parents were disappointed. I was pulled out of school, forced into homeschooling to keep me away from bad influences.

And I felt… lost. Alone. Ashamed. Like I had no one.

So I turned inward — toward tech.

Not because I wanted to get rich or build cool things — but because I needed something, anything, that could make me feel okay again.

“Coding became my escape. My new drug. My identity.”

I cut off everyone. I didn’t just lose toxic friends — I disconnected from everyone. No school. No social life. Just me, my laptop, and the grind.

And I went all in.

I got my first dev job very early soon after 2yrs of self learning to code. Then another. And another. And another… I climbed fast. I:

Built front-ends for major U.S. homeschooling platforms
Joined many hackathons solving real-world issues like police accountability in Chicago
Developed trading tools for one of the largest financial firms
Contributed to some of the most prominent open-source projects
Spoke at international conferences online and in-person
etc…

From the outside, I looked unstoppable.

But inside? I was emotionally empty.

I was living off purely on dopamine — the thrill of building, shipping, winning. But I had no calm, no connection, no physical vitality. Just fast food, code, and screen time.

“I didn’t enjoy my life where I was — not because of the work, but because the people around me didn’t share my energy, my goals, or my mindset. I felt like a stranger in my own world.”

I wasn’t sad. I wasn’t happy either. I was just… functional.

And that’s sometimes the most dangerous place to be — because it convinces you to stay stuck.

🌅 Phase 3: Rebirth in Europe

Then, I moved to Europe.

And everything — everything — changed.

After years of isolation, self-imposed pressure, and emotional numbness… I stepped into a new environment, and it felt like I could finally breathe.
For the first time in my life:

I had sunlight on my skin daily
I had real, human connection
I was surrounded by a different vibe — people who were alive, expressive, present

And I started rebuilding myself from the ground up.

I joined a boxing gym.
Started lifting weights. I dropped 25kg of fat.

I went from extremely overweight to fit, strong, confident.

I completely cut out fast food. Cleaned up my diet.
Started fueling and training my body like an athlete.

I built up my experience with dating, flirting, romance, and intimacy — stuff I never had space for in the grind years.

I learned what it means to give pleasure, to connect deeply, to be desired — and to desire back, with confidence.

I trained my social skills like I trained my muscles: with intention, patience, and reps.

And slowly… I began to love being in my own skin.

I started having fun again. Laughing. Meeting people. Building friendships that weren’t just social — they were soul-aligned.

For the first time, happiness didn’t come from proving myself — it came from being myself.
And chemically? My system was finally in harmony:

Serotonin from sunlight, fitness, and daily movement
Oxytocin from real friendships and emotional connection
Endorphins from training and sweating and pushing my body
Dopamine still there — but no longer running the show

“It wasn’t a grind anymore. It was alignment.”

😵‍💫 But Here’s Where It Gets Complicated…

For the past 9 months… Coding has been the least of my priorities. And I’ve felt good. Really good.

But also… really guilty.

Because I used to love building. I used to wake up excited to create.

Now, the thought of coding for hours feels… draining.

Like something I’ve outgrown, even though it once defined me.

Which is crazy — because I’m full of insane ideas to build.

And I’ve never been sharper — mentally, physically, emotionally.

But I feel rusty. Hesitant. Unmotivated.

And maybe… I’m scared.

“Scared that falling back in love with coding will cost me the life I fought to build. Scared that productivity will once again become a prison.”

🔭Here’s What I’ve Learned

“You haven’t lost your passion. You’ve just outgrown the reason you used to work.”

I used to build to survive. To feel seen. To escape. To prove something.

Now, I want to create from joy, not fear.

From expression, not validation.

I want to build something that fits the life I’ve designed — not replaces it.
Because one thing I know for sure:

Whatever I pour my mind and soul into…I master.

Tech.

Boxing.

Nutrition.

Social life.

Romance.

Even rebuilding my own body from scratch.

So the mission now isn’t to pick one.

It’s to build a life where all of me gets to exist — in balance.

💡 The Line That Changed Everything

"Build your social life around your mission - not as an escape from it."

When I first read that… I froze.
Because it hit too close.
I realized I had spent the past few months doing the opposite.
Surrounding myself with good people - but not mission-aligned ones.
Going out. Hanging out. Socializing… but drifting.
And here's the truth:
When your social life isn't aligned with your purpose, it starts to erode it. Slowly. Silently.

🏡 Environment Shapes Everything

“You don’t rise to the level of your goals — you fall to the level of your environment.”

Lately, I’ve been living in Aveiro — a small, slow city in Portugal.

Peaceful? Yes.
But uninspiring.
Surrounded by retired people… and young people with no ambition.

And when you’re around people with no fire,your flame dims too.

I started to feel retired. Lazy. Unmotivated.

Like I was waiting for life to happen again.

And that’s when it hit me:

“Where you live isn’t just a location — it’s an operating system. It rewires your habits, your energy, your identity.”

🥊 A New Chapter — Not a Reset, a Merge

I’m moving again…this time to the capital — Lisbon.

Not to run away — but to realign.

Because I don’t need to become someone new.

I just need to create space for all the versions of me to coexist:

The builder
The competitive boxer
The romantic
The social connector
The ambitious grinder
The calm, grounded one

“You don’t have to choose between the driven you, the social you, or the peaceful you. You’re allowed to build a life where all of them belong."

This next move isn’t about escape — it’s about integration.

A lifestyle designed to hold the balance I’ve earned.

A co-working space full of creatives and builders at the heart of the capital
A boxing gym where I can keep pushing myself for competing
A neighborhood where energy is alive
Routines that support clarity, movement, and stillness
People who share momentum, not just moments

“If you’re not happy where you are — move!! You’re not a f*cking tree.”

💥 If You’re In That In-Between Place Too…

Then hear this:

If your fire is fading… maybe your fuel needs to change.
If your environment feels off… it’s okay to outgrow it.
If you’re split between versions of yourself — don’t choose. Build the container that holds them all.

For me, it took stepping out of Europe — back to the place where my grind began — to finally connect the dots. I saw the driven, isolated version of me… and the free, expressive, connected version I’d become. And I realized: I need both.

Before that, I thought Europe-me was the answer. But it turns out, neither version is complete on its own.

Balance doesn’t mean mediocrity. It means creating space where your ambition and your aliveness don’t have to compete — they can coexist.

So, I went down the rabbit hole of buying GitHub Stars, so you won't have to 😄

Yassin Eldeeb 🦀 — Thu, 01 Jun 2023 14:09:35 +0000

Checkout my blog post

https://the-guild.dev/blog/judging-open-source-by-github-stars

Deadliner

Yassin Eldeeb 🦀 — Mon, 04 Apr 2022 19:40:07 +0000

🎉🥳Announcing Deadliner

Manage your deadline gently by updating the wallpaper of your desktop with the time left.

🗓️Set deadline
🖼️Update wallpaper dynamically
🤗Less annoying way for reminding you
🎨Full Customization
👨‍👦‍👦Cross Platform
⚡🦀 Efficient

Learn more:

YouTube Video

Landing page

Source Code

Mutex in Rust can be tricky sometimes...

Yassin Eldeeb 🦀 — Mon, 21 Feb 2022 21:50:16 +0000

Can you guess why snippet 1 is outperforming by 400% than snippet 2 🤯

So, this is a thread pool implementation for a simple HTTP server using an mpsc channel to add incoming requests' handlers to a queue then threads can receive the sent closures (request handlers) and execute them in parallel.

Snippet 1:

type Job = Box<dyn FnOnce() + Send + 'static>;

struct Worker {
    id: usize,
    thread: JoinHandle<()>,
}

impl Worker {
    fn new(id: usize, receiver: Arc<Mutex<Receiver<Job>>>) -> Worker {
        let thread = thread::spawn(move || loop {
            // here 👇
            let job = receiver.lock().unwrap().recv().unwrap();
            // here 👆
            println!("executing on thread: {}", id);

            job();
        });

        Worker { id, thread }
    }
}

Snippet 2:

type Job = Box<dyn FnOnce() + Send + 'static>;

struct Worker {
    id: usize,
    thread: JoinHandle<()>,
}

impl Worker {
    fn new(id: usize, receiver: Arc<Mutex<Receiver<Job>>>) -> Worker {
        let thread = thread::spawn(move || loop {
            // here 👇
            let lock = receiver.lock().unwrap();
            let job = lock.recv().unwrap();
            // here 👆
            println!("executing on thread: {}", id);

            job();
        });

        Worker { id, thread }
    }
}

Benchmarks

Tested using Artillery on a CPU that has 16 logical processors and checked the graphs to confirm that all threads are indeed running in parallel and not concurrently.

Look at the spikes 👇

Snippet 1:

Snippet 2:

Really? a single line can make that difference? aren't they the same though 🤔

Let's discuss a few things first to understand where is the problem 👨‍🏫

mpsc from its name is "multiple producers, single consumer", in this case, we want a single producer(main thread) to add requests' handlers to the queue and we want multiple consumers so that multiple threads can consume messages in parallel.

So to achieve our goal we wrapped the receiver we got from mpsc in an Arc which gives us multiple ownership for the receiver to pass to the different threads to work with and to make it that only one thread is responsible for executing a handler we used Mutex which allows only one thread to access the receiver at any given time, because we don't want two threads to respond for a given request.

To access the data in a mutex, a thread must first signal that it wants access by asking to acquire the mutex’s lock. This lock keeps track of who currently has exclusive access to the data and the lock is released when the MutexGuard is dropped.

Notice in snippet 1:

// -------⬇⬇⬇⬇Temporary Value⬇⬇⬇⬇
let job = receiver.lock().unwrap().recv().unwrap();

✨the trick here is: using let, any temporary values used in the expression on the right-hand side of the equals sign are immediately dropped when the let statement ends!

So that means that the lock is released before the thread even starts executing the handler, which means that other threads can acquire the lock to receive incoming requests' handlers to process them 💪

As you see here we're running 16 threads in parallel which is freaking awesome!

executing on thread: 0
executing on thread: 1
executing on thread: 2
executing on thread: 5
executing on thread: 4
executing on thread: 3
executing on thread: 10
executing on thread: 7
executing on thread: 13
executing on thread: 9
executing on thread: 6
executing on thread: 11
executing on thread: 12

On the other hand with snippet 2:

    let thread = thread::spawn(move || loop {
       let acquired_lock= receiver.lock().unwrap();
       let job = acquired_lock.recv().unwrap();

       println!("executing on thread: {}", id);

       job();
    } // `acquired_lock` is dropped here and lock is released.
 );

the lock is released after the execution of the handler, specifically at the end of the scope where It was defined.

Therefore the threads, in this case, are running concurrently and not in parallel, cause each thread has to wait for the other thread who acquired the lock to release it so that it can read the sent closures from the receiver.

And actually the current lock acquirer probably will pick it up again faster than other threads cause it's like:

acquire lock.
release lock.
next iteration of the loop.
acquire lock.
...

which finally leads to single-threaded execution even if there are threads spawned and waiting in the pool, As shown below 👇

executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0
executing on thread: 0

Very tricky right? 😅

The lesson here is, to be careful when dealing with Mutex cause the compiler can't guarantee the desired threading behavior you wanna achieve such as this scenario or other scenarios like deadlocks which are so much worse.

That's why I've included a picture of Ferris that means that "This code compiles but does not produce the desired behavior." from the rust lang book

Without the logs, I wouldn't even notice that there was a problem 🤷‍♂️

Hope you enjoyed it 🤗

Create Prisma Generator

Yassin Eldeeb 🦀 — Sat, 25 Dec 2021 15:14:03 +0000

This blog is hosted on this github repo in content.md file so feel free to correct me when I miss up by making a PR there.

What's a prisma generator? 🤔

Prisma has a concept called "Generator". A generator is an executable program, which takes the parsed Prisma schema as an input and has full freedom to output anything.

The most prominent generator is called prisma-client-js. It's the ORM Client powering the main TypeScript and JavaScript usage of Prisma from Node.js.

Generators will always be called when you run prisma generate. However, only the generators mentioned in the schema.prisma file are being run.

Strongly recommend reading the full article, It's pretty damn good

From a community perspective when integrating prisma in different environments you'll often notice that there's a thing that you always go to change after modifying your prisma schema in your codebase, and that's when great developers realize that this thing should be automated to eliminate the problem of maintaining two or more different sources of the same definitions.

Getting Started

Now that you've a high level overview of what a prisma generator is, let's discuss the hello world prisma generator you'll get when using create-prisma-generator CLI 💪

I made it so that it requires the least amount of effort to start developing your own prisma generator.

Answer the prompt questions to setup your project, The project setup will be based on your answers.

Note: "? setup workspace for testing the generator" means to symlink the generator with another sample usage project so that when you run prisma generate from your terminal, It uses the local generator in the workspace which is very useful when developing, I strongly recommend it.

$ npx create-prisma-generator

I'll go and answer Yes for everything to go with the full capabilities of this CLI but you can follow along with your setup too.

And once you see the success message in your terminal saying that your project is now ready, open the project in your favourite IDE and let's have some fun 😉

First let's open the schema.prisma which you can find it at packages/usage/prisma/schema.prisma.

You'll notice your generator there symlinked with the generator code in the workspace

Note: the provider can differ from package manager to another, here I chose pnpm

generator custom_generator {
  provider = "npx my-gen"
  output   = "../types"
}

You'll also see some enums there, that's because the hello world generator that you get from running create-prisma-generator is for generating Typescript Enums from schema.prisma.

Now let's run the prisma generate command which should run all of the generators listed in schema.prisma:

$ cd packages/usage
$ npx prisma generate

Oh, WOW! the types directory wasn't there before, what the hell happened!

You can see that the types directory was generated after running prisma generate which contains all of the different enums defined in schema.prisma organized by an enum per file.

So if you opened any of the files in the types directory, you'll see an enum that matches exactly with the name and values as defined in schema.prisma

enum Language {
  Typescript = 'Typescript',
  Javascript = 'Javascript',
  Rust = 'Rust',
  Go = 'Go',
  Python = 'Python',
  Cpp = 'Cpp',
}

Noticed something? the output option in the custom_generator block in schema.prisma tells the generator where to output the generated files with a path relative to the directory where schema.prisma is located, try to change this option to something different like ../src/types and run npx prisma generate again.

generator custom_generator {
  provider = "npx my-gen"
  output   = "../src/types"
}

You'll see that it created all of the directories for the defined path and outputted the generated enums there.

Now after we've played around with the Hello World generator, Let's take a look at the code for it.

You can find the generator code located under packages/generator directory.

Open packages/generator/src/generator.(ts|js) and let's slowly discuss what's in there.

At the top you'll see we're importing some strange modules like @prisma/generator-helper, @prisma/sdk, what are those?

@prisma/generator-helper

The generator has to be an executable binary somewhere in the filesystem. This binary, for example ./my-gen needs to implement a JSON RPC interface via stdio.

When @prisma/sdk spawns our generator, It uses RPCs to communicate with our generator to send it the parsed datamodel AST as an example.

Luckily for us, prisma has wrote a helper library called @prisma/generator-helper. It takes all the work of implementing the interface and gives us simple callbacks where we can implement our business logic.

And as you can see, It has a callback called generatorHandler which takes two methods:

`onManifest:`

When running the prisma cli with the following command prisma generate It gets our generator manifest that gets returned from the onManifest callback method which contains all of the information about our generator like It's name, version, default output, which binaries and which version the generator needs.

generatorHandler({
  onManifest() {
    return {
      ...
    }
  },
  ...
})

`onGenerate:`

This is a callback method that run when @prisma/sdk calls it with the correct arguments that contains the parsed datamodel AST, generator options and other useful information.

generatorHandler({
  ...
  onGenerate: async (options: GeneratorOptions) => {
    ...
  },
})

@prisma/sdk

This is an internal API that has some very cool utilities that are often used when developing prisma generators which I've documented some parts about it here.

Back to our Hello World generator

After we've dicussed a bit about @prisma/generator-helper and @prisma/sdk, Let's get back to generator.(ts|js)

You'll first see that we're importing the generator's package.json and grabbing the version out if it to pass it as a part of the generator manifest,

then using the GENERATOR_NAME constant which is imported from packages/generator/constants.ts to log an info message to let us know when our generator is registred then returning an object expressing our generator manifest.

version and prettyName are used by @prisma/sdk when It calls getGeneratorSuccessMessage to generate a success message from our generator manifest like shown below.

defaultOutput is a fallback for the output option if It wasn't provided in the generator block.

const { version } = require('../package.json')

generatorHandler({
  onManifest() {
    logger.info(`${GENERATOR_NAME}:Registered`)
    return {
      version,
      defaultOutput: '../generated',
      prettyName: GENERATOR_NAME,
    }
  },
  ...
}

Let's get to the onGenerate callback where you'll receive the generator options which you can find the latest type definitions here, this contains a lot of information for our generator to use like pure datamodel, dmmf, generator(config, name, output, provider), schemaPath, version and hell a lot more.

DMMF?? It's the Datamodel Meta Format. It is an AST (abstract syntax tree) of the datamodel in the form of JSON.

You can see that we're specifically making use of options.dmmf.datamodel.enums which contains all of the parsed enums as AST that we can then have full freedom of outputting anything with this information.

We're using a helper function that can be found in packages/generator/src/helpers/genEnum.(ts|js) that takes the enum information and gives us back a string containing a Typescript Enum.

generatorHandler({
  ...
  onGenerate: async (options: GeneratorOptions) => {
      options.dmmf.datamodel.enums.forEach(async (enumInfo) => {
      const tsEnum = genEnum(enumInfo)

      const writeLocation = path.join(
        options.generator.output?.value!,
        `${enumInfo.name}.ts`,
      )

      await writeFileSafely(writeLocation, tsEnum)
    })
  },
})

Nothing crazy to make a Typescript Enum from the enum info, you can take a look at the file, It's really really simple.

export const genEnum = ({ name, values }: DMMF.DatamodelEnum) => {
  const enumValues = values.map(({ name }) => `${name}="${name}"`).join(',\n')

  return `enum ${name} { \n${enumValues}\n }`
}

Another thing you'll see is a utility function called writeFileSafely which takes the write location for the file and the content for that file then It creates all of the directories recursivly following the write location path and uses another utility function called formatFile to format the content using prettier before writing the file to the specified path.

export const writeFileSafely = async (writeLocation: string, content: any) => {
  fs.mkdirSync(path.dirname(writeLocation), {
    recursive: true,
  })

  fs.writeFileSync(writeLocation, await formatFile(content))
}

And that's it, that's our Hello World generator, hope It was a fun ride.

How do I develop within this workspace?

1- Open a new terminal and cd into packages/generator and run

# You can use whatever package manager to run the dev script
$ pnpm dev

This will watch your changes and compile on save into a dist folder.

2- Open another terminal and cd into packages/usage and here you'll have the latest build of your generator's code symlinked to this package so running:

$ npx prisma generate

..will always use the latest code of your compiled generator.

And as you iterate over your generator's code, you can run npx prisma generate to see the results.

Testing 🧪

Quality Software can't be shipped directly to the users and have to be well tested before It goes live.

That's why I've included jest in any project that gets bootstrapped by create-prisma-generator CLI.

If you don't know what jest is? It's a JavaScript Testing Framework learn more about it here

There's a very simple test located under packages/generator/__tests__/ called genEnum.test.ts, If you opened this file you'll see a test written that compares the generated output of the genEnum() helper function we've talked about previously with the already taken snapshot of a working version of this function.

We can run that test by running the following command in packages/generator directory:

# You can use whatever package manager to run the test script
$ pnpm test

You'll see all of the tests are passing, that means our software is ready to be shipped! 🥳

You can also see that we're not getting the DMMF from @prisma/sdk, mmm... that's strange but how are we getting the DMMF from a schema.prisma and where is even that schema.prisma file?

Usually in production the DMMF gets sent through this cycle:

@prisma/cli -> @prisma/sdk -> Spawns Generators -> Send DMMF through RPCs

Which works perfectly fine but not the ideal when testing prisma generators, we can cut this cycle and just get the utility function in @prisma/sdk that's responsible for generating the DMMF from a prisma definitions string which called getDMMF.

So as you can see we're calling getSampleDMMF() from the fixtures defined in the tests directory which then reads the sample.prisma located under __tests__/__fixtures__/ and parse it to an AST exactly like the one we get normally in a production environment.

And now It's up to you to write tests for your own generator.

I'm curios to see your creative solutions for testing your prisma generator 🤗.

Fancy Stuff ✨

Now let's get fancy with the full capabilities of this CLI and manage this project like an elite open source programmer 💪.

Auto Publishing 🚀

Remember the "automate publishing the generator with Github Actions" I've said yes to it at first.

That had setup a Github Actions workflow at .github/workflows/CI.yml which will run all of our generator tests then if they're all passing It will publish the package to npm using your Access Token.

To get an access token, you must first be logged in with your npm account or register here

Then click on your profile picture and go to "Access Tokens" like shown in the screenshot below 👇

Click on "Generate New Token" and select the token type to be "Automation" so that you don't require 2FA when running in a CI environment.

Before start publishing your package to npm, you'll need to replace the placeholders in packages/generator/package.json with actual information like: description, homepage, repository, author and keywords.
Check the docs to know what all of those fields mean npm package.json docs.

Now that you've your npm access token you can create a new github repository and add a new secret to your github actions secrets with this exact same name NPM_TOKEN.

Let's make a small change to this generator like changing the name of the generator as an example.

- export const GENERATOR_NAME = 'my-gen'
+ export const GENERATOR_NAME = 'my-super-gen'

Then commit & push to your repository on the main branch

$ git add .
$ git commit -m"fix: generator name"
$ git push -u origin main

After you push, go to your repository on github specifically on tha Actions tab and you'll immediately see the tests running and after they finish, the package will be published to npm with the version specified in the generator's package.json using your access token which you can then find using the following url https://www.npmjs.com/package/$your-generator-name 🥳.

Automatic Semantic Versioning 🤖

Don't know what semantic versioning is?, Mahmoud Abdelwahab got you covered with a 1 minute video about it check it out

Now we've a workflow for testing and automatic publishing the package to npm but It's not very nice having to go and manually bump the version in the package.json everytime you change something and wanna publish it.

Using semantic-release, we can just focus on our commit messages and It'll do the rest of the work for us like: bumping the version, github release, git tag, generating a CHANGELOG and a lot more.

Remember the "(Github Actions) setup automatic semantic release" I've said yes to it at first.

That had setup semantic-release for me with the Github Actions workflow and added husky with commitlint to force Conventional Commit Messages which then semantic-release will recognize and decide the next version based on it and do all of the stuff for us.

But there's a very small configuration we still need to make for this to work as intended.

Remember when I said:

bumping the version, github release, git tag, generating a CHANGELOG and a lot more.

Well, semantic-release needs read/write access over public/private repos to achieve all of that.

Create a new github access token from this link providing a note for it so you can remember what it was for.

Now that you've your github access token you can add a new secret to your github actions secrets with this exact same name GH_TOKEN which semantic-release will look for to do all of the magic for us.

Let's make a smalll change to this generator like changing the name of the generator as an example and call it a minor release.

  generatorHandler({
  onManifest() {
-   logger.info(`${GENERATOR_NAME}:Registered`)
+   logger.info(`${GENERATOR_NAME}:Hooked`)

Then commit & push to your repository on the main branch

$ git add .
$ git commit -m"new register message"
$ git push -u origin main

Oh crab what the hell is this?

Remember when I told you that this CLI has setup husky with commitlint to validate your commit messages if it was conventional or not before commiting so that semantic-release can decide what the next version is based on your commit messages.

Now let's run a proper conventional commit message

$ git add .
$ git commit -m"feat: new register message"
$ git push -u origin main

After you push, go to your repository on github specifically on tha Actions tab and you'll see the same running tests and after they finish, you'll notice something different, semantic-release has bumped the version to 1.1.0 and modified the package.json version to sync it with npm, generated a CHANGELOG for you, created a new tag and published a github release for you 🤯

WOW! I had a 0.01% chance that someone can read through all of that till the very end. I'm very proud of you, please mention or DM me on twitter and let me know you're one of the 0.01% of people.

Typing process.env automatically with this VSC extension

Yassin Eldeeb 🦀 — Sun, 05 Dec 2021 22:17:31 +0000

what's up typescript enthusiasts 👋
tired from writing types for your env variables to get a type-safe version of process.env as seen in this tutorial?

Setup

1- Install @types/node in your project

$ yarn add @types/node -D

// or using npm

$ npm i @types/node -D

2- First of all, download the VSC extension TS Env Typings

3- Specify env-typings.json file in the root of your project.

4- Add path field to your development .env file

and yep! you even have auto-completion in this JSON config too 😎

That's it, Enjoy!

Cool Features 🆒

1- Specify path for the generated output using output field in the JSON config.

2- Auto detect env variable type so that It can give you a nice example in the intellisense on how to use and parse it.

so as an example if you've a number env variable It'll tell you to use parseInt to parse it before using it cause env variables are always read as strings.

3- Variants for an env variable, so you tell the extension what are the possible values for an env variable so It can generate better types for it and recommend you a nicer example to use

How to specify Variants in .env file?

add a comment at the end of the env line that includes "# variants:"
specify the different variants for your variable seperated by a "|" like you would in typscript
quotes are optional around the variants values

That's it.

If you liked the extension, please give it a star here 🌟

Hope you've a great day, curios to see your feedback 🤗