Forem: c4605

shadow-cljs-vite-plugin v0.0.6: Fixing HMR and ES Module Compatibility

c4605 — Thu, 22 Jan 2026 00:00:00 +0000

Two weeks after the initial release of shadow-cljs-vite-plugin, v0.0.6 brings some important fixes that make the development experience much smoother.

Problem 1: ES Module Imports

When I first released the plugin, there were edge cases where ClojureScript code wouldn't import correctly in Vite's ESM environment. This was particularly problematic for users deploying to Cloudflare Workers.

The fix required coordinating with shadow-cljs upstream. We submitted a PR #1249 to address the root cause, which was merged in v3.3.5. Thanks to @thheller for working through it with me!

Problem 2: HMR "Namespace already declared" Error

This was a frustrating one. During hot module replacement, Vite re-executes module code, but global state (like goog.loadedModules_) persists across HMR updates. Google Closure Library assumes modules are loaded exactly once and throws errors on duplicate registration.

The solution was to patch goog.provide and goog.module to be idempotent:

goog.provide = function(name) {
  return goog.isProvided_(name) ? undefined : goog.constructNamespace_.call(this, name);
};

goog.module = Object.assign(function(name) {
  if (name in goog.loadedModules_) {
    goog.moduleLoaderState_.moduleName = name;
    return;
  }
  return origModule.call(this, name);
}, origModule);

Better HMR Batching

Previously, if you saved multiple files quickly (or your editor formatted on save), each change triggered a separate HMR update. Now the plugin batches multiple file changes into a single update using a debounce mechanism.

Additionally, changes to shadow-cljs.edn now automatically restart Vite, so you don't have to manually restart when modifying your build configuration.

Tailwind CSS Support

The plugin works great with Tailwind CSS. I've been using this combination on my blog frontend with no issues.

Try It Out

npm install shadow-cljs-vite-plugin

The plugin is stable and I'm using it in production. Feedback and contributions are always welcome on GitHub.

bitcoin-wallet-connector: One API to Connect All Bitcoin Wallets

c4605 — Tue, 06 Jan 2026 12:14:52 +0000

In the previous article, I ranted about how chaotic the Bitcoin wallet ecosystem is: WBIPs standards that nobody implements, sats-connect compatibility issues, wallets each doing their own thing with APIs...

This article introduces the library I built: bitcoin-wallet-connector.

Try the Live Demo first, or check out the Storybook.

What This Library Focuses On

Smoothing Out the Ridiculous Differences

bitcoin-wallet-connector provides a unified API that lets you connect to all supported wallets with the same code:

import {
  BitcoinWalletConnector,
  UnisatWalletAdapterFactory,
  XverseWalletAdapterFactory,
  LeatherWalletAdapterFactory,
} from "bitcoin-wallet-connector"

// Register the wallets you want to support
const connector = new BitcoinWalletConnector([
  UnisatWalletAdapterFactory(),
  XverseWalletAdapterFactory(),
  LeatherWalletAdapterFactory(),
])

// Subscribe to available wallet changes
// Note: The timing of wallet extension API injection is unpredictable
// (some inject at DOMContentLoaded, others after the load event),
// so subscribing is recommended over getting
connector.subscribeAvailableAdapters(availableAdapters => {
  console.log(
    "Available wallets:",
    availableAdapters.map(([id]) => id),
  )
  // => ['unisat', 'xverse', ...]
})

// Connect wallet - same API for all wallets
const [adapterId, adapter] = availableAdapters[0]
await connector.connect(adapterId, adapter)

// Get addresses, sign, send transactions - unified interface
const addresses = await adapter.getAddresses()
const result = await adapter.signMessage(addresses[0].address, "Hello Bitcoin!")

That's it. Write the code once, support all wallets.

Currently supported wallets:

Wallet	Adapter	Extra Dependencies
UniSat	`UnisatWalletAdapterFactory`	-
Xverse	`XverseWalletAdapterFactory`	`sats-connect`
OKX	`OkxWalletAdapterFactory`	-
Leather	`LeatherWalletAdapterFactory`	`@leather.io/rpc`
Bitget	`BitgetWalletAdapterFactory`	-
Magic Eden	`MagicEdenWalletAdapterFactory`	`sats-connect`

