DEV Community: Petar Garžina

Do you even read bro? 5 advices on reading and staying up to date

Petar Garžina — Fri, 21 Jul 2023 08:42:06 +0000

https://knowyourmeme.com/memes/do-you-even-lift A popular meme back in the days. Used as a condescending expression to question the legitimacy of someone’s expertise around a certain topic. Do you even lift bro?

In the last couple of interviews when we asked the candidates what they read to keep up to date with the latest tech, they had no straight answer. I was a bit saddened by that fact, so I decided to write this blog post about the struggles I experienced and how I managed to keep on reading, either books or tech blogs.

This is also an extended version of the answers to questions I got asked at an IT Job Fair at our local university: How do you maintain your professional skill? and How to land your first job in IT? Hopefully you will find the advice that follows useful.

Already tired of reading? No problem here's a tldr:

Read a major introductory book
Subscribe to at least one newsletter
Re-read important chapters, articles or books
Read a book to master the subject
Find the time to read, change priorities

The start

To give you a bit of context, I am a software engineer with no formal college education in programming. Most of the things I know I read in books and articles, the rest I learned from online courses. I was interested in programming and went to a few public lectures and workshops and managed to publish two small Android apps. Soon I realised that without proper core knowledge and understanding of programming I would never get far. In my last year of college (in Linguistics) I was lucky enough and got an opportunity to go on a summer internship to University of Indiana, USA. My job as an intern involved a bit of programming as well since I was into Computational Linguistics. I decided to invest that summer into reading two core introductory books. The first one was a general Introduction to Programming Using Java and the other was about Android Programming. I did spend almost all afternoons reading them, but it really paid off. That was what really got me off the ground and enabled me to move forward into the field.

That brings us to advice number one, especially if you are a beginner:

Invest time in reading at least one major introductory book that covers the subject thoroughly

Up until that point I read tutorials, watched videos and was able to muster up an application or two. But after reading 1000+ pages that went deep into the matter I finally understood a lot of the things that prior to this I was just copy pasting with little understanding on how they worked. Again, reading them was not easy. I remember keeping my finger on the Abstract class chapter and each time the abstract class would be mentioned further in the book I would have to go back and reread the chapter as it was hard for me to grasp the concept in just one go. For me, those two books enabled me to switch my profession and to land a job as a programmer.

The journey

The road ahead was paved with HTML and CSS as I moved into Web Application development and the ever changing world of Frontend development. To stay ahead of the game you had to follow an extremely broad and somehow Greatly Divided field. Even if you are an UX engineer focused on design, HTML and CSS or a JavaScript engineer focused on programming, there are still a lot of topics to cover. This is where weekly digests helped a lot.
At the beginning I was only getting Android Weekly which got replaced with JavaScript Weekly. Soon after I've added Medium daily digest. But the daily digest was a bit too much and I switched it to a weekly digest as well. Later on I added Frontend Focus, and have kept those three for more than 7 years now.
Both JavaScript Weekly and Frontend Focus are structured in a similar way. You get a General Articles section to start with, followed by a Quick and Brief section outlining a couple of new things out here. After that three sections follow: Tutorials and Articles, Tools and Resources and the last one is Jobs. I read all of the headings as they alone are informative enough to learn if a new Node version is out or an LTS for a tool came to an end. Every now and then I open a job posting or two to see how the industry standard is changing in that regard, mostly checking out the perks and the salaries.
Each of the three serves a purpose; JavaScript Weekly is JavaScript oriented, including backend JS. Frontend Focus includes more articles about Design and UX/UI, and my Medium feed is focused on Angular. In the end I usually read just one or two articles from all three weekly digests. Of course there comes a period of time when I do less reading, my inbox gets cluttered, I skip the digest for a couple of weeks and just delete them.

You don't have to subscribe to three but

Subscribe to at least one weekly digest.

