Today’s challenge will be a quick one.

I would create and use a custom eslint-plugin in our upcoming libraries & projects. Our goal with the eslint-plugin library will be to share reusable eslint configurations.

Before we generate any new library, I want to change the configuration of nx to add new libraries to the /libs folder and new projects to the /projects folder. Update the nx.json file to reflect the following:

{
  .
  "workspaceLayout": {
    "appsDir": "projects",
    "libsDir": "libs"
  }
  . 
}

Next, we will generate 2 ui libraries by running the following commands.

$ nx generate @nrwl/js:library lib1 --unitTestRunner=none --bundler=esbuild --directory=ui --no-interactive
$ nx generate @nrwl/js:library lib2 --unitTestRunner=none --bundler=esbuild --directory=ui --no-interactive

Alternatively, we can generate the new libraries using the nx-console extension gui.

Let’s learn about some of the newly generated library files.

tsconfig.base.json

This will be the root Typescript configuration for our project. All future libraries or projects will be extending this configuration.
The important section to note is paths where we can see our newly added library mentioned.

{
...
    "paths": {
      "@rishabhmhjn/ui/lib1": ["libs/ui/lib1/src/index.ts"],
      "@rishabhmhjn/ui/lib2": ["libs/ui/lib2/src/index.ts"]
    }
...
}

libs/ui/lib{1,2}

project.json

This critical file contains the configurations and commands we would like to run via our nx console.

If you have installed the nx-console extension, you will see small links to run the commands (or targets) directly from the project.json file.

We can go ahead and run the build command directly from the project.json file or type the following command in the console.

$ nx run ui-lib2:build

The library will be compiled to the /dist folder.

Eslint

There will be 3 files related to eslint that are added to our repository.

/.eslintrc.json
/.eslintignore
/libs/ui-lib{1,2}/.eslintrc.json

There are 2 essential things to note about the root .eslintrc.json.

1. nx’ eslint-rule: @nrwl/nx/enforce-module-boundaries
   This handy rule triggers warnings if we have circular dependencies in our libraries or projects. You can read more about the rule here
2. By default, the whole repository is marked as ignored with "ignorePatterns": ["**/*"]. Every individual library or project does the opposite and marks themselves as not ignored in their respective .eslintrc.json configurations

Besides ignorePatterns in the .eslintrc.json file, we also see a .eslintignore file that contains more file patterns to be ignored globally.

Now, we will quickly test the @nrwl/nx/enforce-module-boundaries rule by updating the following 2 files:

/libs/ui/lib1/src/lib/ui-lib1.ts

import { uiLib2 } from '@rishabhmhjn/ui/lib2';

export function uiLib1(): string {
  return 'ui-lib1';
}

export function testBoundaries() {
  return uiLib2();
}

/libs/ui/lib2/src/lib/ui-lib2.ts

import { uiLib1 } from '@rishabhmhjn/ui/lib1';

export function uiLib2(): string {
  return 'ui-lib2';
}

export function testBoundaries() {
  return uiLib1();
}

We can see that the eslint extension will be showing an error:

This means our eslint setup is working!