All adapters implement the same interface:

interface WalletAdapter {
  // Connect/Disconnect
  connect(): Promise<void>
  disconnect(): Promise<void>

  // Get addresses
  getAddresses(): Promise<WalletAdapterAddress[]>

  // Message signing
  signMessage(address: string, message: string): Promise<SignMessageResult>

  // Send BTC
  sendBitcoin(
    fromAddress: string,
    receiverAddress: string,
    satoshiAmount: bigint,
  ): Promise<{ txid: string }>

  // PSBT signing
  signAndFinalizePsbt(
    psbtHex: string,
    signIndices: [address: string, signIndex: number][],
  ): Promise<{ signedPsbtHex: string }>

  // Listen for address changes
  onAddressesChanged(callback): { unsubscribe: () => void }
}

No matter which wallet users choose, your business logic stays the same.

About sendRunes/sendInscriptions/sendBRC20

Currently, this library only supports signMessage, sendBitcoin, and signPsbt. It doesn't support sendRunes, sendInscriptions, or sendBRC20.

Because these involve more complex dependencies (like needing an Ordinals Indexer, a BRC20 Indexer, etc.). These would make a Connector overly complicated.

In my view, this should be the responsibility of a Transaction Builder. The Transaction Builder handles transaction construction, then passes it to the Connector for signing and broadcasting.

Security Matters

When designing this library, I prioritized dependency security. The reason is simple: wallet libraries directly handle user assets, and any security vulnerability could result in real financial losses.

Peer Dependencies

I declared important dependencies as peer dependencies rather than bundling them:

pnpm add bitcoin-wallet-connector @scure/base @scure/btc-signer

This means:

You directly control the versions of these dependencies
If a dependency has a security vulnerability, you can upgrade immediately without waiting for this library to release a new version
You won't end up with two versions of @scure/btc-signer bundled in your final build

Optional Dependencies: Install Only What You Need

Wallet SDKs (like sats-connect, @leather.io/rpc) are optional peer dependencies:

# Only supporting UniSat and OKX? No extra dependencies needed

# Need Xverse support?
pnpm add sats-connect

# Need Leather support?
pnpm add @leather.io/rpc

You only install what you need, reducing your exposure to malicious package scripts.

Dynamic Imports: Lazy Loading

This is another important security design: Wallet SDKs are lazy-loaded via dynamic import().

// Internal implementation sketch
const availability = createAvailability({
  getPrecondition: () => window.unisat ?? null,
  initializer: async () => {
    // Only when user actually wants to connect this wallet
    // will the corresponding implementation be loaded
    const { UnisatWalletAdapterImpl } =
      await import("./UnisatWalletAdapter.impl")
    return new UnisatWalletAdapterImpl()
  },
})

Suppose sats-connect gets compromised in a supply chain attack (not uncommon in the npm ecosystem). If your users only use UniSat wallet, the malicious code won't be loaded or executed, because sats-connect is only imported when users click "Connect Xverse".

This should reduce users' exposure to supply chain attacks.

Framework Integration

Currently React integration is provided with an out-of-the-box Context Provider:

import {
  BitcoinConnectionProvider,
  useBitcoinConnectionContext,
} from "bitcoin-wallet-connector/react"
import {
  UnisatWalletAdapterFactory,
  XverseWalletAdapterFactory,
} from "bitcoin-wallet-connector/adapters"

const adapterFactories = [
  UnisatWalletAdapterFactory(),
  XverseWalletAdapterFactory(),
]

function App() {
  return (
    <BitcoinConnectionProvider
      adapterFactories={adapterFactories}
      onWalletConnected={session => console.log("Connected:", session)}
      onWalletDisconnected={() => console.log("Disconnected")}
    >
      <WalletUI />
    </BitcoinConnectionProvider>
  )
}

