Forem: WH yang

My Solution to Deno Watch Mode Signal Handling

WH yang — Sun, 14 Dec 2025 06:13:01 +0000

To fix the Deno watch mode issue, I researched both Deno and Node.js. I want to use Node.js's approach but implement it in Rust for Deno.

Rust doesn't have a built-in process.kill() function like JavaScript to send signals, but we can simulate this using channels. When creating a channel, we get a sender (Tx) and a receiver (Rx) that work together, which helps avoid race conditions.

I created a pull request (PR) that uses a channel to allow the worker process to inform the watcher process when the INT signal is handled, instead of letting the watcher process handle and ignore it.

Here’s how I set it up:

// Create a channel before starting the worker process
let (ctrl_c_tx, mut ctrl_c_rx) = tokio::sync::mpsc::unbounded_channel::<()>();

let watcher_communicator =
    Arc::new(WatcherCommunicator::new(WatcherCommunicatorOptions {
      // Pass the sender to the worker
      ctrl_c_tx: ctrl_c_tx.clone(), 
    }));

impl WatcherCommunicator {
   // Public function to inform the watcher process
   pub fn handle_ctrl_c(&self) -> Result<(), SendError<()>> {
     self.ctrl_c_tx.send(())
   }
}

I also removed the INT handler from the watcher process and replaced it with the channel's receive handler:

