![](\"/cache/d9/44/d94443c94b1f1d57abc02f7d4dcb717c.png\")
Last week, I wrote about a cool new API in Bun called WebView that makes it possible to open a URL in a headless browser without needing something like Puppeteer or Playwright. The code looks like this:
\nimport { WebView } from "bun"\n\nawait using view = new WebView({ width: 2000, height: 3000 })\nawait view.navigate(url)\n\n// example, evaluate JavaScript \nconsole.log(await view.evaluate("document.body.innerHTML"))\n\n// example, take a screenshot\nconst png = await view.screenshot()\nawait Bun.write(values.screenshot, png)\nHowever, there's a drawback: each time I run a process like this on my Ubuntu 20.04 server, it creates directories such as /tmp/snap-private-tmp/snap.chromium/tmp/bun-chrome-80856 and /tmp/snap-private-tmp/snap.chromium/tmp/org.chromium.Chromium.YL1S7L.
After I've run the above Bun code five times, I see this:
\nroot@ubuntu-s-2vcpu-8gb-amd-nyc3-01:~# ls -l /tmp/snap-private-tmp/snap.chromium/tmp/\ntotal 0\ndrwx------ 31 django django 740 Apr 29 12:30 bun-chrome-80651\ndrwx------ 31 django django 740 Apr 29 12:30 bun-chrome-80856\ndrwx------ 31 django django 740 Apr 29 12:30 bun-chrome-81058\ndrwx------ 31 django django 740 Apr 29 12:30 bun-chrome-81260\ndrwx------ 31 django django 740 Apr 29 12:30 bun-chrome-81459\ndrwx------ 2 django django 80 Apr 29 12:30 org.chromium.Chromium.3zCHrv\ndrwx------ 2 django django 80 Apr 29 12:30 org.chromium.Chromium.ImIP4v\ndrwx------ 2 django django 80 Apr 29 12:30 org.chromium.Chromium.YL1S7L\ndrwx------ 2 django django 80 Apr 29 12:30 org.chromium.Chromium.erkDSy\ndrwx------ 2 django django 80 Apr 29 12:30 org.chromium.Chromium.orhmkv\n\n
They're pretty big too.
\n# du -sh /tmp/snap-private-tmp/snap.chromium/tmp/bun-chrome-80651/\n4.0M /tmp/snap-private-tmp/snap.chromium/tmp/bun-chrome-80651/\n# du -sh /tmp/snap-private-tmp/snap.chromium/tmp/\n21M /tmp/snap-private-tmp/snap.chromium/tmp/\n\n
Here, that bun-chrome-80651 was \"only\" 4MB. If you open a more busy web site, I've seen it become around 25MB.
I learned this the hard way because I server nearly died from exhausted disk usage since that directory was taking up ~4GB.
\nNow I have bash cron script that periodically deletes these files.
", "url": null, "disallow_comments": false, "split": null}, {"oid": "html-getter", "title": "html-getter - A powerfully simple HTML scraper in Bun", "pub_date": "2026-04-17T13:34:17.084Z", "comments": 0, "categories": ["TypeScript", "macOS", "Bun"], "html": "When Bun v1.3.12 was released last week, they subtly included a powerful feature, almost under the radar: WebView. It's like Playwright/Puppeteer but more limited, especially in terms of documentation.
I built a demo app based on it called html-getter which you can use like this:
\n\nbun run src/html-getter.ts https://www.peterbe.com\nThat will open https://www.peterbe.com with Chrome or Chromium or WebKit and evaluate the following JavaScript expression: document.documentElement.outerHTML (which is the whole HTML source of the whole DOM) and print this to stdout.
or you can use it like this:
\n\nbun run src/html-getter.ts --body --screenshot /tmp/page.png https://www.peterbe.com\nwhich means it prints everything inside the <body>...</body> instead and at the same time, it dumps a screenshot of what it looks like, which can be useful for debugging.
What's cool about this is that you no longer need to install playwright or puppeteer. Scraping HTML is just one of many applications you can use WebView for. I wouldn't use it for automated headless browser testing though because the documentation, tooling, and APIs for Playwright is still so much much better.
WARNING
\nAt the time of writing this, I am unable, on macOS, to compile this Bun script into a binary. When I do, this happens:
\n\n$ bun run build\n$ bun build src/html-getter.ts --target=bun --outfile out/html-getter --compile --bytecode\n [14ms] bundle 1 modules\n [77ms] compile out/html-getter\n$ ./out/html-getter https://www.peterbe.com\n[1] 70304 killed ./out/html-getter https://www.peterbe.com\nThe same worked on my x64 Linux server, but to get this to compile on macOS might need some more careful thought.
", "url": "https://github.com/peterbe/html-getter", "disallow_comments": false, "split": null}, {"oid": "bestest-security-tip-for-updating-packages-with-bun", "title": "Bestest security tip for updating packages with Bun", "pub_date": "2026-04-14T14:25:40.655Z", "comments": 0, "categories": ["Bun"], "html": "I don't know when this was added but if you use Bun in your TypeScript project, you might be familiar with bun upgrade which is a CLI tool for upgrading the packages you pin and depend on. You can now pass it a \"cool down period\" which means a certain package update doesn't count unless it's been published for at least X hours.
This is critical for avoiding installing compromised NPM packages. Sometimes a package gets hacked. If you were to be unlucky and upgrade to it at that window of time, you can have pinned an insecure/compromised version into your lock file. \nWhen the Axios supply chain attack happened, there was a 39 minute window when installing the latest version of axios would (potentially) sneak in the bad package version.
Now, this is how I use bun update:
\nbun update --interactive --minimum-release-age=86400\nThat means, it won't upgrade anything that hasn't sat for at least 1 day.
", "url": null, "disallow_comments": false, "split": null}, {"oid": "pytest-import-file-mismatch", "title": "pytest \"import file mismatch\"", "pub_date": "2026-04-01T13:20:53.199Z", "comments": 0, "categories": ["Python"], "html": "I stumbled into a strange error when running pytest in a side-project:
import file mismatch:\nimported module 'test_comments' has this __file__ attribute:\n /<root>/django-peterbecom/peterbecom/api/tests/test_comments.py\nwhich is not the same as the test file we want to collect:\n /<root>/django-peterbecom/peterbecom/publicapi/tests/test_comments.py\nHINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules\n\n
I desperately made sure I deleted every __pycache__ directory and every *.pyc file. I also ran rm -fr .pytest_cache.
It was strange because I knew I had, in the past, had two files called exactly the same. E.g. test_utils.py.
Turns out, you can have two test_something.py called exactly the same but they must both sit in a directory that has a __init__.py.
So there was nothing wrong with /<root>/django-peterbecom/peterbecom/api/tests/test_comments.py. I just had to do:
\ntouch /<root>/django-peterbecom/peterbecom/api/tests/__init__.py\n...and the problem got solved.
", "url": null, "disallow_comments": false, "split": null}, {"oid": "copy-the-current-line-in-vs-code", "title": "Copy the current line in VS Code", "pub_date": "2026-03-12T15:07:52.002Z", "comments": 0, "categories": ["macOS"], "html": "tl;dr; In VS Code you can copy the current line without first selecting it. Cmd-C without selection defaults to whole line.
\nOne of those \"How did I not know this until now?!?!\"
\nVS Code is not emacs even though its emulation gets many things right. But one thing that I only just learned is that to copy a whole current line, you don't have to select it first. If nothing is selected, whichever line the cursor is on gets the entire line copied.
The regular way of doing it:
\n\n\nthe keyboard use here is down, Ctrl-Shift-left, Ctrl-Shift-left, Cmd-C. Then moving down to a new line and Cmd-V
\nHere, note that the cursor is just somewhere on line 6:
\n\n\nthe keyboard use here is down, down, Cmd-C, down, Cmd-V
\nIn this particular demo video, I'm just replicating line 6 and putting a copy of that on (new) line 8. There's actually another keyboard shortcut sequence for that: Option+Shift+down then Option+down
\nOption+Shift+down replicates the current line and puts a copy right below. Then Option+down moves the current line.
", "url": null, "disallow_comments": false, "split": null}, {"oid": "logger.error-or-logger.exception", "title": "logger.error or logger.exception in Python", "pub_date": "2026-03-06T15:27:44.219Z", "comments": 0, "categories": ["Python"], "html": "Consider this Python code:
\n\ntry:\n 1 / 0\nexcept Exception as e:\n logger.error("An error occurred while dividing by zero.: %s", e)\nThe output of this is:
\n\nAn error occurred while dividing by zero.: division by zero\nNo traceback. Perhaps you don't care because you don't need it.
\nI see code like this quite often and it's curious that you even use logger.error if it's not a problem. And it's curious that you include the stringified exception into the logger message.
Another common pattern I see is use of exc_info=True like this:
\ntry:\n 1 / 0\nexcept Exception:\n logger.error("An error occurred while dividing by zero.", exc_info=True)\nIts output is:
\n\nAn error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 23, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nOk, now you get the traceback and the error value (division by zero in this case).
But a more convenient function is logger.exception which looks like this:
\ntry:\n 1 / 0\nexcept Exception:\n logger.exception("An error occurred while dividing by zero.")\nIts output is:
\n\nAn error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 9, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nSo it's sugar for logger.error.
Also, a common logging config is something like this:
\nimport logging\n\nlogger = logging.getLogger(__name__)\nlogging.basicConfig(\n format="%(asctime)s - %(levelname)s - %(name)s - %(message)s", level=logging.ERROR\n)\n\n
So if you use logger.exception what will it print? In short, the same as if you used logger.error. For example, with the logger.exception(\"An error occurred while dividing by zero.\") line above:
\n2026-03-06 10:45:23,570 - ERROR - __main__ - An error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 12, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nadd_noteYou can, if it's applicable, inject some more information about the exception. Consider:
\n\ntry:\n n / 0\nexcept Exception as exception:\n exception.add_note(f"The numerator was {n}.")\n logger.exception("An error occurred while dividing by zero.")\nThe net output of this is:
\n\n2026-03-06 10:48:34,279 - ERROR - __main__ - An error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 13, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nThe numerator was 123.\nPlease tell me there's a better way.
\nI'm in a git feature branch. It was branched off of master some time ago. Then I made some commits. Later, I merged in latest master, and after that some more commits. The question is what was the SHA when I merged in latest master? How to find that out?
Here's what I did:
\nI'm in my feature branch and I run:
\n\ngit log --merges --first-parent\nIt prints this out:
\n\ncommit 2c010ef6e94d792f25f7309ed83a2d35e41e5051\nMerge: 24b2a2513d6f e2817859ed02\nAuthor: Peter Bengtsson <email>\nDate: Thu Feb 26 14:06:24 2026 +0000\n\n Merge remote-tracking branch 'origin' into name-of-my-feature-branch\nThe SHA that was, on master, at the time of merging, was e2817859ed02 which is the second thing the Merge: 24b2a2513d6f e2817859ed02 line.
Now, equipped with this I can go back in time git checkout e2817859ed02 and on that detached HEAD, I can do things like run (unit) tests to see if the master branch was busted at the time I merged it into my feature branch.
gg2 is a command line tool for doing things with Git branches, faster. One of the convenient commands is gg2 branches. \nIt lists your recent branches, sorted by committer-date and for each branch it displays a human-friendly date distance and whether it's already been merged. Looks like this:
Turns out, for large repos figuring out which branches have already been merged is quite slow. For example, in this repo it takes half a second to list all merged branches:
\n\n$ git branch --all --merged | wc -l\n669\n\n$ time git branch --all --merged 1>/dev/null\n\nreal 0m0.490s\nuser 0m0.460s\nsys 0m0.030s\nThe problem was that gg2 branches also does multiple other git branch listing commands to get information. In particular: get the current branch, figure out the default branch, a list of branch committer dates, and a list of merged branches.
\nAll of these async operations were done in serial. With a bit of rearranging, and refactoring, all of these can be turned into this:
\nconst [defaultBranch, currentBranch, dates, isMerged] = await Promise.all([\n getDefaultBranch(git),\n getCurrentBranch(git),\n getAllBranchDates(git),\n getAllMergedBranches(git),\n])\nThe getAllMergedBranches(git) function still takes a very long time and I think it lists all remote branches that have been merged. Anyway, now it's only the slowest part of the Promise.all rather than one of multiple.
UPDATE
\nThe act of blogging about something can sometimes bring out how wrong you are.
\nWhat I didn't realize is that I was using git branch --all --merged to know which local branches have already been merged into the default branch. But you can just use git branch --merged to get the same result but much much faster.
Correcting for this, on a large repo, the average time to execute gg2 branches went from median 541ms to median 188ms. So that's 3x speed improvement.
xbar-my-prs is a plugin I wrote for something called xbar which is a macOS app that let's you write scripts that then show up in the macOS menu bar. Mine is about fetching information about my recent GitHub pull requests.
\nA picture of it in action:
\n![](\"/cache/b8/f6/b8f6c9b52314c6a7674ac86d44fc8a46.png\")
Every minute, it does this GitHub search: is:pr author:@me sort:updated
Then it parses the results and attempts to display a neat summary.
\nAnd each time it runs, it stores a copy of the result in the /tmp directory so that it can compare what the result became compared to before. So if something has changed in the last minute, it displays a summary of the change(s). Example:
![](\"/cache/d5/d5/d5d5ee05f145495eb912840129a5b20b.png\")
First you have to install xbar onto your macOS.
\nAt the time of writing you can't install it with Homebrew. Working on that. But all you need is just and Bun and then you can install it like this:
\ngit clone https://github.com/peterbe/xbar-my-prs.git && cd xbar-my-prs\njust install\njust ship\nIf all goes well, it should have crated an executable file at:
\n\n~/Library/Application\\ Support/xbar/plugins/my-prs.1m.bin\non your system. And that should be all xbar needs to know there's a new plugin to run.
", "url": "https://github.com/peterbe/xbar-my-prs", "disallow_comments": false, "split": null}, {"oid": "optimizing-bun-compiled-binary-for-gg2", "title": "Optimizing Bun compiled binary for gg2", "pub_date": "2026-01-13T16:06:09.784Z", "comments": 0, "categories": ["TypeScript", "Bun"], "html": "tl;dr; adding --bytecode and --production to bun build --compile gives a marginal boost.
I have a CLI tool called gg2 which is written in TypeScript and using Bun compiled to a single executable binary that can be installed with Homebrew. It's fast. Only 17% slower than GitHub's Go-compile gh CLI. But can it get even faster?
I read about Bytecode Caching which is supposed to make the executable \"dramatically improved\". Hmm. Let's see. There's also the --production option, which according to Set NODE_ENV=production and enable minification. Not convinced it's doing much but let's try.
I compiled the binary 4 different ways:
\nbun build src/index.ts --target=bun --compile --outfile out/ggbun build src/index.ts --target=bun --compile --outfile out/gg-bytecode --bytecodebun build src/index.ts --target=bun --compile --outfile out/gg-production --productionbun build src/index.ts --target=bun --compile --outfile out/gg-bytecode-production --production --bytecodeThen I ran hyperfine like this:
\nhyperfine "./out/gg --version" "./out/gg-bytecode --version" "./out/gg-production --version" "./out/gg-bytecode-production --version" --warmup 6\nThe results are as follows:
\n| BINARY | \nTIME (ms, smaller is better) | \nSIZE (MB) | \n
|---|---|---|
| gg | \n87 | \n58 | \n
| gg-bytecode | \n81 | \n60 | \n
| gg-production | \n82.4 | \n55 | \n
| gg-bytecode-production | \n79.6 | \n60 | \n
![](\"/cache/c7/1f/c71f48b8b4ab4acb5c455a140d0301da.png\")
(sorry for being terrible at using Excel to draw charts)
\nI'm skeptical. The hyperfine often complains about statistical outliers so you have to run it with warmup and re-run it till it doesn't complain.
One caveat with using --bytecode is that the compiled code is not re-usable across different versions of bun but I don't understand how that's applicable if it's a executable binary that is shipped outside of Bun.
I'm going to add --bytecode and --production to the next release of gg2.