DEV Community: Michał Wrzosek

Your offline GitHub

Michał Wrzosek — Fri, 04 Sep 2026 05:18:17 +0000

Hi all!

I’ve been coding professionally for the last 15 years - and more and more with AI next to me. Naturally pushed by the market to produce more and more output, I now find myself hopping daily between 5 to 7 simultaneous AI sessions.

I realized that the bottleneck is becoming the code review process - and, more specifically, the place where I conduct those reviews.

I work mostly in environments where it’s not really an option to dump one-shot AI slop into the company’s GitHub. By the time my work is pushed there, it needs to be more or less ready for code review by my colleagues.

So I found myself juggling between terminals and IDEs, copy-pasting my comments about changes created by my agents. I tried many solutions out there, but what I kept feeling was that what I really needed was my own local GitHub.

I want that GitHub code review experience, but before a commit is made, right here on my computer. A single place where all my agents and I can talk about code changes.

So I built GitWarren.

It’s a local, PR-like code review app that works directly with your working tree. I can review committed, staged, unstaged, and untracked changes, leave inline comments, and organize the work into actual reviews without having to push anything anywhere.

What I really like is that I can connect whatever AI I’m using at the moment through MCP and have a coherent experience without all the mundane copy-pasting. Also, all comments live in threads attached to specific code changes, so it’s easy to follow what’s going on over time.

The app is free, open source, fully local - no accounts, no servers - and you bring your own agents to the party.

On macOS, you can just:

brew install --cask klarluft/tap/gitwarren

There are also Linux and Windows builds available. The Windows build isn’t signed yet - I’m working on that.

I think there must be more people facing similar problems right now, no?

Also, the more I work on this app, the more I feel like we may find many other use cases for a local GitHub-like experience. Maybe this could become a meeting place for different agents roaming inside your computer - and, as a bonus, you can peek through a nice UI at what they’re doing, just to stay in the "loop".

Would love to hear how others are handling this.

https://gitwarren.com

Some screenshots:

Adding Tailwind v4 to Docusaurus v3

Michał Wrzosek — Sat, 01 Mar 2025 20:45:09 +0000

This is a very basic Tailwind v4 setup for Docusaurus v3.

Install Tailwind and Postcss:

npm i --save-dev tailwindcss postcss @tailwindcss/postcss

Create docosaurus plugin in src/plugins/tailwind-config.js:

module.exports = function tailwindPlugin(context, options) {
  return {
    name: "tailwind-plugin",
    configurePostCss(postcssOptions) {
      postcssOptions.plugins = [require("@tailwindcss/postcss")];
      return postcssOptions;
    },
  };
};

Add this plugin to docosaurus config object in docusaurus.config.ts:

const config: Config = {
  //...
  plugins: ["./src/plugins/tailwind-config.js"],
  //...
};

Add tailwind setup somewhere in src/css/custom.css file:

@import "tailwindcss";

@custom-variant dark (&:is([data-theme="dark"] *));

And voila! From now on, Tailwind classes should be picked up by Docosaurus and the dark theme will also sync up correctly.

How to inject runtime env vars to your Next.js app

Michał Wrzosek — Thu, 17 Oct 2024 23:07:04 +0000

It is very often beneficial to load environment variables during runtime to your client side, for example, when you want a single Docker image to use in different environments. This would not be possible when using build-time environments (NEXT_PUBLIC_...). Surprisingly, it may not be that obvious how to do so...

Here's one way you can do it:

You have your dynamic layout that will be executed on the server side that injects the env vars config to the client side. You can't use the "use client" clause here.

/src/app/layout.tsx

import { PropsWithChildren } from 'react';
import { unstable_noStore } from 'next/cache';
import { LayoutClient } from './layout-client';

export default function Layout({ children }: PropsWithChildren) {
  // This is important!
  unstable_noStore();

  // some example config to be injected to the client side
  const config = {
    apiEndpoint: process.env.API_ENDPOINT!,
    appEnvironment: process.env.APP_ENVIRONMENT!,
  };

  return (
    <html lang="en">
      <head>
        <link rel="icon" href="favicon.ico" />
      </head>
      <body>
        <LayoutClient config={config}>{children}</LayoutClient>
      </body>
    </html>
  )
}

Then you have your "client" layout:

/src/app/layout-client.tsx

'use client';

import { PropsWithChildren } from 'react';

export const LayoutClient = ({ config, children }: PropsWithChildren<{
  apiEndpoint: string;
  appEnvironment: string;
}>) => {
  // and here you are now on the "client" and basically,
  // you can do whatever you want with your config
}

I split the layout into "server" and "client" because I like to push the config through the React Context so that it will be available to all the components and this of course requires you to be within the "use client" clause.

In short, to make this work you need "unstable_noStore" and careful "use client" clause placement.