memorandum

When I want to come and go several project windows frequently, if I use VSCode then using vscode-ghq and switching window is enough for me. But if I need to work on terminals, I'd rather want to use terminals like iTerm2 than terminal in VSVode.
I wanted to do like what I do in VSCode, but I used to do operations like below.

1. Find the target repository from the opened windows (relying on my memory).
2. If the target repository is opened in some window, then switch to it.
3. Otherwise, create a window with prefix + c on tmux and move to it by using ghq.

In this article, I will explain how to do following operations with just 1 command.

1. Show a list of repository with ghq from any windows.
2. Find the window which directory is the selected repository.
3. If the target repository is opened in existing window, then move to it.
4. Otherwise create a new window, move to it, and change the directory to that of selected repository.

There is an audit item named Image elements have explicit width and height in Lighthouse.
Its detail is described in Images without dimensions, which says that setting width and height attributes to <img> tag improves CLS (Cumulative Layout Shift).

However, in nuxt/content, it seemed that they are not set automatically when the images are specified with ![](URL) notation. So I created a rehype plugin named rehype-img-size and let it set image size attributes automatically by reading files.

I've been created my blog with nuxt/content, but I couldn't have improved the Performance score of Lighthouse (or PageSpeed Insight) from about 80 points.
It seemed TTB (Total Blocking Time) was bad and I found that loading JavaScript files is the cause, and this time I dealt with this and finally improved the Performance score to 100 points!

I'm exploring the possibility of using GitHub Actions to do a little automation in development around pull requests.
In repositories where there are many people coming and going, or where people only develop occasionally, I think it would be difficult to let people read and follow something like a development workflow, even if it is carefully documented.
I think it would be more effective to prepare something that indicates or forces next action according to the progress of development.

Based on that kind of thoughts, I tried to create an action to comment on a pull request when it is approved and become mergeable.
With this comment, developers are able to recognize what they should do before or after merging it.
The following is an image of a bot commenting on a pull request when it is approved.

Continuation of Migrating blog to nuxt/content - 2. generate description automatically.
Finally I could migrate past posts and show list like Blogger, and I tested performance with PageSpeed Insight. But it was just 33 points...!
I think the main cause is that the top page has a list of posts with first half of each post by using v-html and ClientOnly, which causes bad DCL (DOMContentLoaded) and LCP (Largest Contentful Paint).
CLS (Cumulative Layout Shift) was also large; it seems that putting contents with JavaScript later causes layout shift.

I searched VuePress related topics about this issue, but couldn't find it.
It seems difficult to resolve this issue unless I choose the framework that has features so-called SSG.

Then some examples of using nuxt/content catched sight of me. I gave it a shot and felt like very good, so I decided to switch to it after some experiments for features that are needed for my requirements.

Continuation of the last post Migrate blog to nuxt/content - 1. migration of old posts.

There is no description header in the frontmatter of the posts, so the summary of the posts cannot be displayed in the post list on the top page.

I've been migrating my blog from Blogger as written in Migrating my blog and implementing with VuePress.
There had been no problem for writing new posts, but when it comes to migrate old posts, I had an issue, and eventually I switched from VuePress to nuxt/content.
Why do I keep changing my blog for a long time, though I don't have much passion for studying frontend? I don’t even know the answer.
But I could have migrated it finally, so I'd like to look back.

I thought that each blog post having .html suffix is not good when I migrate my blog to other system in the future, so I investigated if there is an option to change this.

How do I remove .html suffix?

I thought markdown.pageSuffix option fits this purpose, but it wasn't.
It is an option for embedded URL inside Markdown, and actually page.path on the post list Component has .html suffix even if this option is set.
There is an open issue SEO friendly URLs · Issue #78 · vuejs/vuepress, but it has not been proceeded.
I found that there is a workaround for this, so I followed this steps: moving path.md to path/README.md to change the generated path from path.html to path/index.html.

When I was building this blog on my local environment, there was no issue around date, but after I changed the workflow to deploy the blog from local to GitHub Actions, it seems last updated date became current date, so I fixed it.

What happend?

I found that date on my blog was strange after I deployed my blog.
On top page, all dates were the same.
I first guessed that it was because I updated page list component, but each page also had the issue.

It worked on my local environment, so I thought there is something wrong around build process.

There are important files in the project root dirctory that affect to the whole project such as configuration files which names start with ..
I thought it might be meaningful to apply CODEOWNERS file to those project root files.

Test with machine user

To test this, I need multiple users but I can't create another user that can be manually operatable on GitHub.
GitHub allows us to create a machine user that can be used for CI, so I tested the expected files are required to be approved by code owner if the machine user create a pull request automatically.