// _ = deno_signals::ctrl_c() => {
    _ = ctrl_c_rx.recv() => {

This approach requires a better understanding of how the signal API is implemented in Deno. The Signal.rs file shows how the Deno.addSignalListener() or process.on(signalName, callback) API works. I'm still looking for the right place to trigger the channel sender without breaking existing behavior.

Implementing this feature has been the most challenging task I've faced recently. Three months ago, I had never written a line of Rust, but now I'm working on something significant written in Rust. I can't believe how far I've come since starting my open-source journey. I want to thank my professor, humphd, for encouraging everyone in class to get involved in the open-source community. Everyone has grown so much this semester; this has been the best course I've taken.

Update on Deno Watch Mode Signal Issue.

WH yang — Sun, 14 Dec 2025 04:34:05 +0000

There is an issue in Deno where the signal handler doesn't work in watch mode. I believe this happens because the Deno file watcher doesn't send the INT signal to the worker, causing it to just stop instead. I'm confident about this now.

source

 select! {
      _ = receiver_future => {},
      _ = deno_signals::ctrl_c() => {
        return Ok(()); // this line handled the INT signal and fulfilled select!
      },
      _ = restart_rx.recv() => {
        print_after_restart();
        continue;
      },
      success = operation_future => {...}

In the Deno code, the select! statement acts like JavaScript's Promise.any. It completes as soon as the INT signal is ignored. The operation_future runs the user's JavaScript or TypeScript files, but it doesn't get a chance to activate the user-defined listener.

I also looked at how Node.js handles signals in watch mode. It sends the signal to the worker and waits for the worker to finish.

source

async function killAndWait(signal = kKillSignal, force = false) {
  child?.removeAllListeners();
  if (!child) {
    return;
  }
  if ((child.killed || exited) && !force) {
    return;
  }
  const onExit = once(child, 'exit');
  child.kill(signal);
  const { 0: exitCode } = await onExit;
  return exitCode;
}

I plan to use a similar approach: send the signal to the worker to trigger the listener and then wait for it to complete.

The Difference of Deno and Node Handle Signals in Watch Mode

WH yang — Sat, 13 Dec 2025 05:15:29 +0000

I recently started learning Rust and tried to contribute to some projects that use it, specifically Andromeda and Deno. Both projects are JavaScript/TypeScript runtimes and have some problems with their watch mode.

This issue shows how the two runtimes behave differently. When using Node.js in watch mode, it handles the INT signal correctly, but Deno just exits without doing that. This can lead to some resources not being released properly. I plan to submit a pull request (PR) to fix this issue because I have worked on related PRs before.

I think the problem is that Deno doesn’t pass the INT signal to the process running the JavaScript/TypeScript code, so it just stops immediately.

I found some notes left by developers about three years ago while exploring the repo. While exit codes and signal handling aren’t the same, both should be managed properly for the JavaScript/Rust processes. I will keep trying to figure this out.

// TODO(bartlomieju): this function is not handling `exit_code` set by the runtime
// code properly.
async fn run_with_watch(

Enhance Deno.watchFs

WH yang — Fri, 12 Dec 2025 15:37:59 +0000

Deno has a built-in API called watchFs that tracks changes in files and folders. It can also watch subfolders automatically. However, some files, like those in the .git folder, change a lot. It would be helpful to have an "ignore" option that skips events from .git and its subfolders. I found this issue suggesting this idea.

I created a pull request for this new ignore option. This update changes fs_events.rs, which is the Rust code behind the Deno.watchFs API. My update checks if an event belongs to any ignored paths. If it does, it won’t send that event back to the JavaScript layer.

  let ignore = ignore.iter().any(|path| {
            event.paths.iter().any(|event_path| {
              same_file::is_same_file(event_path, path).unwrap_or(false)
                || starts_with_canonicalized(event_path, path)
            })
          });
 if !ignore && paths.iter().any(|path| { ... }

The original proposal also mentioned that watching a folder with many nested subfolders can be slow. I tried a different method that manually walk each folder and creates watchers but skips ignored paths. However, this method was slower than the simple filter I implemented. Managing multiple file watchers is less efficient than one that watches everything at once for OS. Also, new folders won't be detected if they weren't included in the initial walk.

Deno CLI Not Parsing Options After Target Files

WH yang — Tue, 25 Nov 2025 20:17:32 +0000

Deno Overview

Deno is a JavaScript and TypeScript runtime built with Rust. It offers a better development experience with built-in tools like a linter, formatter, and test runner. Deno is also compatible with Node.js and npm.

Breaking Changes in Deno 3.0

In version 3.0, Deno introduced a change for command-line arguments. Users now need to put -- before their arguments to avoid confusion. You can find more details in these issues: Issue 31295 and Issue 30334.

Example from Version 2.5.6

Here’s how it worked in version 2.5.6:

Command with --output ignored:

   ❯ deno compile --output output tests/testdata/compile/args.ts -- abcd
   Compile file:///Users/phillips/Repo/deno/tests/testdata/compile/args.ts to output

   Embedded Files

   output
   └── args.ts (224B)

   Files: 1.61KB
   Metadata: 1.29KB
   Remote modules: 12B

Command with -- correctly parsed:

   ❯ deno compile tests/testdata/compile/args.ts --output output -- abcd
   Compile file:///Users/phillips/Repo/deno/tests/testdata/compile/args.ts to args

   Embedded Files

   args
   └── args.ts (224B)

   Files: 1.63KB
   Metadata: 1.31KB
   Remote modules: 12B

In the second example, the --output option was ignored and treated as an argument, which was not what users expected.

Fixing the Issue

A PR was made to fix this issue in version 2.5.6. The change removed a line of code that caused everything after the .ts or .js file to be considered an argument. Instead, it added a new rule to make sure anything after -- is treated as an argument for the script.

A test case was also created to check that arguments after -- are parsed correctly. However, it didn’t test if options after the target file would affect execution, as seen in Issue 30334:

deno compile main.ts --output output

To address this, I submitted another PR to add a test case ensuring that the order of arguments doesn’t affect the execution result.

Conclusion

My journey through these issues and pull requests was quite interesting. When I joined the project, Issue 31295 was already open. I tried to help, but my question led the maintainer to realize the issue had been solved. I discovered another related issue that lacked a test case, which allowed me to contribute in a way I hadn’t planned, but it was still enjoyable!

Version 1.0.0 Released! My Repo Extraction Tool is now available on NPM!

WH yang — Sat, 22 Nov 2025 22:53:28 +0000

🎉 Exciting News! My project, repoal, has just launched its first version on NPM! You can install it using:

npm install -g @whyang9701/repopal

or run it directly with:

npx @whyang9701/repopal

How I Published on NPM

Choosing a Name:
- I decided to use a scoped name for my project. This means it will be associated with my username.
- For example, an unscoped package like vue is just a project name and can't be reused. In contrast, a scoped package like @vue/shared is linked to the Vue organization.
- I went with a scoped name to avoid confusion and connect it to me.
Automating the Publish Process:
- I used GitHub Actions to automate my publishing. GitHub has a tutorial that shows how to set this up.
- I modified the YAML file to trigger the publish process when I create a new git tag:

   name: Node.js Package

   on:
     push:
       tags:
         - 'v*'
   jobs:
     ...

To update the version and push the tag, I run:

   npm version 1.0.0
   git push && git push --tags

This automation will kick in every time I update the version.

Adding Provenance Statements:
- I also added a feature for provenance statements, which help verify where the package was built and who published it. This can enhance security.
- NPM provides a tutorial on how to do this.
- In my GitHub Actions YAML, I made two updates:
  - Allow the runner to read the repo and use my ID token for verification:
```
 ...
     runs-on: ubuntu-latest
     permissions:
       contents: read
       id-token: write
     steps:
     ...
       - run: npm publish --provenance --access public
```

Visual Confirmation

Here's a green check mark that shows my publish comes with provenance statements!

This check mark indicates that my package has verified information, improving supply-chain security.

Meet GitHub Actions

WH yang — Sat, 15 Nov 2025 18:03:39 +0000

Continuous Integration (CI) with GitHub Actions

What is CI?

Continuous Integration (CI) is a process that automatically tests the latest code to ensure everything works as expected. There are many ways to set up CI, but I find GitHub Actions the easiest to use when hosting a project on GitHub.

Why Use GitHub Actions?

GitHub Actions runs your project's tests automatically whenever you need it. For example, it can trigger tests when you:

Push a new commit
Open a pull request

This ensures that any new changes won’t break existing features. It gives me confidence before merging anything into the main branch.

Is It Free?

For public repositories: GitHub Actions is completely free.
For private repositories: You can still configure self-hosted runners and use them for free.

How to Set It Up?

Enable GitHub Actions

Go to your repository, click the "Actions" tab, and enable it.
Add a YAML Configuration File

Create a .yml file inside the .github/workflows folder. Here's an example from my Repopal project:

   name: Node.js CI

   on:
     pull_request:
       branches:
         - main
     push:
       branches:
         - main

   jobs:
     build:
       runs-on: ubuntu-latest

       steps:
         - uses: actions/checkout@v4
         - uses: volta-cli/action@v4
         - run: npm ci --no-audit
         - run: npm run lint --if-present
         - run: npm run prettier:check --if-present
         - run: npm test
         - run: npm run build --if-present

Optimize Your Workflow Use options like --silent or --no-color in your commands to speed things up and reduce unnecessary output. If any command fails (returns a non-zero exit code), the job will be marked as failed.

GitHub also provides step-by-step tutorials to help you get started.

What’s Next?

Once your CI is up and running, you can focus on improving it:

Increase Test Coverage: Add more tests to cover different scenarios.
Static Code Scanning: Use tools like GitHub CodeQL (built-in) or third-party options like SonarQube to scan your code for issues.

Security is just as important as functionality, so integrating automated security checks is a great next step.

Hacktoberfest 2025

WH yang — Mon, 10 Nov 2025 18:01:04 +0000

Hacktoberfest is a yearly event by DigitalOcean that supports the open source community. Many things we use every day rely on open source software. For example, Android and cloud servers use Linux, while Macs is part of BSD family. GitHub, owned by Microsoft, is the most popular site for storing open source projects and has many features for collaboration.

My Pull Requests (PRs) in Hacktoberfest

When I made my first contribution to open source, I felt nervous. I worried about making mistakes, wasting someone’s time with my pull request (PR), or not following the community rules. I spent a lot of time looking for issues I felt confident I could solve. However, I found that I needed to understand the projects better before I could tackle any issues. Even the scrollbar issue, which seemed simple, felt daunting when I first asked the maintainer to assign it to me. Now, I realize my anxiety was unnecessary. Most things become clearer once you dive into a project.

While working on my PR for improving the Incus documentation, the maintainer asked me to fix my commit to follow the community rules. Even though the fix was minor and didn’t affect the code or the CI/CD pipeline, he was polite and insisted on the no-anonymous contribution rule. It took me about 15 minutes to update the files and another 15 minutes to learn how to build the documentation site on my local machine. However, it took me 2 hours to understand the command git commit --sign-commits and why it was important.

My Productive October

This October has been my most productive and satisfying month of the year. I learned a lot by contributing to different open source projects. My motivation made a big difference. By choosing issues to work on, I set personal goals that felt like promises to the community.

I learned how to implement the --watch option for CLI tools by studying a Node.js project. Then, I recreated that feature in another project using Rust. I started learning Rust from scratch and was able to contribute within two weeks. I also discovered that most maintainers online are friendly, and the community is there to help, not criticize.

If you want to join Hacktoberfest 2026, don’t spend too much time searching for issues you feel fully confident about. Choose issues that interest you and think through them as you go. You don’t need to know every detail before you start; having a rough idea is enough.

Build A Watch Option for TypeScript Runtime in Rust

WH yang — Sat, 08 Nov 2025 03:11:09 +0000

Andromeda is a new TypeScript runtime that uses the Nova Engine and Oxc, which is written in Rust.

Node.js has had a --watch feature since 2022, and you can find the pull request (PR) for it on GitHub. This watch mode, or hot reload, is very popular for frontend frameworks, testing frameworks, and even in Node.js itself. It automatically reruns the code whenever you change a file in the working directory, making life easier for developers today.

I had never tried Rust before sending this PR, and it was a bit reckless to ask the maintainer to assign the issue to me. However, I think it was the best decision I made during Hacktoberfest.

I didn’t think much about how watch mode was implemented, but I used it a lot. My approach was:

Go to the Node.js release page to find out when the watch option was announced.
Locate the PR related to the --watch option.
Read the core implementation.

Then, I needed to use Rust to create a similar function. I did the following:

I read The Rust Programming Language to get a basic understanding of Rust and its tools.
I used AI to help explain each package in the Cargo.toml file, which is like package.json for JavaScript projects.
I looked at the main entry point of the project, even though I didn’t fully understand it. The function names and variables gave me clues about the watch option.
I wrote a folder watch program in a test project and then copied that code to Andromeda.

It was a long journey to solve all the problems I faced. I made some progress but had many doubts over the past two weeks. However, I felt more satisfied than I expected after sending the PR. It reminded me of the first time I compiled and ran my "Hello World" program when I started learning to code.

Vitest HTML Report

WH yang — Fri, 07 Nov 2025 22:48:06 +0000

Testing is very important for software projects. It helps developers find problems that might occur after changes to the code, before those changes are added to the main branch. Software code is updated frequently, and it’s hard to test every possible issue manually each time. Testing frameworks help automate this process, either on the developer's computer or in cloud services.

Vitest is a testing framework made for the Vite ecosystem. Jest is another well-known framework, and Vitest is designed to work similarly, so developers can easily switch between them. I can use the Expect API, which I'm already familiar with, originally from Jest.

Vitest also has a --ui option that opens a web page showing the test results and coverage reports while monitoring project files. The HTML report helps me understand which parts of the code are not covered by tests better than just seeing it in the command line.

Vitest can integrate with IDEs like VS Code and JetBrains, but I use Neovim with lazyVim for my development. There’s a third-party tool called Neotest that works with Neovim and Vitest, but I haven’t tried it yet.

When it comes to writing tests, I often feel less motivated than when I’m developing new features. So, I need to create a nice interface and an easy-to-use pipeline for myself to stay motivated with testing tasks.

Browser scrollbar color in the Dark mode.

WH yang — Sun, 02 Nov 2025 01:08:18 +0000

SoybeenAdmin is a dashboard template built with Vue 3, Pinia, and TypeScript. With 13.3k stars and 2.3k forks, it is a popular project.

I fixed a bug where the scrollbar color didn't switch to light when dark mode was enabled. The fix for Firefox and Chrome involved updating the CSS property scrollbar-color, but this property doesn’t apply to Safari. Safari doesn't support this property, yet I found several websites that displayed different color scrollbars while dark mode was active.

The solution for Safari is the color-scheme property. This property informs Safari that the element is dark, allowing it to use a light color scrollbar by default.

Although this issue wasn’t difficult, I initially had no idea what was causing it. Chrome, Firefox, and Safari each support different CSS properties, which made it challenging for me to get into frontend development. After checking line by line on MDN, I discovered stylelint. I believe this CSS linter can help alleviate my headaches in the frontend projects I'm involved in.

Be a contributor of Incus

WH yang — Sat, 01 Nov 2025 20:53:30 +0000

Incus is a next-generation system container, application container, and virtual machine manager. It aims to provide a similar approach to public clouds for managing containers and VMs on private machines, suitable for anything from a single laptop to a whole server rack. It is an alternative to Canonical's LXD.

Incus is a large project, and I'm not sure when I will use it. While exploring the project documentation, I noticed some small problems that hadn’t been reported. I took about half an hour to understand how to build the static documentation page and submitted a pull request (PR) to the Incus main repository. However, things became more complicated after submitting the PR.

I didn’t realize they had specific instructions for pull requests, including a required commit format and the need to use git commit -s to add a sign-off line to my commit message. By adding the sign-off line, I agreed to the terms outlined in the Developer Certificate of Origin.

This was new to me. This project don’t accept anonymous commits. This policy helps avoid legal issues if someone copies code from a company project to this one.

Even though I made a mistake in my PR, the maintainer kindly asked me to add the sign-off, and he merged it a few hours later after the CI pipeline ran. It was my first time having a conversation online with someone reviewing my contribution. Honestly, this process was more strict than any project I’ve worked on before. I spent a lot of time writing issues, creating the PR, updating my commits, and reading the contribution guidelines, even though my PR only included a small documentation update.

A huge thank you to Stéphane Graber, and I’m happy to see my contribution included in the 6.18 release.