Newsletters don't require that much focus time as a book, so you can read them wherever. Drinking your morning coffee at the office or in the waiting room at the dentist. What helps a lot to stay loyal to your weekly digests is having Inbox Zero Policy. That way the digests don't get lost too quickly and it also drives you into reading them.

As for the books, in the first couple of years I've read two JavaScript books: Secrets of the JavaScript Ninja and Mastering Modular Javascript. The 500-pager on how to become a Ninja was useful, but how to build modular architecture with JavaScript is the one I really loved. It's a rather thin book, around 150 pages, mostly text with very little code examples. After reading this book I was like, wow, I'll have to read this book again. And so I did, a year or so after.

The main benefit of reading a good book again, particularly many years later, is that your added experience of life [work] enables you to understand what the author had in mind much more clearly. Stein

Even though it takes a bit more effort, re-reading a book or at least some parts of it is essential in better understanding the topic.

That would be my 3rd advice

Re-read a chapter, an article or a book
Often, reading it once is not enough, you will deepen your understanding with the second read.

Although my transition from the initial Java/Android developer to a Web App developer went kind of smooth, I always had a feeling I was missing something. One day a colleague ordered JavaScript the Definitive Guide and by mistake we got two copies. I was glad and I took the opportunity to finally read a JavaScript book that covers the language from A to Z. Even though years passed and I was far off into the field I thought it was not too late for me to go through the ins and outs of the language, through all the quirkiness JavaScript provides. Challenge yourself to read that core book, the one that digs deep into the matter and that will "take your understanding and mastery to the next level" (O’Reilly). This applies to senior developers as well, as we had senior developer candidates that, to our surprise, lacked the basic and fundamental JavaScript knowledge.

That would be my 4th advice:

Read a book to master the subject
It's never too late to strengthen your fundamental knowledge. Don't feel uncomfortable going back to basics.

The end

Don't get me wrong. I'm no bookworm and I don't have a long list of books I want to read. I'm also not a routine person so my reading habits often change. With fields such as IT that constantly change, learning is an endless story in a life lasting sprint. I still get my tech weekly digests, but as my career changed direction a bit I started reading management books, going once more through most of the steps I went when I started as a developer.

My 5th and final advice would be:

Find the time to read
Change your priorities, change your routine.

At Cognism, we are enabled and encouraged to improve and educate ourselves by reading and taking courses. My first try at better reading habits was booking reading slots during the work week in the calendar. But it was quite hard to come into the office, take a book out and start reading there. Once I'm in the office I enter the office mode. Usually one or two persons are already on Slack waiting for me, emails waiting to be replied to, meetings to attend etc. What I started doing at one point was instead of going directly to the office, I would spend 30-45 minutes in the building's coffee bar reading and would come into the office a bit later.
Finding time to read at home is hard as well. Especially with 3 small children running around. For a while I did manage to squeeze in a slot. Once we put our 3 children to bed, instead of turning on Netflix immediately, I would spend 30-40 minutes reading, and then we would proceed to the newest must-watch series. Does not seem much, but falls nicely into the daily routine.
In the end it is not about having time, we all have 24 hours in our day, but it's about the priorities and on how you want to spend your time.
Experiment with different times and see what suits you the most and try to stick with it. If you have any suggestions or want to share any of you struggles please do post them in the discussion below!

The race for excellence has no finish line. (a wise internet person)

Feel free to connect 👋

LinkedIn | Twitter | Instagram

Cursors, shortcuts and clipboards; increasing your productivity

Petar Garžina — Wed, 21 Dec 2022 12:54:58 +0000

Save time. Increase productivity. Here are several small things that will make you a bit faster, and your work a bit more enjoyable. I hope you'll pick up at least one or two things. You can go wild and use all of these. It's a good start if you want to progress into a real power user.

Notes:

Several GIFs ahead. Just click on it to stop it looping.
Hotkeys used are for MacOS, but if you replace ⌘ with ctrl you should be all set for Win/Linux.

Use your cursors wisely

