Forem: Dragoș Străinu

MacOS: notify when the terminal command is finished

Dragoș Străinu — Fri, 21 Apr 2023 09:04:17 +0000

After reading A decade of dotfiles I wanted to create a similar bash function to boop.

And here it is:

# ~/.zshrc
# ...rest of zshrc
,notify () {
  local last_exit_status="$?"
  if [[ "$last_exit_status" == '0' ]]; then
    osascript -e "display notification \"Done\" with title \"Good\" sound name \"Fonk\""
  else
    osascript -e "display notification \"Exit code: $last_exit_status\" with title \"Bad\" sound name \"Ping\""
  fi
  $(exit "$last_exit_status")
}

It uses osascript to execute the AppleScripts that pushes the notification.

According to stackoverflow
this is not the best way to pass bash variable to osascript,
but I did not understand how to do it for my use case and as I use last_exit_status there should be no problem.

usage:

npm run test;,notify

I prefix the function name with a comma to faster search for it when doing ;,<Tab>.

You can test it with (exit 0);,notify and (exit 1);,notify.

Stop doing git checkout master branch

Dragoș Străinu — Tue, 14 Mar 2023 13:19:58 +0000

I see a common workflow when starting to work on new task:

git checkout master
git pull # or git pull -r
git checkout -b feat/4605-new-task

But I do things a bit differently. The main difference is that I don't care about the local master branch because the source of truth is always remote origin/master.
I don't do commits on master branch, because all changes to the project are done through Pull Requests. So why should I keep the local master in sync with origin/master?

The first thing I do is fetch the remote master branch to get the latest commits.

I have an alias in my .gitconfig file:

[alias]
  fetch-and-clean-branches = "!git fetch -p && git branch -vv | grep ': gone]'|  grep -v "\\*" | awk '{ print $1; }' | xargs git branch -D"

How to locally delete all remotely merged git branches

Running git fetch-and-clean-branches, will fetch new updates on remote branches and will remove local branches that are not relevant anymore.

Next, I create a new branch based on origin/master:

git checkout -b feat/4605-new-task origin/master # --no-track

I also created an alias for this command:

[alias]
  fetch-and-clean-branches = "!git fetch -p && git branch -vv | grep ': gone]'|  grep -v "\\*" | awk '{ print $1; }' | xargs git branch -D"
  start = "!git fetch-and-clean-branches && git checkout -b \"$1\" --no-track origin/master #"

And I can use it as: git start feat/4605-new-task.

Related: How I use Git

How to gradually add an eslint rule

Dragoș Străinu — Wed, 18 May 2022 09:51:38 +0000

As your javascript project grows and new engineers are joining the team, you may try to add new eslint plugins and rules to make the code base more rigid.

The problem is that often these new eslint rules may require changes in all project files, and as your project is big enough, you may have a situation when eslint rules require changes in 2000+ files.

What if you could gradually enforce an eslint rule, without breaking the CI of your project.

We can do this using lint-staged, husky, and some changes in the .eslintrc.js file.

I hope you are already using lint-staged with husky. If not, please set up it.

Your .lintstagedrc.js file may look something like this:

// .lintstagedrc.js
module.exports = {
  '*.{js,jsx,ts,tsx}': ['prettier --write', 'eslint --quiet --fix'],
  '*.css': 'stylelint --fix',
  '*.md': 'prettier --write'
};

You may also have a script in your package.json file, that you run in CI to make sure eslint rules are followed:

...
"scripts": {
  "eslint:run": "eslint --ext=.js,.jsx,.ts,.tsx --quiet .",
}

Now let's say you want to enforce the removal of all console logs using the eslint rule no-console.

In your .eslintrc.js file, set the rule to warning:

// .eslintrc.js
module.exports = {
  ...
  rules: {
    'no-console': 'warn',
  ...

Now running npm run eslint:run will just show a bunch of warnings but will pass the check.
Next, you need to create a new eslintrc file that will be used only by lint-staged. Let's name it eslintrc-staged.js.
There you need to extend the default eslint config and override the rule to error.

// .eslintrc-staged.js
module.exports = {
  extends: './.eslintrc.js',
  rules: {
    'no-console': 'error',
  }
};

The last change needs to be done in .lintstagedrc.js to tell lint-staged to use another config file when running eslint.

module.exports = {
  '*.{js,jsx,ts,tsx}': ['prettier --write', 'eslint -c eslintrc-staged.js --no-eslintrc --quiet --fix'],
  '*.css': 'stylelint --fix',
  '*.md': 'prettier --write'
};

Now, when doing changes to the project, eslint will throw errors only to the files that were changed before the commit.

How I found a bug in 2000 files

Dragoș Străinu — Sun, 15 May 2022 09:28:22 +0000

I was adding a new eslint plugin that will sort imports in js/ts files.

After adding eslint-plugin-simple-import-sort,
I run eslint --fix and found about 2000 files changed.
As there was only reorder of imports I thought that there should not be any issues.

I was surprised when I found a very strange

TypeError: Cannot read properties of undefined

Reverting the import order did not help to fix the issue.

And now I started thinking about how I can find the issue without going through all 2000 files.

Then an idea came. As all changes are independent,
I could do a commit for every file change and then run a git bisect and find the file that causes the problem.

So I created a bash script that will get all file names from git status and create a commit with the file name:

Let's see how:

git status --porcelain # prints git status in a format that can be parsed
# M utils/index.ts
# M components/Button.tsx
# ...

Then we pipe this result to awk and print only the file name:

git status --porcelain | awk '{print $2}'
# utils/index.ts
# components/Button.tsx
# ...

read each line (filename), and do a commit with --no-verify to not trigger pre-commit check:

#!/bin/bash
(git status --porcelain | awk '{print $2}') | 
while read -r line
do
    git add $line
    git commit -m "Add file $line" --no-verify
done

After running this script I had about 2000 commits where I could run git bisect and find the issue.
git bisect reduced the number of checks from 2000 (theoretically) to just 11.

I found the file that caused the issue, and it was completely unrelated to the file where the error was thrown.
So I just eslint ignored the sorting rule in that file (till later investigation).
Then I did a soft reset to undo all 2000 commits and pushed a single commit that successfully adds the new eslint plugin and rules to the project.

NodeJS: How to test the npm package before releasing

Dragoș Străinu — Fri, 15 Apr 2022 00:00:00 +0000

Let's say you have a core package that is used in your app and mobile projects.

Now you need to do some changes, both in core and app.

In the process of local development, you should test that core is working correctly with app before the release.
You can use npm link, but from my experience, it's not always working as expected.

A better alternative is yalc. You can check it yourself, but shortly, as the package itself says:

Better workflow than npm | yarn link for package authors
After everything is working locally, you are ready to do a Pull Request.
But wait! The CI will fail because the new version of core is only available locally.

To fix this, we need a prerelease version of the core that will be installed in CI, or then other engineers will try it on their machines.

Let's, say the previous version of core was 1.0.1, and you are working on future 1.0.2.

Semver.org docs suggests to use 1.0.2-rc.1 (release candidate),
but this approach does not work well when you are working on a project where many engineers can release to core before you.

From my experience, the best is to have a prerelease version that is associated with some issue/ticket/task number in the format:

<current version>-<issue number>.<WIP version>

Example: 1.0.1-4605.0, 1.0.1-4605.1 ...

The important part before publishing such a prerelease version is to set a tag.
If you don't set a tag, the package will be published as latest,
and then someone will try to install the core package, it will get the wrong "latest" version which may still be WIP.

For this, you might use the dev tag.

So, the workflow

You do changes in core
Use the WIP version of core in app locally using yalc
When the task is ready:
- Change the version of core: 1.0.1-4605.0
- Publish the WIP version: npm publish --tag dev
- Update the app with WIP version of core
- Do move WIP prereleases if needed: 1.0.1-4605.1
Create PRs for both projects
When core PR is approved
- Merge core
- Set new version 1.0.2
- Publish core: npm publish (latest tag is default)
Update app PR with new version of core
Merge app changes into master
Happy coding

Keep your JavaScript repository clean

Dragoș Străinu — Sat, 09 Apr 2022 11:11:14 +0000

As your JavaScript project grows, you start adding more tools and settings that will improve the development experience.

Nowadays, tools like eslint, husky, and tests are essential for any project.

The problem is that most of these tools require a config file at the root of your project/repo.
After some time, the root directory is full of config files, and it's a bit intimidating when you open it in the git hub.

One elegant solution I found in remirror repo.
There all config files that should stay in the root of the project are actually in the ./support/root/ directory,
and they are locally symlinked when setting up the project.

Inspired by their approach I created symlink-config, which helps to migrate your project to this approach.

Here is how repo looks on Github before and after:

Default	With symlink-config

This demo has only 5 configs in the root, but imagine adding more tools, like tsconfig.json, jest.config.js, and others.

When exploring the project locally,
all these files will be in the root but being just a symlink file they will differ from the rest of the files and you may skip them visually.

In the end, I think this tool is useful for big open source projects with a lot of config files, as it cleans up the entry point of the project (the repo root) and makes it more appealing to users.

Check out symlink-config, and let me know your opinion!

Optional pre-commit checks with husky

Dragoș Străinu — Fri, 01 Apr 2022 09:48:14 +0000

If you are working on a JavaScript project, you probably are using husky to check your commit messages,
maybe do some Prettier, Eslint formatting, or TypeScript checks.

Checking commit messages is fast, but running formatting and type checking takes more time as your project grows.

You can use lint-staged for prettier and eslint,
but using it for TypeScript check makes no sense because if you change types in a git staged file it may break typing in another file.

All engineers have different workflows. To fix an issue from the TypeScript compiler, you could run a tsc --watch process and make sure nothing is broken.

I don't want to run tsc --watch because constantly running it slows the laptop. I don't mind if this check will be done at pre-commit stage even if the commit will take 10,20,30+ seconds.

But how to make this pre-commit optional? So the teammates that do manually formatting and type checking will not be frustrated.

husky version 7 enables pre-commit configuration using a bash script. So why not do checking before running tsc or lint-staged?!

This will be the beginning of the .husky/pre-commit file

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

APP_PRE_COMMIT_OPTIONS="$(dirname "$0")/_/pre-commit.options"

So we can put our options in a file named pre-commit.options inside the .husky/_/ folder.

.husky/_/ should have a .gitingore file that will ignore our option file.

Next, let's print some message if the options files do not exist

YELLOW="\033[1;33m"
GREEN="\033[1;32m"
RESET="\033[0m"
if ! [ -f "$APP_PRE_COMMIT_OPTIONS" ]; then
  echo "${YELLOW}\nSkipping pre-commit hook."
  echo "If you want to use pre-commit for TypeScript check and lint-staged, run:\n"
  echo "  ${GREEN}echo -e 'APP_TS=true;\\\nAPP_LINT=true;' > $P_APP_PRE_COMMIT_OPTIONS${RESET}"
  echo ${YELLOW}\nIt will add some delay before committing!\n${RESET}"
  exit 0
fi

Now, let's source the options file and check if the user enabled the linting:

source $APP_PRE_COMMIT_OPTIONS

if [ -n "${APP_LINT}" ] && [ "${APP_LINT}" == "true" ]; then
  echo "${GREEN}[husky] [pre-commit] [lint-staged]${RESET}"
  npx lint-staged
fi

You can add more options and checks if needed!

Final result

The .husky/pre-commit file should look similar to this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

APP_PRE_COMMIT_OPTIONS="$(dirname "$0")/_/pre-commit.options"

YELLOW="\033[1;33m"
GREEN="\033[1;32m"
RESET="\033[0m"
if ! [ -f "$APP_PRE_COMMIT_OPTIONS" ]; then
  echo "${YELLOW}\nSkipping pre-commit hook."
  echo "If you want to use pre-commit for TypeScript check and lint-staged, run:\n"
  echo "  ${GREEN}echo -e 'APP_TS=true;\\\nAPP_LINT=true;' > $P_APP_PRE_COMMIT_OPTIONS${RESET}"
  echo ${YELLOW}\nIt will add some delay before committing!\n${RESET}"
  exit 0
fi

source $APP_PRE_COMMIT_OPTIONS

if [ -n "${APP_TS}" ] && [ "${APP_TS}" == "true" ]; then
  echo "${GREEN}[husky] [pre-commit] [tsc]${RESET}"
  npx tsc
fi

if [ -n "${APP_LINT}" ] && [ "${APP_LINT}" == "true" ]; then
  echo "${GREEN}[husky] [pre-commit] [lint-staged]${RESET}"
  npx lint-staged
fi

NPM: How to document your package.json scripts

Dragoș Străinu — Sun, 27 Mar 2022 17:13:28 +0000

As your project grows you add more scripts to package.json.
When a new member joins the project (or maybe you come back after a break) it's hard to understand from the script itself,
what it is doing and why it was created, especially when the script is 80 chars long with a lot of params and &&.

Let's see what we do about this:

README.md

You could add documentation for the scripts in a section of the README.md file.

## NPM scripts

- **start**: Description for `npm start` script
- **test**: Description for `npm test` script
...

👍This approach is nice because you can use the markdown rich text features. Also, the README file is the first file opened by a new member of the team.

🙁A downside of this approach is that when you see a script in package.json you need to open the README, then do back to package.json or terminal (to run the command).

package.json

Npm does not support JSON5 for package.json that could allow comments in JSON for example in tsconfig.json.

There is a popular question on StackOverflow on the topic:

How do I add comments to package.json for npm install?

You can read all proposed variants (and discussions) on StackOverflow. One option that could be ok is:

{
  "name": "package name",
  "version": "1.0",
  "description": "package description",
  "scripts": {
    "start": "npm install && node server.js"
  },
  "scriptsComments": {
    "start": "Runs development build on a local server configured by server.js"
  },
  ...
}

👍This approach is nice because script documentation stays closer to the script itself.

🙁The downside: as your package.json grows with more scripts, dependencies, other tools configs it's very easy to get lost.

npx why

npx why is a tool created to fix the problem of documenting package.json scripts.

If we have to run the scripts from the terminal, why not have the documentation for the scripts in the terminal?

npx why --init will create a package-why.json in the root of the project with all scripts from package.json and the default descriptions.

After this, calling npx why will print all scripts and descriptions.

npx why <some script name> will print only description for npm run <some script name>.

You could update the documention by passing a description to npx why <some script name> "<script description>". Or changing package-why.json file directly.

For better experience I suggest installing the package as a development dependency:

npm install why --save-dev

🎉This solution for documenting the script is nice because you access the docs from the terminal (where you have to use the script).
Also I am sure that with new updates and features the experience of using why will get better and better.

🙁The downside: the process of documenting script is not so comfortable because you have to move between package-why.json and package.json files.

Check out npx why package.

You need to use Git worktree

Dragoș Străinu — Wed, 16 Mar 2022 14:03:44 +0000

Recently I found git worktree feature and I plan to use it in all my projects.
Here is why and how you can use it.

Why

If you are working on a big project with a lot of issues and tasks, you constantly have to switch between branches to do some quick-fix changes or maybe review a PR from a teammate.
The problem is that often you have some work in progress and switching branches means that you need to commit or stash your WIP changes.
If it's only 1-2 files/changes the cost of commit/stash is not that high. But if you work on a big feature with over 9000 changes it's hard to constantly change branches.

How

Basically git worktree command allows to create a new directory with desired git state.

Actually, your current workspace is already in git worktree.

You can type git worktree list and you will see one item, which is your current git workspace.

Let's say you work on a big feature in your work project.

git worktree list
~/Work/project  17d8aab [big-feature]

And a quick-fix needs to be done from the origin/master.
You can create a git worktree with the following command:

git worktree add -b quick-fix ../quickfix origin/master

This command will create a new directory named quickfix at the same level as your project directory.

The branch will be quick-fix and it will be set at commit from origin/master.

You can see your git worktree:

git worktree list
~/Work/project   17d8aab [big-feature]
~/Work/quickfix  25e6c4b [quick-fix]

Next, you can navigate to quickfix directory, do your changes, push to remote, merge.

After you are done with quickfix you can remove the workspace with git worktree remove quickfix.

Conclusion

This approach of using git worktree is not the most elegant but it's doing the job.
I might change the workflow (using bare git repos instead of normal repos) and will update this post.
For now you may check How to use git worktree and in a clean way.

But I suggest to play a bit with git worktree if you have problems from Why section. And adding this git feature to your toolkit will make you a more productive engineer.

Let me know if you have a nice workflow for git worktree!

Use Caps Lock to trigger iTerm2 terminal

Dragoș Străinu — Tue, 22 Feb 2022 09:33:50 +0000

A long time ago someone showed me that it's possible to add a hotkey to iTerm2 to open the terminal window from anywhere in the system. Till these days I was using ` key as a hotkey. But when having to input ` in markdown or JS I had to use Option + ` which has specific behavior.

I decided to try Caps Lock for a while (as Caps Lock is one of the useless keys on the keyboard).

The issue is that iTerm2 does not recognize the Caps Lock press. So I have to remap in MacOS Caps Lock to Control key.

Go to System Preferences > Keyboard:

Select Modifier Keys:

Set Caps Lock as Control key:

Go to iTerm, System Preferences > Profiles > Select profile > Keys > Configure Hotkey Window:
Set Double-tap key as Control

Now when you double press Caps Lock (or Ctrl) the iTerm window will popup.

Nudge Github PR reviewers with Slack API

Dragoș Străinu — Thu, 17 Feb 2022 20:21:44 +0000

You know that moment when you have a Pull Request waiting for someone to review but days pass and no one is looking at it, so you have to manually ask reviewers in a public channel or privately. How we can automate this?

Previously I was using Bitbucket and Bitbucket Cloud have a cool feature to nudge reviewers from Slack and it will send a private message notifying reviewers to take a look at the Pull Request.

Now I am using Github with Github for Slack and it has a feature to remind reviewers at a specific time of the day about PRs. But I could not find a nudge reviewer feature. I searched on the Slack app store but still had no success.

I decided to do an MVP for my project and team, not publicly available, but you can create the same feature for your project/team/company.

Slack App

To publish messages to Slack workspace you need to create a Slack App.

Click Create New App button
Pick From scratch
Set App Name to <Company name> PR nudge (or any other suitable name)
Pick your company workspace
Press Create App

Next, we need to create a webhook for a Slack channel.

In Add features and functionality section select Incoming Webhooks
Click Add New Webhook to Workspace and select a channel where all messages from Github for Slack goes (Usually this channel is named #dev)

Now we have a webhook that will post messages to our channel, next we need to call this webhook from somewhere.

Userscript

Let's build a userscript that will add a Nudge reviewers button into Github PR page, that when clicked will nudge in Slack, reviewers that are awaited for review.

If you don't know about userscripts you can check my explanation video: You Don't Know *.user.js.

First, your need a Userscript manager extension, let's install Tampermonkey.
After installation open Tampermonkey and create a new script.

Userscript Header

We start with:

// ==UserScript==
// @name         <Your Company> PR nudge
// @namespace    https://github.com/<Your Company>
// @version      1.0.0
// @description  Nudge PR reviewers
// @author       You
// @match        https://github.com/<Your Company>/*/pull/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=github.com
// @grant        GM_xmlhttpRequest
// @connect      slack.com
// ==/UserScript==
(function () {
  "use strict";
  // Your code here...
})();

We need:

@match https://github.com/<Your Company>/*/pull/* to run the script only when navigating to a PR page, such as https://github.com/Org/Repo/pull/4605
@grant GM_xmlhttpRequest to do requests to Slack webhook
@connect slack.com to allow requests to Slack

Nudge reviewers button

Now let's create a Nudge reviewers button and add it to the Reviewers section:

(function () {
  "use strict";
  const PR_NUDGE_WEBHOOK =
    "https://hooks.slack.com/services/********/***********/************************";
  const nudgeButton = document.createElement("button");
  nudgeButton.innerText = "Nudge reviewers";
  nudgeButton.className =
    "btn btn-sm js-details-target d-inline-block float-left float-none m-0 mr-md-0 js-title-edit-button";
  const reviewersFormElement = document.getElementById(
    "reviewers-select-menu"
  ).parentElement;
})();

Who needs to review

This function will return a list with Github nicknames that should review this PR.

function getAllAwaiting() {
  const allReviewers = Array.from(reviewersFormElement.querySelectorAll("p"));
  const awaiting = allReviewers.filter((reviewerEl) =>
    reviewerEl
      .querySelector("span[aria-label]")
      .getAttribute("aria-label")
      .startsWith("Awaiting")
  );
  const awaitingNicknames = awaiting.map(
    (reviewerEl) => reviewerEl.querySelectorAll("a")[1].innerText
  );
  return awaitingNicknames;
}

Mapping Github user with Slack user

Here is a sad part of this script, because we need to map Github with Slack, to know whom to nudge on Slack.
At this point, this is a manual process and this is the only downside of this solution.

(function () {
  "use strict";
  const GithubSlackMap = {
    strdr4605: "U**********",
    ...
  };
  const PR_NUDGE_WEBHOOK =
  ...

To find the member ID from Slack, go to a Slack user profile, click More, and click Copy member ID.
If you have 30+ engineers in your team it may take a while. For me, it was 11 engineers.

If you have an idea how to automate this, let me know.

onNudgeBtnClick

Now let's gather all the data and sent a request to Slack webhook.
Slack has a specific format style for messages, so to tag people we need slackMention function.

function slackMention(githugNickname) {
  return GithubSlackMap[githugNickname]
    ? `<@${GithubSlackMap[githugNickname]}>`
    : githugNickname;
}
function onNudgeBtnClick(e) {
  e.preventDefault();
  const prLink = window.location.href;
  const prTitle = document.title.split(" by ")[0] || prLink;
  const awaitingReviewers = getAllAwaiting();
  if (!awaitingReviewers.length) {
    return;
  }
  const dataObj = {
    text: `Hey ${awaitingReviewers.map(
      slackMention
    )},\nI really need your review on <${prLink}|${prTitle}>. 🥺😇🙏😊`,
  };
  GM_xmlhttpRequest({
    fetch: true,
    method: "POST",
    url: PR_NUDGE_WEBHOOK,
    data: JSON.stringify(dataObj),
    responseType: "json",
    nocache: true,
    onload: (response) => console.log({ response }),
    onerror: (err) => console.error({ err }),
  });
}

Add button to the page

nudgeButton.addEventListener("click", onNudgeBtnClick);
setTimeout(() => {
  reviewersFormElement.appendChild(nudgeButton);
}, 1000);

Final result

// ==UserScript==
// @name         <Your Company> PR nudge
// @namespace    https://github.com/<Your Company>
// @version      1.0.0
// @description  Nudge PR reviewers
// @author       You
// @match        https://github.com/<Your Company>/*/pull/*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=github.com
// @grant        GM_xmlhttpRequest
// @connect      slack.com
// ==/UserScript==
(function () {
  "use strict";
  const GithubSlackMap = {
    strdr4605: "U**********",
    ...
  };
  const PR_NUDGE_WEBHOOK =
    "https://hooks.slack.com/services/********/***********/************************";
  const nudgeButton = document.createElement("button");
  nudgeButton.innerText = "Nudge reviewers";
  nudgeButton.className =
    "btn btn-sm js-details-target d-inline-block float-left float-none m-0 mr-md-0 js-title-edit-button";
  const reviewersFormElement = document.getElementById(
    "reviewers-select-menu"
  ).parentElement;
  function getAllAwaiting() {
    const allReviewers = Array.from(reviewersFormElement.querySelectorAll("p"));
    const awaiting = allReviewers.filter((reviewerEl) =>
      reviewerEl
        .querySelector("span[aria-label]")
        .getAttribute("aria-label")
        .startsWith("Awaiting")
    );
    const awaitingNicknames = awaiting.map(
      (reviewerEl) => reviewerEl.querySelectorAll("a")[1].innerText
    );
    return awaitingNicknames;
  }
  function slackMention(githugNickname) {
    return GithubSlackMap[githugNickname]
      ? `<@${GithubSlackMap[githugNickname]}>`
      : githugNickname;
  }
  function onNudgeBtnClick(e) {
    e.preventDefault();
    const prLink = window.location.href;
    const prTitle = document.title.split(" by ")[0] || prLink;
    const awaitingReviewers = getAllAwaiting();
    if (!awaitingReviewers.length) {
      return;
    }
    const dataObj = {
      text: `Hey ${awaitingReviewers.map(
        slackMention
      )},\nI really need your review on <${prLink}|${prTitle}>. 🥺😇🙏😊`,
    };
    GM_xmlhttpRequest({
      fetch: true,
      method: "POST",
      url: PR_NUDGE_WEBHOOK,
      data: JSON.stringify(dataObj),
      responseType: "json",
      nocache: true,
      onload: (response) => console.log({ response }),
      onerror: (err) => console.error({ err }),
    });
  }
  nudgeButton.addEventListener("click", onNudgeBtnClick);
  setTimeout(() => {
    reviewersFormElement.appendChild(nudgeButton);
  }, 1000);
})();

Now when clicking Nudge reviewers your teammates will be notified and will review your changes faster.

Final step

Don't expose webhook URL to the public!

Add the script to a private repo(company-userscripts) in your Github org.
Name it PR-nudge.user.js.

Tell teammates to install Tampermonkey and send them:

https://github.com/Org/org-userscripts/blob/master/PR-nudge.user.js?raw=1

to add the script on their machine.

Git: hide specific branch when doing git log --all

Dragoș Străinu — Thu, 17 Feb 2022 20:21:23 +0000

I deploy https://strdr4605.com on Github pages. Deployment and hosting are on gh-pages branch.
When doing my usual check of branch status and history using:

git log --oneline --all --graph

I faced this problem:

I see a very long list of commits on gh-pages branch and I need to scroll down to see my other branches.

Solution

You can hide a specific branch using --exclude option for git log. Now my command looks like this:


git log \
--oneline \
--graph \
--exclude=refs/remotes/origin/gh-pages \
--all

Now it looks better:

You can add this command in a git alias.

If needed check here for more things to exclude from git log.

You can check why I prefer to do long commands instead of git aliases at How I use Git.