function WalletUI() {
  const { walletSession, availableAdapters, connect, disconnect } =
    useBitcoinConnectionContext()

  if (walletSession) {
    return (
      <div>
        <p>Connected: {walletSession.adapterId}</p>
        <button onClick={() => disconnect()}>Disconnect</button>
      </div>
    )
  }

  return (
    <div>
      {availableAdapters.map(([adapterId, adapter]) => (
        <button key={adapterId} onClick={() => connect(adapterId, adapter)}>
          Connect {adapterId}
        </button>
      ))}
    </div>
  )
}

The core BitcoinWalletConnector is framework-agnostic. If you're using Vue, Svelte, Solid, or other frameworks, wrapping it into corresponding hooks/composables should be straightforward. Contributions are welcome!

Get Started and Contribute

Quick Start

pnpm add bitcoin-wallet-connector @scure/base @scure/btc-signer

# Install wallet SDKs as needed
pnpm add sats-connect      # Xverse / Magic Eden
pnpm add @leather.io/rpc   # Leather

Or get the demo running in 5 minutes:

Clone the repo
pnpm install
pnpm storybook
Open http://localhost:6006

You can test wallet connections, signing, and other features in Storybook.

Contributing

This is an open source project, and community contributions are very welcome!

If you want to add support for a new wallet, there's one small preference: try to avoid depending on the wallet's official SDK.

Why? Because many wallet APIs are just mounted on the window object and can be called directly without introducing an additional SDK. For example, the UniSat, OKX, and Bitget adapters have zero external dependencies.