The same way a craftsman uses his hands as tools in the physical world, we use our mouse and keyboard as a tool in the digital world. It may not be our most important tool, but nevertheless as a tool we should be always looking to improve how we use it.

Copy a single line

Everyone knows how to copy a line right? (⌘ + C)

Some might not know that you don't need to go through the pain of highlighting a line in order to copy it. Put the cursor anywhere on the line, hit the shortcut and the line will get copied.

People struggle clicking three times to highlight the line, sometimes they click the fourth time, highlighting the whole text. Or they drag the cursor along the line usually messing up the highlight or end up missing a couple of characters.

Place the cursor in position and hit that shortcut!

Remove a single line

The same cursor placement magic that applies when copying a line also applies when removing a line. The quickest way to remove a line is placing the cursor anywhere on that line and hitting ⌘ + X.

One thing to note here is that ⌘ + X cuts the lines, it does not delete them. So it affects your clipboard, or the clipboard manager that you use. You do use a clipboard manager right?

If you actually want to delete the line then you should use a different shortcut, ⌘ + shift + K. The shortcut is for VS Code, it might differ for other IDEs.

Since the above shortcut is a bit harder and takes a bit more time to perform than the one for cutting, my preference is ⌘ + X.

Multi-cursors

Place one cursor to edit a single line, place multiple cursors to edit multiple lines! Multi-cursors are your friends for fast simultaneous edits.

Once you get a hang of it you'll love it as it makes coding a lot more fun. The two main shortcuts are ⌘ + D which selects the word at the cursor, or the next occurrence of the current selection, and Alt+ Click that adds secondary cursors.

This was a game changer for me, and I used it on a daily basis. I seriously recommend you learn the basic shortcuts and give it a go.

This is something all popular Integrated Development Environments have, VS Code, JetBrains IDE's, Atom, Sublime so you can definitely try it out.

Clipboard manager

Now that you know how to copy lines more easily and know how to add a bunch of cursors and copy all the lines at once, you need a better storage place for the data you copied. Instead of overwriting what you copied with each new copy, a clipboard manager enables you to store the data you copy.

Copy from the browser, switch to the IDE to paste, then go back to the browser to copy again, switch to the IDE to paste, go back to... no more!

