Tasks

This week, for the Starchart project, I added some explanation to how to create releases in GitHub repo, and I added some tests too.

I wanted to mention how to create releases because I noticed multiple people have been asking how to do it. It seems like a good idea to add some pointers in the wiki.

As for test, thing are quite usual except one interesting bug I found. (PR)

Create GitHub Releases

This is about making a release version of your application from your GitHub repo, in the repo's release page. This will generate copies of the source code for download, in the release.
GitHub has documentation on how to manage releases, including creating one.

The Page to create a release looks like this:

Assuming you have the access, you do it by:

1. Click "Releases" on a repo's main page, then click "Draft a new release" to get to the page shown.
2. Choose or create a tag, which can be a version.
3. Choose a branch, which might be main.
4. Give it a title and some description of what's added/changed. You can click "Generate release notes" to get some information from GitHub, including contributors, change log, and newly committed PRs.
5. You can set it as pre-release or latest release. You can even allow discussion under the release note. 6.(Optional) You can attach some files to the release.

As part of making a release, you might increment project version for a release. You can use CLI command npm version in the project directory.

For example, assuming you have initialized npm and git, npm version 0.8.0 -m "sample commit" will change the version in package.json and create a new commit with the commit message sample commit by -m option. This new commit will have a tag v0.8.0, which you can use for creating a release.

NOTE: locally created tags don't exist on GitHub repo unless you push them. To push the commit with the tag, you can push with --tags flag, such as git push origin main --tags. For more information on tags, see here.

Odd Bug

While writing a test, I noticed an odd behavior when I tested this code:

export function setIsReconciliationNeeded(
  reconciliationNeeded: SystemState['reconciliationNeeded']
) {
  try {
    return prisma.systemState.update({
      data: { reconciliationNeeded },
      where: { unique: StateEnumType.unique },
    });
  } catch (error) {
    return initialize();
  }
}

The code is meant to update a row in the SystemState table, to set reconciliationNeeded field by the parameter, which is Boolean (True/False). It uses Prisma's Update function to do the update.
The main and interest point is that this try block will not catch errors throw by [Update] when it fails to find such row, such as when it simply doesn't exist.
Given that the documentation states the function returns the exception when it can't find the target to update, my guess was that it's returning the error from the function with the return keyword, which makes the error land outside of the try block.

The expected behavior is to catch the error and then call and return initialize.
Therefore, I tried to avoid having return in the try block by doing it later:

export async function setIsReconciliationNeeded(
  reconciliationNeeded: SystemState['reconciliationNeeded']
) {
  let result;
  try {
    result = await prisma.systemState.update({
      data: { reconciliationNeeded },
      where: { unique: StateEnumType.unique },
    });
  } catch (error) {
    return initialize();
  }
  return result;
}

This way, the try block properly catches the error and execute the catch block.
Alternatively, a teammate come up with another solution:

export function setIsReconciliationNeeded(
  reconciliationNeeded: SystemState['reconciliationNeeded']
) {
  return prisma.systemState
    .update({
      data: { reconciliationNeeded },
      where: { unique: StateEnumType.unique },
    })
    .catch(() => {

      return initialize();
    });
}

This one instead deal with the error before the code hits return. The error is caught in catch and dealt with, before anything goes to return.