DEV Community: KID-joker

I finally shipped the plugin I'd been putting off for years. Then I started questioning why I built it.

KID-joker — Thu, 21 May 2026 14:13:05 +0000

A few days ago I checked off something that had been sitting in my todo list for a long time.

It's a small develop plugin called unplugin-drop-committed. It removes method calls like console.log from your code during development — but only the ones that have been committed to Git. Your uncommitted lines are safe.

The idea came from a real frustration: a colleague had left console.log calls inside polling loops. The browser console was unusable. I didn't want to ban console.log globally — I just wanted the committed noise gone.

Simple enough concept. I had the idea. I never built it.

Why it sat there so long

I care deeply about DX tooling. Probably more than is professionally sensible. I've filtered job opportunities based on whether I'd be working on developer experience. I think it's underrated craft — the invisible layer that makes other developers' days slightly less painful.

But DX is almost always low priority at work. There's always a feature to ship, a bug to fix, a deadline to hit. The DX improvements I want to make get pushed to "later". Later becomes the weekend. The weekend fills up. The todo list grows.

unplugin-drop-committed sat there for a long time. Not because it was hard. Because I never had the uninterrupted time to start.

How AI changed that

I used Claude to help me build it. I want to be clear about what that means: the ideas, the design, the four removal modes — those were mine. What AI gave me was momentum. It handled the boilerplate, suggested approaches I hadn't considered, and kept me from getting stuck on implementation details that would have cost me a whole evening.

It took a fraction of the time I expected. I finally crossed something off the list.

For someone like me — someone with a backlog of DX ideas and a shortage of free hours — AI is genuinely liberating. It's not replacing my thinking. It's removing the friction that was keeping my thinking from becoming real things.

The question that followed

The satisfaction lasted maybe ten minutes.

Then I started thinking about who would actually use this.

AI-assisted development is changing how code gets written. AI agents don't forget to delete their console.log calls the way humans do — or if they produce noise, it's a different kind. The problem this plugin solves is a human problem, shaped by human habits.

I asked Claude how I should position the plugin. It suggested: "unplugin-drop-committed helps AI coding agents stay focused — keeping debug output isolated to the module being worked on."

That's… not wrong. It's actually an interesting reframe. But it also felt like I was watching my motivation quietly shift from "making developers' lives better" to "making AI agents' workflows cleaner."

DX. AX. Developer Experience. Agent Experience.

I'm not sure when the transition happened, or if it already has.

What I actually believe

I don't think DX is dead. I think the audience is changing, and the best DX tools will be the ones that serve both humans and the agents working alongside them.

I also think there's something worth preserving about caring whether the developer console is readable. Whether the hot reload feels instant. Whether configuration is intuitive. These things still matter, even if fewer people are writing the code by hand.

And I'm going to keep building these tools. AI gave me back the time to do it. I'd rather use that time on the things I actually care about than spend it wondering whether caring still counts.

If you want to try it:

https://github.com/KID-joker/unplugin-drop-committed

Four modes: strict (committed lines), file (committed files), user (other authors), time (older than N days/months). Vite, Webpack, Rollup, Rspack. Vue and Svelte script blocks included.

I'd genuinely like to know: do you think DX tooling still matters the same way it did two years ago?

How to keep the type of storage value unchanged?

KID-joker — Sun, 15 Jan 2023 13:24:03 +0000

Hello, everyone! In September last year, I created a new repository called proxy-web-storage which has over 200 stars now. It can helps some developers manage storage more easily, so I want to share it with you. If you think this repository is useful and deserves more attention, please click a star to support it. I'll introduce it below, so let's get started.

What can proxy-web-storage do?

proxy-web-storage reflects every change of the storage through the Proxy.

The Proxy object enables you to create a proxy for another object, which can intercept and redefine fundamental operations for that object.

1. Keep the type of storage value unchanged.

import { local } from 'proxy-web-storage';

local.test = 'Hello proxy-web-storage'; // works
delete local.test; // works

// number
local.test = 0;
local.test === 0; // true

// boolean
local.test = false;
local.test === false; // true

// undefined
local.test = undefined;
local.test === undefined; // true

// null
local.test = null;
local.test === null; // true

// object
local.test = { hello: 'world' };
local.test.hello = 'proxy-web-storage'; // works

// array
local.test = ['hello'];
local.test.push('proxy-web-storage'); // works
local.test.length // 2

// Date
local.test = new Date('2000-01-01T00:00:00.000Z');
local.test.getTime() === 946684800000; // true

// RegExp
local.test = /d(b+)d/g;
local.test.test("cdbbdbsbz"); // true

// function
local.test = function() {
  return 'Hello proxy-web-storage!';
};
local.test() === 'Hello proxy-web-storage!'; // true

The local corresponds to localStorage, and the same is true for session. They have the same methods and properties: key(), getItem(), setItem(), removeItem(), clear() and length.

2. Listen to the changes.

import { local } from 'proxy-web-storage';

local.on('test', function(newVal, oldVal) {
  console.log('test', newVal, oldVal);
});
local.on('test.a', function(newVal, oldVal) {
  console.log('test.a', newVal, oldVal);
});

local.test = {};
// test {} undefined

local.test.a = 1;
// test.a 1 undefined

It can also listens to changes triggered by other tabs.

on

Subscribe to an item.

key: the name of the item to subscribe to. Support obj.a for Object and list[0] for Array, and also Array length.
callback: the function to call when the item is changed. Includes newValue and oldValue.

once

Subscribe to an item only once.

key: the name of the item to subscribe to. Support obj.a for Object and list[0] for Array.
callback: the function to call when the item is changed. Includes newValue and oldValue.

off

Unsubscribe from an item or all items.

key(optional): the name of the item to unsubscribe from. If no key is provided, it unsubscribes you from all items.
callback(optional): the function used when binding to the item. If no callback is provided, it unsubscribes you from all functions binding to the item.

3. Set expires for items.

import { local } from 'proxy-web-storage';

local.test = 'hello proxy-web-storage';
local.setExpires('test', Date.now() + 10000);

// within 10's
local.test // 'hello proxy-web-storage'

// after 10's
local.test // undefined

The expires is saved to localStorage. So page refresh or close will not affect its expiration. Within 10's, the value still exists. But after 10's, it has been removed.

setExpires

set expires for an item.

key: the name of the item to set expires.
expires: accept string、number and Date.

getExpires

return the expires(Date) of the item.

key: the name of the item that has set expires.

removeExpires

cancel the expires of the item.

key: the name of the item that has set expires.

The features of proxy-web-storage are the above. But I would like to ask how to do the e2e test of localStorage? If you have any suggestion, whether it is about e2e testing or about the repository, please contact me or open an issue. Thanks for reading.