We can also see that the warning goes off if we deactivate the rule in the root .eslintrc.json config

        {
        "@nrwl/nx/enforce-module-boundaries": [
          "off",
          {...}
        }

Now we can create our shared eslint-plugin library where will move the @nrwl/nx/enforce-module-boundaries.

Let’s create a new library: @rishabhmhjn/eslint-config.

$ nx generate @nrwl/js:library eslint-plugin \
  --unitTestRunner=none \
  --bundler=esbuild \
  --directory=etc \
  --importPath=@rishabhmhjn/eslint-plugin \
  --js \
  --no-interactive

It is essential to know that eslint-plugin can only use configs exposed from other npm packages and not via the typescript’s paths configuration.

Since we will add our newly added library as a linked package directly into our root package.json, we can choose to remove the path entry from the tsconfig.base.json file.

// tsconfig.base.json
{
 "paths": {
      "@rishabhmhjn/eslint-plugin": ["libs/etc/eslint-plugin/src/index.ts"], // You may remove this line
      "@rishabhmhjn/ui/lib1": ["libs/ui/lib1/src/index.ts"],
      "@rishabhmhjn/ui/lib2": ["libs/ui/lib2/src/index.ts"]
    }
}

package.json

Our package name is already set to what we need, so we do not require any change here.

{
  "name": "@rishabhmhjn/eslint-plugin",
  "version": "0.0.1",
  "type": "commonjs"
}

We will add the new library as a yarn-linked package with the following command.

$ yarn add link:./libs/etc/eslint-plugin -D

This will create a new entry "@rishabhmhjn/eslint-plugin": "link:./libs/etc/eslint-plugin" in the devDependencies of the root package.json file.

Now let’s make the following changes to our repository:

• Update libs/etc/eslint-plugin/package.json
  This exposes our main index.js file that will export our shared eslint configs.

{
  "name": "@rishabhmhjn/eslint-plugin",
  "version": "0.0.1",
  "type": "commonjs",
  "main": "src/index.js" // Add this line
}

• Remove libs/etc/eslint-plugin/src/lib/etc-eslint-plugin.js
  We don’t need this file

• Add libs/etc/eslint-plugin/src/lib/configs/nx.js
  This is the config containing the set of rules bunched together. We can see that this is the javascript equivalent of the rule in the current root .eslintrc.json file.

module.exports = {
  plugins: ['@nrwl/nx'],
  overrides: [
    {
      files: ['*.ts', '*.tsx', '*.js', '*.jsx'],
      rules: {
        '@nrwl/nx/enforce-module-boundaries': [
          'error',
          {
            enforceBuildableLibDependency: true,
            allow: [],
            depConstraints: [
              {
                sourceTag: '*',
                onlyDependOnLibsWithTags: ['*']
              }
            ]
          }
        ]
      }
    }
  ]
};

• Update libs/etc/eslint-plugin/src/index.js
  This is how we name and export the configs. Currently, we are exporting the nx config as plugin:@rishabhmhjn/eslint-plugin/nx or short plugin:@rishabhmhjn/nx

module.exports = {
  configs: {
    nx: require('./lib/configs/nx')
  }
};

Once these changes are made, we can remove the rule from the root config and extend the config we just exposed with our new eslint-plugin library.

• Update .eslintrc.json

{
  "root": true,
  "ignorePatterns": ["**/*"],
  "plugins": ["@nrwl/nx"],
  "extends": ["plugin:@rishabhmhjn/eslint-plugin/nx"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx", "*.js", "*.jsx"],
      "rules": {}
    },
    {
      "files": ["*.ts", "*.tsx"],
      "extends": ["plugin:@nrwl/nx/typescript"],
      "rules": {}
    },
    {
      "files": ["*.js", "*.jsx"],
      "extends": ["plugin:@nrwl/nx/javascript"],
      "rules": {}
    }
  ]
}

Now we can go back to the libs/ui/lib1/src/lib/ui-lib{1,2}.ts files and still see that the same lint error.

Except for this time, the rule triggering this error comes from our new eslint-plugin library, not the rule inside the root .eslintrc.json.

Hope you found this helpful. This was a very crude introduction to setting up an eslint plugin, but we will explore this further tomorrow along with

1. Setting up an angular web app project
2. Add a few eslint configs and implement them differently across libs
3. Add lint-staged config with a husky pre-commit hook

See you again tomorrow.

It’s 23:31 at the time of starting this blog! I just returned from a Toastmasters event.

I didn’t get time to work on the challenge today in the coworking space as I was busy with a few meetings and the goal of completing the skeleton of the data management flow of our Create post page with custom hooks. I am happy that it was finished before I left for the Toastmasters.

Tomorrow, I will complete the integration of data management hooks with the screens.

Toastmasters

A fellow at the coworking space invited me to join him at the Toastmasters event. Toastmasters is an organization that encourages people to learn public speaking and communication skills through regular events, usually weekly.

It’s an incredible stroke of luck that I recently talked about improving my speaking skills, and today there I was as part of a community that’s doing just that. The participants were half Czech and half expat.