Introducing an SDK means one more potential supply chain attack vector, one more package users need to install, and potentially unnecessary bundle size. Of course, if a wallet can only be accessed through its SDK (like Xverse's sats-connect), that's fine — we can make it an optional peer dependency.

See CONTRIBUTING.md for detailed contribution guidelines.

The project is fully open source (MIT). Stars and contributions are welcome!

The Bitcoin Wallet Extensions Ecosystem is a Mess: A Developer's Rant

c4605 — Sat, 03 Jan 2026 19:13:49 +0000

If you're building a Bitcoin dApp, you've probably already discovered that the Bitcoin community's ecosystem is an absolute dumpster fire.

The simplest example is Bitcoin wallets. Everyone seems eager to create standards for others, but nobody seems eager to actually implement them.

"Standards"? What Standards?

Let me be more specific:

WBIPs: Even the Standard Makers Don't Follow Their Own Standards

Leather and Xverse created WBIPs, supposedly to establish a unified Bitcoin wallet API standard, but:

The signPsbt finalize parameter

The signPsbt standard defines a finalize parameter, but neither of the initiators implemented it:

Leather's code
Xverse's code

The wallet auto-discovery mechanism is completely wrong

WBIP004 defines a wallet plugin auto-discovery mechanism, where the first step is to inject the wallet provider into wbip_providers.

But in reality, both Xverse and Leather inject into window.btc_providers:

Leather's code
Xverse's code

Two other major wallets don't care at all

Not to mention that UniSat and OKX Wallet, which actually have massive traffic, seem to have zero interest in supporting WBIPs.

sats-connect: A Standard on Top of Standards

Then, beyond WBIPs, Xverse also created sats-connect, apparently wanting to extend some of their own APIs beyond WBIPs, implementing a standard on top of a standard.

This isn't bad, especially since it also provides compatibility with the UniSat API. Magic Eden even claims to be "sats-connect compatible."

"This sounds absolutely amazing! sats-connect is the meta! The savior of the world!" Right? That's what you're thinking.

But there are still "two small clouds" hovering over this perfect world:

sats-connect doesn't support OKX Wallet (even though OKX Wallet's API has now migrated to be UniSat-compatible, sats-connect can't auto-discover it)
Magic Eden's auto-discovery follows a different standard: ExodusMovement/bitcoin-wallet-standard, not the WBIPs standard. So you can't rely on sats-connect to auto-discover it.

Wait What, Another Standard?

"Wait, what the hell is this ExodusMovement/bitcoin-wallet-standard? I've never heard of it!"

Right, before I tried to integrate Magic Eden, I hadn't heard of it either. Now I've heard of it, and so have you.

More Fun Facts

Oh, here's a "fun fact": if your users have both Xverse and Magic Eden installed, and you don't handle it properly, when they click "Connect Wallet," they might randomly receive a confirmation request from one of the two wallets. Life is full of surprises.

Oh, and another "fun fact": although Magic Eden claims to be "sats-connect compatible," it's actually compatible with an older version of the API.

Show Some Code

You might think, "Fine, I'll just integrate them all myself." So let's look at the code differences for implementing a simple "connect wallet" feature:

// UniSat - Direct window object call
const unisatResponse = await window.unisat.requestAccounts()

// Leather - Yet another API
const leatherResponse = await window.LeatherProvider.request("getAddresses")

// Xverse - From official docs
import { request } from "sats-connect"
const xverseResponse = await request("getAddresses", null)

// Magic Eden - From official docs
import { getAddress, AddressPurpose, BitcoinNetworkType } from "sats-connect"
await getAddress({
  getProvider: getBtcProvider,
  payload: {
    purposes: [AddressPurpose.Ordinals, AddressPurpose.Payment],
    message: "Address for receiving Ordinals and payments",
    network: {
      type: BitcoinNetworkType.Mainnet,
    },
  },
  onFinish: response => {
    console.log("onFinish response, ", response.addresses)
    connectionStatus?.setAccounts(response.addresses as unknown as Account[])
  },
  onCancel: () => {
    alert("Request canceled")
  },
})

Four wallets, four different implementations.

What if you need to integrate 6 wallets in your project? Congratulations, you'll need to go through all the issues I mentioned above, and enjoy wasting a huge chunk of your life along with me.

To Sum It Up

"F**k the stupid ecosystem, what a dumpster fire!" — you/I thought.

So I Built a Library

So I built bitcoin-wallet-connector to help others waste less time on this crap.

In the next article, I'll detail the usage and design philosophy of this library. If you can't wait, check out:

Live Demo
GitHub Repository

I Moved My Config Sharing Repo to LLM-oriented Mode

c4605 — Fri, 02 Jan 2026 10:41:03 +0000

TL;DR: Using npm to distribute shared configs isn't great. "LLM-oriented config sharing" lets you keep full ownership of your configs while enjoying intelligent upgrade assistance.

And here's my updated repo https://github.com/bolasblack/js-metarepo/tree/develop/packages/toolconfs

What is "LLM-oriented Config Sharing"?

Simply put, config sharing projects provide llms.txt, and consumers use it to let LLMs download/update project config files to keep them up to date—instead of distributing configs through npm registry.

So Why Not Use npm Anymore?

Traditional ways of sharing tool configurations—whether through extends or presets—all face a fundamental contradiction: the trade-off between convenience and flexibility.

The Pros of Inheritance Mode

When you use something like extends: "@company/eslint-config", the benefits are obvious:

Easy upgrades: Just npm update, and all projects using this config get the updates
Consistency guaranteed: All projects in the team use the same rules
Centralized maintenance: Improvements and bug fixes only need to happen in one place

But Reality is Harsh

Problems arise when you need to do anything "non-standard":

Custom requirements: Your project has special needs and requires overriding certain rules
Dependency version conflicts: You need to upgrade ESLint, but the upstream config package hasn't caught up yet (e.g., ESLint moved to flat config mode, and you need the latest version, but I'm lazy and haven't updated yet 🤪)
Rule disagreements: Upstream updated a rule, but it doesn't fit your project (the problem is you might not know at first, and only realize "damn, I got burned" when things break)

At this point, you have two choices:

Option A: Patch on top of inheritance

// eslint.config.js
export default [
  ...baseConfig,
  {
    rules: {
      // Override one rule
      'some-rule': 'off',
      // Override another
      'another-rule': ['error', { different: 'options' }],
    },
  },
  // Still need to handle plugin version conflicts...
]

As patches pile up, your "inheritance" becomes layer upon layer of overrides, ending up harder to maintain than writing from scratch.

ESLint is actually not too bad. Tools like Prettier and lint-staged that don't have extends/merge mechanisms are even more troublesome. I previously wrote a super complicated lint-staged config (see lint-staged.config.js and lint-staged.helpers.js, or see belo). It looks decent (well, at least I think so), but it's actually super hard to use and makes a very simple thing extremely complex.

Option B: Eject

Many scaffold tools provide an eject command that copies all config files into your project, giving you full control.

But after ejecting:

You lose the ability to auto-upgrade; you have to update yourself and can't benefit from upstream's tested plugin compatibility
When upstream has important updates, you need to manually diff and merge

This is the dilemma: In inheritance mode you're constrained by upstream; after ejecting you bear the maintenance cost.

LLM is a Game Changer

Now we have LLMs. Times have changed.

The New Workflow

Get latest configs: LLM fetches the latest recommended configs directly from llms.md/llms.txt
Smart merging: LLM understands your project context and merges new configs into existing ones
Preserve customizations: Your custom modifications are recognized and preserved
Update on demand: When you need to upgrade, let LLM handle the merge conflicts

Why is This Better Than Traditional Approaches?

All configs live in your codebase

No hidden config files deep in node_modules, no confusion about "where did this rule come from". Every line of config is clearly visible in your project.

Upgrades become controllable

Upgrading is no longer an "all or nothing" decision. LLM can help you:

See what changed upstream
Understand the impact of each change
Selectively apply updates
Automatically handle merge conflicts

Customization is a first-class citizen

Your customizations are no longer "patches"—they're part of the config. LLM understands and respects these customizations when updating.

Dependency version freedom

You can upgrade any dependency anytime without waiting for upstream config packages to update. Run into issues? LLM can help adjust the config (and configs are easier for them to read now too).

Upstream config files become simpler

Let's look at my lint-staged config files again.

Previous version:

lint-staged.config.js

const { presets: { js, css, md }} = require('./lint-staged.helpers')

module.exports = {
  '*.{ts,tsx}': js,
  '*.{js,jsx}': js,
  '*.{css,scss,sass,less}': css,
  '*.{md,mdx}': md,
}

Helper functions I had to write so downstream could reuse and customize the lint-staged config: lint-staged.helpers.js

const path = require('path')

const wrap = (fn) => (next) => (filenames, commands) =>
  ensureArray(next(filenames, ensureArray(commands))).concat(fn(filenames))

const tap = (fn) => (next) => (filenames, commands) => {
  fn(filenames, commands)
  return ensureArray(next(filenames, ensureArray(commands)))
}

const finish = (filenames, commands) => commands

const prettier = wrap((filenames) => {
  if (!filenames.length) return []

  const cliFileNames = fileNamesToCliArg(filenames)

  // prettier-ignore
  return [
    'yarn prettier --write ' + cliFileNames,
  ]
})

const eslint = wrap((filenames) => {
  if (!filenames.length) return []

  const cliFileNames = fileNamesToCliArg(
    filenames.filter((f) => !f.includes('eslint')),
  )

  // prettier-ignore
  return [
    'yarn eslint ' + cliFileNames,
  ]
})

const prCmds = tap((filenames, cmds) => console.log('cmds', cmds))

module.exports = {
  operators: {
    wrap,
    tap,
    finish,
  },
  atoms: {
    prCmds,
    prettier,
    eslint,
  },
  presets: {
    js: eslint(prettier(finish)),
    css: prettier(finish),
    md: prettier(finish),
  },
  helpers: {
    ensureArray,
    fileNamesToCliArg,
  },
}

function ensureArray(obj) {
  if (obj == null) return []
  return Array.isArray(obj) ? obj : [obj]
}

function fileNamesToCliArg(names, base = process.cwd()) {
  return names.map((f) => path.relative(base, f)).join(' ')
}

Current version:

lint-staged.config.js
Actually, this is so simple now, let me just inline it:

module.exports = {
  '*.{ts,tsx,js,jsx}': ['prettier --write', 'eslint'],
  '*.{css,scss,sass,less,md,mdx}': ['prettier --write'],
}

lint-staged.helpers.js no longer exists—because it's no longer needed

You've Said a Lot, But Doesn't This Still Look Like a Step Backward?

Yes and no.

Yes: Config files do exist independently in each project, just like the old days
No: Because the maintenance cost has fundamentally changed:
- Before: Manually read CHANGELOG or diff against upstream config -> Figure out what changed -> Manually modify -> Test and verify
- Now: Tell LLM "upgrade to the latest recommended config" -> Review LLM's changes -> Done

The cognitive burden of maintenance shifts from "I need to understand all these configs" to "I need to review LLM's suggestions". This is what's different from the early days.

Summary (AI version, couldn't write this myself)

Traditional config sharing forces a choice between "one-size-fits-all convenience" and "full autonomy with complexity". The LLM-oriented approach lets us have both:

Maintain full ownership and transparency of configs
While enjoying intelligent assistance for upgrades and maintenance

This isn't a step backward in technology—it's redefining best practices with new tools.

The Original Article

I built (another) Elm-style `useEffectReducer` hook for React ⚛️

c4605 — Wed, 12 Nov 2025 22:21:51 +0000

GitHub: bolasblack/react-components/tree/develop/packages/useEffectReducer

🌳 What is “Elm-style”?

Elm popularized the Model-View-Update pattern, where each update returns both the next model and the commands to run:

update : Msg -> Model -> ( Model, Cmd Msg )

This design keeps all logic about “what happens when event X occurs” in one place — the update function — instead of scattering side effects across random useEffects.
It also keeps reducers pure while making when and what side effects happen explicit and interpretable by a runtime.

React’s docs echo this philosophy: effects should be an escape hatch, not the default — see You Might Not Need an Effect.

If you want to see how this kind of modeling makes UI logic elegant and maintainable, check out David Khourshid’s classic post “No, disabling a button is not app logic.” 💡

⚛️ So why another Elm-style reducer?

I know there are several similar libraries — and I like many of them! — but I wanted a variant with different trade-offs:

🧱 Some are archived. For example, useEffectReducer and react-use-bireducer are now read-only.
⚙️ Keep it tiny. Fits in one file with almost no dependencies — copy, tweak, or delete it whenever you want.
🧪 Effects as plain objects + separate interpreter. I prefer returning serializable effect descriptors and implementing the actual effect logic in one dedicated place. It’s easier to test reducers (assert on descriptors) without invoking real side effects. (Elm’s update : Msg -> Model -> (Model, Cmd Msg) inspires this split.)

Of course, useEffectReducer doesn’t stop you from returning a function as an effect — the API is flexible enough; it’s just not my personal preference 🙂.
💬 Lower the barrier. I don’t want people curious about the Elm-style approach to feel like they must first study Elm’s Cmd Msg system or learn a full-blown state machine library like XState just to try this pattern.

Both XState and Elm are amazing — I’m genuinely thankful to David Khourshid and all of XState’s contributors, and to the Elm community. I’ve used XState in multiple real projects (it’s saved me countless times!), but it does have a learning curve. Moving from useReducer to useEffectReducer, on the other hand, should feel smooth and approachable 🚀.)

🧪 Example usage

Let’s reimplement the example from David Khourshid’s article
“No, disabling a button is not app logic.”, but this time using useEffectReducer ✨

You can also check out both implementations on GitHub:

🪄 useEffectReducer version: useEffectReducer.stories.tsx → L121–203
⚙️ useReducer version: useEffectReducer.stories.tsx → L24–119

🔗 Related work

Here are some excellent existing takes on bringing Elm-style “state + effects” reducers into React:

davidkpiano/useEffectReducer — by David Khourshid, effectful reducers via an exec helper; archived.
soywod/react-use-bireducer — returns [state, effects] and processes effects through a separate “effect reducer”; archived.
ncthbrt/react-use-elmish — Elmish-style hook combining reducer logic with async helpers.
redux-loop — Redux enhancer adding Elm-like effect tuples.
dai-shi/use-reducer-async — extends dispatch for async actions; conceptually related.
useReducerWithEmitEffect — Sophie Alpert’s gist that inspired much of this work.

📜 Good Articles

Christian Ekrem - "Chapter 2, Take 2: Why I Changed Course - If you want to understand Elm’s architecture, you can read this newly published article
David Khourshid – "Redux is half of a pattern (1/2)"
David Khourshid – "There are so many fundamental misunderstandings about XState (and state machines in general)"
David Khourshid – "No, disabling a button is not app logic."
React docs – “You Might Not Need an Effect” https://react.dev/learn/you-might-not-need-an-effect