Copy all the things you need from the browser, switch to your IDE and paste one by one in the desired location.
While on Windows I used Ditto as it has several cool features. On MacOS I use Pastebot which also comes with some advanced features. One of the features I use is Custom Pasteboards where I keep a permanent Lorem Ipsum paragraph which is always useful to have at hand while developing and testing. I also keep my personal Zoom link there as well as it makes setting up meetings on the fly easier. If you find yourself using something over and over again and it might fit into a persistent pasteboard, add it (don't add passwords tho)!

Navigating through the codebase

Use ⌘ + P to quickly open a file.

Don't start looking for the file in the IDEs file Explorer, opening and closing different folders trying to locate it. Or even worse, using the global search to search for something you know is in that file, just to open it. This is something I have witnessed first hand, and usually gets me agitated :)

Pretty much all of the modern editors have this documented in more length. Two main actions follow.

Open a file

You can open any file by its name when you type ⌘ + P (Quick Open). As you start typing the IDE will narrow down the list of files from which you can select to open. You don't have to go to the File Explorer and dig up a file.

Find a symbol or jump to a line

Use ⌘ + P and append @ to find a method inside the file. You can also combine ⌘ + P with @ and/or : to easily jump to methods, variables or jump to lines. I usually use it to jump to a line, especially if I see the line mentioned in the error stack trace.

Jump to definition

Use your mouse keys.

You can jump to definition with ⌘+ Click , but you cannot jump back. Once you jumped in, the only way to go back is to navigate back with ⌘+ - . At that point if you need to see the definition once more, you can just navigate forward using ⌘+ shift + -.

Jumping in several definitions consecutively and then navigating back and forth between them to better understand the data flow in yours or someone else's program is something you have to get familiar with.

The shortcuts here are quite impractical. Of course you can change the shortcuts to your liking. But the neat thing here is that you can also use your mouse to navigate. You just need a mouse with two additional keys which are usually by default bound as navigational keys. You can then use those keys to navigate between the methods in your IDE. And since jumping in requires a mouse click, it feels natural to continue to navigate using the mouse keys.

Even if you don't want to use your mouse keys, do learn the shortcuts or change them as you like. Any of the above is better than navigating back by trying to find the file that you just jumped out of in the list of your currently opened files. The shortcut is a lifesaver here.

These are only bits and pieces I picked up in my own journey that made it a bit more fun, hope it will do the same to you. They might not seem much but as the years go by they will add up.

5 tools to automate your development

Petar Garžina — Fri, 27 Aug 2021 12:43:48 +0000

Automating your development with Dependabot, Auto Assign, Merge Freeze, Husky and Scheduled reminders.

The idea of this post is to introduce some of the tools and integrations that made our development life easier.

Most of these are pretty straightforward to implement into your workflow but for the ones that have a couple of gotchas I might write an extended introductory version for that tool alone.

1. Dependabot

Automated dependency updates

Dependabot creates pull requests to keep your dependencies secure and up-to-date.

Dependabot is dead simple and their punchline clearly states what it does. We started using it a couple of years back, a bit before Github acquired it.

The main reason was that, at the time our current team took over the Front End division, there were a lot of outdated dependencies which we wanted to update and wanted to keep up to date. We found Dependabot, added it to our projects, and let it do its magic ever since.

Now it's natively a part of Github, so adding it is even easier than before. You can check out how to set up Dependabot, but in the end you'll end up with a dependabot.yml in your .github folder.
Ours looks like this:

version: 2
updates:
  - package-ecosystem: "npm" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "daily"
    open-pull-requests-limit: 2
    commit-message:
       prefix: "BleedingEdge"

The only thing that differs from the default settings is that we:

chose npm as our package-ecosystem
limited the number of open PRs to 2
added a prefix for the default Dependabots commit message (you'll see later why)

Four years back we had 3 frontend repos, now we have around 14 active ones. Manually keeping every dependency up to date would be extremely time consuming. Dependabot helps a lot, but it still takes time to review and merge all the PR's. We usually take a day, after our weekly release, to merge Dependabots pull requests.

Writing this got me wondering if we could set the bot to open PR's only on major, minor or patch versions and indeed the feature was requested in 2018 and got released a few months ago and now you can ignore SemVer updates of your choice. Check out GitHub's blog post for more.

2. Auto Assign

Add reviewers/assignees to pull requests when pull requests are opened.

So you opened a pull request, you need at least two approvals and you need to add reviewers to your pull request. Every single time.

Things are pretty obvious, let the bot do it.

Setting up is easy, go to probot.github.io/apps/auto-assign hit the Add to Github button and don't ever worry about manually adding reviewers!
Similar to Dependabot, you will end up with a auto_assing.yml file:

# Set to true to add reviewers to pull requests
addReviewers: true

# Set to true to add assignees to pull requests
addAssignees: false

# A list of reviewers to be added to pull requests (GitHub user name)
reviewers:
  - teammember1
  - teammember2
  - teammember3
  - ...


# A number of reviewers added to the pull request
# Set 0 to add all the reviewers (default: 0)
numberOfReviewers: 0

# A list of keywords to be skipped the process that add reviewers if pull requests include it
skipKeywords:
  - BleedingEdge

We have nothing out of the ordinary here. We are utilizing the skipKeywords option with the BleedingEdge keyword that if you remember Dependabot prefixes to each of its pull requests. We handle the pull requests Dependabot opens a little bit differently and don't want to burden all the reviewers with them.

Once the Pull request is opened the bot kicks in and you see it in the timeline requesting reviews:

You can also try and use the default settings Github provides for Code Review Assignments. Just go to your team page, in the top right hit Settings and you'll find the Code review assignments tab. We tried it but it didn't work out for us.

3. Merge Freeze

The code freeze tool to block merging and deployments

The reason for adding merge freeze originated from a simple question:

Can you tell all the developers to stop merging since we are starting regression?

We could announce it in our team's channel in hopes that everyone reads the message in time. Or we could integrate a tool that allows the QA team to issue a command on Slack that freezes/unfreezes merging to the repository. Merge Freeze to the rescue.

Again, setting up, nothing too complex. What we did find Merge Freeze is missing is the ability to bulk freeze. It worked well when we needed to freeze a couple of repos. But once the number of our repositories increased to over 10, manually entering the command more than 10 times... you get it.

For this we used Slack Apps and AWS Lambda.

We created a custom Slack App for our workspace called Deployment, that has two Slash commands: /freeze_all and /unfreeze_all. Both commands have the Request URL set to our Lambda url, and pass the freeze value as a query parameter: ?freeze=true | false.

Using it on Slack looks like this:

The Merge Freeze tool exposes an API endpoint for each repository you add to it, which you can use to freeze or unfreeze it. That makes the Lambda rather simple, it just makes a POST request to each of the endpoints provided by MergeFreeze.

const https = require('https');

exports.handler = async (event) => {

  const freezeValue = getFreezeValue(event);
  if (!freezeValue) {
    return {
      statusCode: 400,
      body: JSON.stringify('BOOM! You need to provide a freeze value as a query param, either true or false'),
    };
  }

  const userName = getUserName(event)

  const baseOptions = {
    hostname: 'mergefreeze.com',
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Content-Length': 0,
    },
  };

  const appOneOptions = {
    path: `/api/branches/your-organization/your-repo/main/?access_token=${process.env.ACCESS_TOKEN}&frozen=${freezeValue}&user_name=${userName}`,
    ...baseOptions,
  };
  ...
  /** Removed the rest of declaration to keep the preview short */


  await Promise.all([
    doRequest(appOneOptions),
    ...
    doRequest(appElevenOptions),
  ]);

  console.log("I'm done with all your promises!");

  // Text that gets return to Slack that is only visible to the person entering the command
  return {
    statusCode: 200,
    body: JSON.stringify('You have such power!!!'),
  };

  function doRequest(options) {
    return new Promise((resolve, reject) => {
      const req = https.request(options, (res) => {
        res.setEncoding('utf8');
        let responseBody = '';
        res.on('data', (chunk) => responseBody += chunk);
        res.on('end', () => resolve(responseBody));
      });

      req.on('error', (err) => reject(err));
      req.end();
    });
  }

  function getFreezeValue(event) {
    let freezeQueryString;
    let freeze;

    if (event && event.queryStringParameters && event.queryStringParameters.freeze) {
      freezeQueryString = event.queryStringParameters.freeze;
    }

    if (freezeQueryString === 'true' || freezeQueryString === 'false') {
        freeze = freezeQueryString;
    }

    return freeze;
  }

  function getUserName(event) {
    const bodyQueryParams = new URLSearchParams(event.body);
    return bodyQueryParams.get('user_name') || 'Web API';     
  }
};

After entering the command, MergeFreeze lists all the repos that got frozen or unfrozen and you get a confirmation message from Slack, making your work day a bit better!

After the regression is done, everything is pushed to Production and is smoke tested, the lead QA issues the unfreeze_all command and life goes on.

4. Husky

Modern native Git hooks made easy

We use Jira as our work management tool so we have to prepend the ticket ID to our branch names and commit messages in order to utilize both the Development panel when viewing an issue and VSCodes extension GitLens:

Jira ticket Development panel:

This means that each time you create a branch you have to remember to include the Jira issue ID, eg: task-ND-123-add-authentication. That alone was not a big deal as it quickly became a habit. But what was a PIA was prepending it to every commit message. The 1st automation round was just setting up the git prepare-commit-message hook on your local machine, but as the team grew larger we needed a better solution which Husky provided!

Husky in combination with jira-prepare-commit-msg is what worked for us:

...
  "private": true,
  "husky": {
    "hooks": {
      "prepare-commit-msg": "jira-prepare-commit-msg"
    }
  },
  "jira-prepare-commit-msg": {
    "messagePattern": "$J $M",
    "jiraTicketPattern": "(\\w+-\\w+-\\d+)"
  },
  "dependencies": {
...
  "devDependencies": {
    "husky": "^4.3.8",
    "jira-prepare-commit-msg": "^1.5.2",
...

The JIRA ticket ID is taken from a git branch name. Now you could just write commit -m "Fixing a typo" and you would get a commit message looking like task-ND-123-Fixing a typo.

In case you did not name your branch correctly eg: missing Jira ticket ID you would get an error:

my-application git:(main) ✗ git commit -m "Add authentication methods"
husky > prepare-commit-msg (node v14.15.0)
JIRA prepare commit msg > start
JIRA prepare commit msg > Error: The JIRA ticket ID not found
JIRA prepare commit msg > done

This came in nicely as everything was set up in package.json and a new developer would do npm i and she/he is pretty much set, no need to manually configure hooks.

But the Jira Ticket ID in the commit message in combination with GitLens is what really made this super useful.

GitLens with Git blame annotations:

There were a lot of times where we had to, for various reasons, open up and read the Jira issue associated with the code change. Having the ticket ID at each mouse click throughout the codebase saved us a lot of time. (opening it in the browser is easy as well, just take the Jira ID and add it after .../browse/ + ND-123 e.g., https://your-organization.atlassian.net/browse/ND-123)

GitLens is a cool tool which I personally use on a daily basis. It helps you to visualize code authorship at a glance via Git blame annotations and code lens. You can also very easily navigate back in history to see past commits which is useful as well.

5. Scheduled reminders for Pull Requests

Scheduled reminders help teams focus on the most important review requests

This is something we added not too long ago, just a bit after we moved to Micro Frontend Architecture. One of the reasons for adding it was that the number of repositories increased from 4 to 14 so having a dedicated channel for open pull requests made sense. Prior to this we would post a link of the PR in our team's main channel, or would hope people would see it in their email. This way we moved the noise to a dedicated channel, and the devs know the team will get automatically notified.

We get notifications on every working day each full hour from 8-16. It ignores approved pull requests (in our case when 2+ ppl approved it) and we also have ignore terms for BleedingEdge so it ignores pull requests opened by Dependabot.

Setting up scheduled reminders is straightforward and you can find the github docs here. This is how it looks like once its up, in our case it posts messages in a private frontend-pull-requests channel:

...

There are a lot of improvements that we could include on top of what we have, like creating branches directly from Jira would ease up on having to remember the naming convention. Or maybe we could have chosen a merge freeze tool that has bulk freeze built in. But usually we had limited time for investigation, or it was good enough at that time, and later on we just tried to improve the process instead of replacing the tool.
If you have any suggestions, please do post them in the discussion below!

Feel free to connect 👋

Twitter | Instagram | LinkedIn

Adding ESLint to an Angular Micro Frontend architecture

Petar Garžina — Tue, 18 May 2021 13:47:21 +0000

Recently we moved our platform from a mono repo to a micro frontend architecture. One of the things we wanted to add was a base linter that is shared across our apps to ensure a more standardized code as both the platform and the number of micro applications expand.

In this post I'll share the basic rundown of the things we had to do in order to get the linter up and running.

1. Transition from TSLint to ESLint

As noted in the ng lint Angular Docs, TSLint is being deprecated in favor of ESLint. The migration is rather straightforward and boils down to these two lines:

installing the schematics

ng add @angular-eslint/schematics

and running the converter

ng g @angular-eslint/schematics:convert-tslint-to-eslint

For a more detailed migration guide, see this article: https://dev.to/gsarciotto/migrating-and-configuring-eslint-with-angular-11-3fg1

2. Add Super-Linter to GitHub Actions

Setting up Super-Linter was super easy, since we already had a workflows test-pull-req.yml file that tests our build on each pull request. Adding the linter was merely adding another step to the process.


name: Test And Lint Pull Request
on:
  pull_request:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
...
      - name: Lint Code Base
        uses: github/super-linter@v3
        env:
          NODE_ENV: production
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: main
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          LINTER_RULES_PATH: /
          TYPESCRIPT_ES_CONFIG_FILE: .eslintrc.js
          VALIDATE_TYPESCRIPT_ES: true
...

The Super-Linter docs are pretty self explanatory, the only additional thing we added here is the NODE_ENV variable, that will be used a bit later. The VALIDATE_ALL_CODEBASE variable came in nicely as the linter lints only files changed, so it makes adding new linter rules a bit more easier.

At this point you are good to go, you have migrated to the new ESLint and your files are being linted on each Pull Request. Tap yourself on the back!

3. Share and extend the base lint rules

Since we have around 10 applications, adding or changing a rule requires us to change it in each of the 10 applications; ain't nobody got time for that!

When we switched to the micro frontend platform we started utilizing our own Angular library for some of the configs, components, pipes and services that we use around the platform. We also keep a part of our Tailwind(❤) config in our libraries assets folder, so that was the obvious place to put our base lint config as well.

One thing to note here is, to make your library include the assets folder in the final dist you have to explicitly tell it to.

This happens in the libraries ng-package.json

{
  "dest": "../../dist/app-library",
  "assets": ["./assets"],
  "lib": {
    "entryFile": "src/public-api.ts"
  }
}

Now each application's eslintrc.js can reference and extend the base-eslint.js using the extends property

module.exports = {
 root: true,
 extends: [
   "./node_modules/@cognism/app-library/assets/configs/linter/base-eslint.js"
 ],
 ...
}

4. Add application specific rules

This is how our most basic eslintrc.js config looks like in one of our micro applications.

module.exports = {
 root: true,
 extends: [
   "./node_modules/@cognism/app-library/assets/configs/linter/base-eslint.js"
 ],
 overrides: [
   {
     files: ["*.ts"],
     rules: {
       "@angular-eslint/component-selector": [
         "error",
         {
           type: "element",
           prefix: "app-nav",
           style: "kebab-case"
         }
       ],
       "@angular-eslint/directive-selector": [
         "error",
         {
           type: "attribute",
           prefix: "appNav",
           style: "camelCase"
         }
       ]
     }
   }
 ]
}

As you can see, first we extend our base-eslint.js rules and then we override it with our application specific rules. In this case we just want to have application specific prefixes for both components and directives.

5. Add environment dependent rules

The idea here was to enable different rule behaviors depending on the environment. For example the console.log. We don't want the log statement committed to the main branch, but we also don't want to give out errors to developers while writing logs in their local environment.

The easiest way to do it was by simply using a ternary operator inside the lint file. Note that your config file must be in .js format and not in the default .json format to be able to do this.

module.exports = {
  ...
      rules: {
        "@typescript-eslint/naming-convention": [
          "error",
          { "selector": "enumMember", "format": ["UPPER_CASE"] }
        ],
        "@angular-eslint/no-empty-lifecycle-method": "off",
        "no-console": process.env.NODE_ENV === 'production' ? "error" : 'warn'
      }
   ...
}

As you can see, this is where the NODE_ENV kicks in which we defined in our GitHub Actions test-pull-req.yml file.

We did implement different environments this way, but are also aware that it might get messy with a lot of ternaries in different rules. If that comes to be the case, we ll just start using two files, eg. eslintrc.js and prod-eslintrc.js and the test-pull-req.yml file will always point to prod-eslintrc.js while in development we'll use eslintrc.js.

6. There you have it!

We used single-spa https://single-spa.js.org/ to move our monolith to the front-end microservices world.
The Angular version used was v11.
If you need any additional info feel free to reach out.
Any comments and improvements are welcome.

Feel free to connect 👋

Twitter | Instagram | LinkedIn