The topic of today was confusing: Reverse Toastmasters. It was about doing all the things they usually do, but in reverse.

It kicked off with an ending farewell note, feedback on the speeches (that were yet to come), and lastly the introduction of what the Toastmasters event is. It was confusing for all the participants! However, it was fun and interesting.

I am inclined towards joining one of these groups. I found the people to be kind and supportive. Everyone seemed to have come with a shared ambition of learning how to speak in public. That is just what I was looking for!

I still struggle to find the right words to communicate well. The easier, straightforward topics for me to talk about are differences in culture, work, and jokes.

But my goal is to give an informative presentation on a specific topic. It’s easy to do small talks about random topics with a handful of people, but it is challenging to keep a large audience engaged when you have all their attention and expectations to gain something out of the time they spend listening to you. It’s daunting!

When you learn to write, you learn to think

One of the ways I feel I can overcome this hurdle is by writing. It’s very late now, but I want to write a blog daily; no excuse! So here we are.

For the challenge, today I will create and publish the 100daysofcode repository with support for nx, commitlint and husky. Let’s get started.

Monorepo setup

Nx

We will initialize our 100daysofcode challenge monorepo using the create-nx-workspace command. I will talk more about monorepo and their benefits in the coming days. For now, let’s create our repository.

$ npx create-nx-workspace@latest @rishabhmhjn/100daysofcode --preset=ts --package-manager=yarn

This should initialize your repository with the following files.

Install recommended VS Code extensions

I suggest you also install the VSCode extension for NX, which will make it easier to run NX commands directly from the editor.

The recommendation to install Nx console is already added to your .vscode/extensions.json file, so it should appear in your Extensions tab under the Recommended window.

I will also add some of the extensions I use daily to my list of recommended extensions.

I could type in their IDs directly into the JSON file manually.

I can also search the extensions and press the Add to Workspace Recommendations file directly from the UI. The extension IDs are added to the .vscode/extensions.json file automatically.

This is how my .vscode/extensions.json file looks like

{
  "recommendations": [
    "nrwl.angular-console",
    "esbenp.prettier-vscode",
    "formulahendry.auto-rename-tag",
    "jannisx11.batch-rename-extension",
    "aaron-bond.better-comments",
    "wmaurer.change-case",
    "naumovs.color-highlight",
    "dbaeumer.vscode-eslint",
    "editorconfig.editorconfig",
    "oderwat.indent-rainbow",
    "ecmel.vscode-html-css",
    "eamodio.gitlens",
    "davidanson.vscode-markdownlint",
    "pnp.polacode",
    "medo64.render-crlf",
    "ms-vscode.sublime-keybindings",
    "angular.ng-template"
  ]
}

Prettier

Now we can start adding our custom configs, starting with prettier. I use the following config for our projects.

{
  "singleQuote": true,
  "useTabs": false,
  "tabWidth": 2,
  "semi": true,
  "trailingComma": "none",
  "bracketSpacing": true,
  "htmlWhitespaceSensitivity": "strict",
  "printWidth": 80,
  "overrides": [
    {
      "files": ["**/*.html"],
      "options": {
        "printWidth": 120
      }
    },
    {
      "files": "*.{yaml,yml}",
      "options": {
        "singleQuote": false
      }
    }
  ]
}

Commitlint

Commitlint helps you create consistent commit messages. You can follow the instructions at https://github.com/conventional-changelog/commitlint.

# Install commitlint cli and conventional config
$ yarn add @commitlint/{config-conventional,cli} -D

I tend to follow Angular’s commit message guidelines. We can install the package containing their commitlint rules.

# Install the angular commit lint config
$ yarn add @commitlint/config-angular -D

Now, although commitlint manual suggests using a commitlint.config.js file, I will go a different route and use a .commitlintrc file.

echo '{"extends": ["@commitlint/config-angular"]}' > .commitlintrc

I will also instruct the VSCode editor to fetch the schema of the JSON file so that I can get a neat explanation of what the various property means. To do that, I will add a new file .vscode/settings.json.

// .vscode/settings.json
{
  "json.schemas": [
    {
      "fileMatch": [".commitlintrc.json", ".commitlintrc"],
      "url": "https://json.schemastore.org/commitlintrc.json"
    }
  ]
}

Once the schema is fetched, you can hover on to the properties and also get code completions:

Husky

We also need to add husky that automatically runs the pre-commit hooks for commitlint and the eslint later.

# Install Husky v6
yarn add husky --dev

# Activate hooks
yarn husky install

# Add the pre-commit hook
npx husky add .husky/commit-msg  'npx --no -- commitlint --edit ${1}'

This should add a few files to the .husky folder.

To ensure the git hooks are installed automatically if you move systems or when someone else works on your repository, you need to add the following command to your scripts in package.json

  "scripts": {
    "prepare": "husky install"
  },

Before committing the above changes, we should add our own commitlint config. I foresee using the following config for the coming time, so I will add it manually. This is what my .commitlintrc will look like.

{
  "extends": ["@commitlint/config-angular"],
  "helpUrl": "https://commitlint.js.org/#/reference-rules",
  "rules": {
    "type-enum": [
      2,
      "always",
      ["build", "docs", "feat", "fix", "perf", "refactor", "revert"]
    ],

    "scope-max-length": [2, "always", 16],
    "scope-min-length": [2, "always", 2],
    "scope-empty": [2, "never"],
    "scope-enum": [2, "always", ["infra"]],

    "subject-case": [2, "always", ["sentence-case", "lower-case"]],

    "header-max-length": [2, "always", 72],
    "body-max-line-length": [2, "always", 72]
  }
}

I will add more scope-enum in the coming days of the challenge. You can read more about the commitlint rules here.

Now, if you would try to commit with a non-conforming commit message, you will get an error, and the commit will fail.

# 1. Without any format
$ git commit -m "Any Commit"                                                                                                       

⧗   input: Any Commit
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]
✖   scope may not be empty [scope-empty]

✖   found 3 problems, 0 warnings
ⓘ   Get help: https://commitlint.js.org/#/reference-rules

husky - commit-msg hook exited with code 1 (error)

# 2. Following the format but exceeding max header length
$ git commit -m "feat(infra): Adding .prettierrc, .commitlintrc and recommended vscode extensions"
⧗   input: feat(infra): Adding .prettierrc, .commitlintrc and recommended vscode extensions
✖   header must not be longer than 72 characters, current length is 80 [header-max-length]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://commitlint.js.org/#/reference-rules

husky - commit-msg hook exited with code 1 (error)

This means that our pre-commit hook with commitlint is working. We can now commit the current code with a proper message.

$ git commit -m "feat(infra): Adding .prettierrc, .commitlintrc and .vscode/extensions"

[main febffba] feat(infra): Adding .prettierrc, .commitlintrc and .vscode/extensions
 7 files changed, 1010 insertions(+), 18 deletions(-)
 create mode 100644 .commitlintrc
 create mode 100755 .husky/commit-msg
 rewrite .prettierrc (84%)
 create mode 100644 .vscode/settings.json

Success! Now I will push this newly created repository to my github profile.

https://github.com/rishabhmhjn/100daysofcode

It’s 01:33 now! I planned to do more, but I need to sleep to be able to finish my ComposePage tomorrow.

Tomorrow, for the challenge, I plan to work on the following within the new nx monorepo:

1. Create a simple Angular/React/Vite project
2. Create & test custom eslint-plugin
3. Update the Readme.md

It was a very crude post today, but I hope it will be useful to you.

See you tomorrow.

“I can’t see a way through”, said the boy.

“Can you see your next step?”

“Yes”

“Just take that,” said the horse.

The Boy, the Mole, the Fox and the Horse

I have been going over this for long, and it is high time I do this. Rephrasing, It would be a waste of my time if I don’t do this!

Background

I have been a developer for most of the last 13 years. I have built tools and libraries consumed primarily internally at my company, Statusbrew.

I used to be active in building communities of creators, developers, and startup/small business owners in my home city. I had many occasions to meet new people and share knowledge with them. We were also covered frequently by the local press. Many people in our city knew about us and were following our work.

After the pandemic started, I passed on the opportunity to become active in the social space as I focused on sales and revamping our web and mobile applications. It’s been nearly 2 years since I also gave up even on talking to my own customers and delved deeper into coding behind my work desk. That closed work focus was the need of the time, but now most of the hard work is done.

I have temporarily moved to Prague and have spent a significant chunk of the last 2 years here but working from home. I moved to a co-working space in November and saw my communication and social circle improve. I am inspired by the tech talks I get to attend nowadays, and I envision being part of the core community soon.

It was not easy getting back within groups of people and talking. Often I find myself in the situation I was in 12 years ago when I moved to Japan – my accent and the words I use are hard for people to understand. I am also stumbling during simple discussions. This is due to the lack of social interactions in the last years.

So things need to change. I needed push myself to become more active virtually and in daily dealings for my growth.

Thus, this challenge.

Objective

I am taking up this challenge to work on the following aspects:

1. Knowledge sharing
2. Communication
3. Time management

Knowledge sharing

Every day, I work on exciting solutions, designs, and architecture that goes into building a complex application. A portion of that knowledge gets shared with my team, but most of it gets lost as I move on to the next problem.

Occasionally, I get to attend tech meetups and discuss challenges with other developers. Most expressed excitement when they learn about some unique designs we have worked on our with our application architecture. I reciprocated similarly when I learned something new from them.

I started to take small steps of knowledge sharing and technical discussions in my current workspace. When I am stuck, I reach out to developers in the space; those discussions have benefitted me.

A simple example:

I could find a workaround for using Components with Generics and memo (or even forwardRefs) that helped enforce strict type definitions in my component designs. This solution was given by a fellow react developer in my coworking space.

Communication

There is no doubt that writing and speaking skills are incredibly essential nowadays. We have infinite thoughts, though a majority of them are banal. But there are many ideas that, when shared, can lead to meaningful interactions and connections.

During all that hustle in the last 3 years, I hadn’t been reading, writing, or engaging in public communication. Recently, I had moments when it was hard to express myself and communicate well.

With this challenge, I will focus on articulating and publishing a daily post, however small it will be, on this blog under the #100daysofcode tag.

I will discuss javascript, typescript, mono repo, angular, react, and architecture designs. Currently, I do not plan to publish open-source libraries, but I would love to release something helpful to others whenever possible.

I will also use various tools and modes to share knowledge, an upcoming github monorep, Expo Snacks & gists. I also plan to publish a mundane looking timelapse of one of my daily pomodoro sessions on the @ramenhacker Instagram page.

Time management

Without a doubt, my work at Statusbrew has and will likely continue to precede other initiatives. However, I want to push myself to pursue other interests, knowing that now it’s more possible to do so than ever before.

My tentative time divisions would be as follows:

1. Statusbrew (8 – 10 hours)
2. Publish a readable gist/snack/monorep (0.5 hour)
3. Timelapse reel (0.5 hour)
4. Daily progress report blog post (1 hour)

Undoubtedly, I won’t have the same bandwidth to strictly follow the above time allocation. I reckon it will be a tentative time division when looked at over the course of a week or month.

This blog has taken me about 4 hours to write! Of course, I don’t intend to write lengthy monologues every day. But I don’t want to take more than 20-30 minutes to write the next set of posts

Goal

My ultimate goal with this challenge is to give a presentation about a topic I have mastered at a developer meetup.

To achieve this goal, I will

1. Learn to organize my thoughts into speaking bits and writing
2. Be more active in the nearby developer communities
3. Become comfortable in front of an audience or camera

Next Steps

In the coming week, I will set up a high-level plan of action and milestones leading toward my goal.

Tomorrow, I will set up and publish a monorepo with my frequently used configs, such as .dotfiles, eslint, and prettier. Soon, I will be writing about Angular, React, Vite, Monorepo architecture, and the best practices we have implemented.

From Starbucks in front of the Astronomical Clock in Prague

This challenge will not solve all my communication problems. But it sure will help improve it a little bit. So I am taking the next step.

Have a great rest of the weekend. See you soon.