Forem: DeVoresyah ArEst

Deploy Fumadocs to Cloudflare Workers with Vinext

DeVoresyah ArEst — Mon, 02 Mar 2026 12:12:06 +0000

Fumadocs is one of the best documentation frameworks in the React ecosystem — built on Next.js with MDX support, full-text search, and a polished UI out of the box. But deploying a Next.js app to Cloudflare has historically been painful.

Enter Vinext — Cloudflare's Vite-based reimplementation of the Next.js API surface. It lets you run your Next.js App Router project on Cloudflare Workers without rewriting anything.

Sounds simple. In practice, there are a few sharp edges. This guide walks through every step and pitfall we hit deploying a real Fumadocs site to Cloudflare Workers.

Prerequisites

A working Fumadocs project (App Router)
Bun or Node.js installed
A Cloudflare account

1. Install Dependencies

bun add -d vinext vite @vitejs/plugin-rsc react-server-dom-webpack @cloudflare/vite-plugin wrangler

Add "type": "module" to your package.json:

{
  "type": "module"
}

2. Create `vite.config.ts`

Fumadocs uses MDX, which needs to be transformed before the RSC plugin processes it. The key is placing fumadocs-mdx/vite before vinext() in the plugin order:

import { cloudflare } from "@cloudflare/vite-plugin";
import mdxPlugin from "fumadocs-mdx/vite";
import vinext from "vinext";
import { defineConfig } from "vite";
import * as sourceConfig from "./source.config";

export default defineConfig({
  plugins: [
    await mdxPlugin(sourceConfig),
    vinext(),
    cloudflare({
      viteEnvironment: {
        name: "rsc",
        childEnvironments: ["ssr"],
      },
    }),
  ],
  resolve: {
    dedupe: [
      "fumadocs-core",
      "fumadocs-ui",
      "react",
      "react-dom",
    ],
  },
  ssr: {
    noExternal: [
      "fumadocs-core",
      "fumadocs-ui",
    ],
  },
});

Why resolve.dedupe and ssr.noExternal? Vite's multi-environment build (RSC + SSR + Client) can create multiple copies of fumadocs-core and react. Deduplication ensures React context works across boundaries.

3. Update Scripts

{
  "scripts": {
    "dev": "vinext dev",
    "build": "vinext build",
    "start": "vinext start",
    "deploy": "vinext deploy"
  }
}

At this point, bun run dev should start your Fumadocs site on Vite. But you'll likely hit a blank page.

4. Fix the React Context Boundary Problem

This is the biggest gotcha. Fumadocs components like DocsLayout and DocsPage use React hooks internally but don't have 'use client' directives — they rely on Next.js's bundler to pull them into the client boundary automatically.

Vinext's RSC plugin is stricter. If a server component renders DocsLayout, the context chain breaks. You'll see errors like:

Uncaught Error: You need to wrap your application inside FrameworkProvider

or:

Cannot destructure property 'isNavTransparent' of 'use(...)' as it is null

The fix: Create explicit 'use client' wrapper components that co-locate the context providers and consumers in the same client tree.

`app/docs-layout.client.tsx`

'use client';

import { RootProvider } from 'fumadocs-ui/provider/next';
import { DocsLayout } from 'fumadocs-ui/layouts/docs';
import type { BaseLayoutProps } from 'fumadocs-ui/layouts/shared';
import type { Root } from 'fumadocs-core/page-tree';

export function DocsLayoutClient({
  tree,
  options,
  children,
}: {
  tree: Root;
  options: BaseLayoutProps;
  children: React.ReactNode;
}) {
  return (
    <RootProvider>
      <DocsLayout tree={tree} {...options}>
        {children}
      </DocsLayout>
    </RootProvider>
  );
}

`app/docs-page.client.tsx`

'use client';

import {
  DocsPage,
  DocsBody,
  DocsTitle,
  DocsDescription,
} from 'fumadocs-ui/layouts/docs/page';
import type { TOCItemType } from 'fumadocs-core/toc';

export function DocsPageClient({
  toc,
  full,
  title,
  description,
  children,
}: {
  toc: TOCItemType[];
  full?: boolean;
  title: string;
  description?: string;
  children: React.ReactNode;
}) {
  return (
    <DocsPage toc={toc} full={full}>
      <DocsTitle>{title}</DocsTitle>
      <DocsDescription>{description}</DocsDescription>
      <DocsBody>{children}</DocsBody>
    </DocsPage>
  );
}

Update `app/layout.tsx`

import { source } from '@/lib/source';
import { baseOptions } from '@/lib/layout.shared';
import { DocsLayoutClient } from './docs-layout.client';
import './global.css';

export default function Layout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <DocsLayoutClient
          tree={source.getPageTree()}
          options={baseOptions}
        >
          {children}
        </DocsLayoutClient>
      </body>
    </html>
  );
}

Update `app/[[...slug]]/page.tsx`

import { source } from '@/lib/source';
import { notFound } from 'next/navigation';
import { getMDXComponents } from '@/mdx-components';
import { DocsPageClient } from '../docs-page.client';

export default async function Page({ params }) {
  const { slug } = await params;
  const page = source.getPage(slug);
  if (!page) notFound();

  const MDX = page.data.body;

  return (
    <DocsPageClient
      toc={page.data.toc}
      full={page.data.full}
      title={page.data.title}
      description={page.data.description}
    >
      <MDX components={getMDXComponents({})} />
    </DocsPageClient>
  );
}

5. Fix OG Image Generation

If you're using @takumi-rs/image-response (Fumadocs' default for fumadocs-ui/og/takumi), it will crash on Cloudflare Workers — it's a native Rust/NAPI module that uses createRequire(import.meta.url) to load .node binaries.

Even the standard fumadocs-ui/og (which uses next/og / @vercel/og) has a subtler problem: it eagerly fetches a fallback font file via import.meta.url at module initialization time, which fails in the Workers environment.

The fix: Use a dynamic import so the OG code only loads when the route is hit, not at Worker startup:

// app/og/[...slug]/route.tsx
import { source } from '@/lib/source';
import { notFound } from 'next/navigation';

export async function GET(_req: Request, { params }) {
  const { slug } = await params;
  const page = source.getPage(slug.slice(0, -1));
  if (!page) notFound();

  // Dynamic import avoids @vercel/og eager font fetch at module init
  const { ImageResponse } = await import('next/og');

  return new ImageResponse(
    (
      <div
        style={{
          display: 'flex',
          flexDirection: 'column',
          width: '100%',
          height: '100%',
          color: 'white',
          padding: '4rem',
          backgroundColor: '#0c0c0c',
        }}
      >
        <p style={{ fontSize: '82px', fontWeight: 800, margin: 0 }}>
          {page.data.title}
        </p>
        <p style={{ fontSize: '52px', color: 'rgba(240,240,240,0.8)', margin: 0 }}>
          {page.data.description}
        </p>
      </div>
    ),
    { width: 1200, height: 630 },
  );
}

And remove the native package:

bun remove @takumi-rs/image-response

6. Create the Worker Entry

Create worker/index.ts. The critical detail: only route image optimization requests to handleImageOptimization. All other requests go to the vinext handler. If you pass everything through handleImageOptimization, you'll get 400 Bad Request on every page.

import {
  handleImageOptimization,
  DEFAULT_DEVICE_SIZES,
  DEFAULT_IMAGE_SIZES,
} from "vinext/server/image-optimization";
import handler from "vinext/server/app-router-entry";

interface Env {
  ASSETS: Fetcher;
  IMAGES: {
    input(stream: ReadableStream): {
      transform(options: Record<string, unknown>): {
        output(options: {
          format: string;
          quality: number;
        }): Promise<{ response(): Response }>;
      };
    };
  };
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);

    // Only handle image optimization requests
    if (url.pathname === "/_vinext/image") {
      const allowedWidths = [
        ...DEFAULT_DEVICE_SIZES,
        ...DEFAULT_IMAGE_SIZES,
      ];
      return handleImageOptimization(
        request,
        {
          fetchAsset: (path) =>
            env.ASSETS.fetch(
              new Request(new URL(path, request.url))
            ),
          transformImage: async (body, { width, format, quality }) => {
            const result = await env.IMAGES.input(body)
              .transform(width > 0 ? { width } : {})
              .output({ format, quality });
            return result.response();
          },
        },
        allowedWidths
      );
    }

    // Delegate everything else to vinext
    return handler.fetch(request);
  },
};

7. Create `wrangler.jsonc`

As of vinext 0.0.18 and wrangler 4.69.0, the auto-generated wrangler config is missing the required assets.directory property (vinext#219). Create one manually:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "your-docs-site",
  "compatibility_date": "2025-12-01",
  "compatibility_flags": ["nodejs_compat"],
  "main": "./worker/index.ts",
  "assets": {
    "directory": "./dist/client",
    "not_found_handling": "none",
    "binding": "ASSETS"
  },
  "images": {
    "binding": "IMAGES"
  }
}

8. Build and Test Locally

bun run build
npx wrangler dev

Open http://localhost:8787 — you should see your Fumadocs site running on the Workers runtime.

9. Deploy

bun run deploy

Or set up CI/CD with Cloudflare auto-detecting pushes to your main branch.

Recap: The Three Pitfalls

Problem	Symptom	Fix
RSC context boundaries	Blank page, `FrameworkProvider` errors	Wrap Fumadocs layout/page components in explicit `'use client'` wrappers
Native modules	`createRequire` / `Invalid URL string` at deploy	Remove `@takumi-rs/image-response`, use dynamic `import('next/og')`
Worker routing	`400 Bad Request` on all pages	Only route `/_vinext/image` through `handleImageOptimization`, delegate rest to `handler.fetch()`

Final Project Structure

your-docs-site/
├── app/
│   ├── layout.tsx                 # Uses DocsLayoutClient
│   ├── docs-layout.client.tsx     # 'use client' wrapper
│   ├── docs-page.client.tsx       # 'use client' wrapper
│   ├── [[...slug]]/page.tsx       # Uses DocsPageClient
│   └── og/[...slug]/route.tsx     # Dynamic import for next/og
├── worker/
│   └── index.ts                   # Cloudflare Worker entry
├── vite.config.ts                 # fumadocs-mdx/vite + vinext + cloudflare
├── wrangler.jsonc                 # Manual config with assets.directory
├── source.config.ts
└── package.json

Vinext is still early (0.0.18 at time of writing), but it already handles the full Fumadocs feature set — MDX, sidebar navigation, search, table of contents, and OG images — all running on Cloudflare Workers at the edge.

6 Pitfalls of Dynamic OG Image Generation on Cloudflare Workers (Satori + resvg-wasm)

DeVoresyah ArEst — Sun, 15 Feb 2026 10:27:55 +0000

I've built a dynamic OG image generator for MachiCrate — a plugin marketplace for city-builder games. Each plugin gets a rich social preview card with its name, author, stats, and thumbnail, generated on-the-fly at the edge.

The stack:

Qwik City (SSR framework on Cloudflare Pages)
Satori — converts HTML/CSS to SVG
satori-html — converts HTML strings to VNodes that Satori understands
@resvg/resvg-wasm — converts SVG to PNG

Sounds simple. It wasn't. Here are the 6 issues we hit and how we solved them.

Issue 1: Cloudflare Workers Block Dynamic WASM Compilation

The Problem

resvg-wasm needs to initialize a WebAssembly module. The standard way is:

import { initWasm } from "@resvg/resvg-wasm";

// This loads the .wasm file and compiles it at runtime
await initWasm(fetch("path/to/index_bg.wasm"));

Cloudflare Workers block dynamic WebAssembly compilation — calling WebAssembly.instantiate() with raw bytes throws an error. This is a security restriction on the Workers runtime.

The Solution

Static WASM imports in _worker.js are processed by wrangler's esbuild, which pre-compiles them into WebAssembly.Module objects that can be instantiated at runtime.

The trick: Vite's SSR build can't handle .wasm file imports either (Node.js throws ERR_UNKNOWN_FILE_EXTENSION). So we inject the import after the build via a post-build script:

// scripts/patch-worker-wasm.js
import { readFileSync, writeFileSync } from "node:fs";

const workerPath = "./dist/_worker.js";
const content = readFileSync(workerPath, "utf-8");

const patched = `import resvgWasm from '@resvg/resvg-wasm/index_bg.wasm';
globalThis.__resvgWasm = resvgWasm;
${content}`;

writeFileSync(workerPath, patched);

Then in the handler, we initialize from globalThis:

let wasmInitialized = false;

async function ensureWasmInitialized() {
  if (wasmInitialized) return;
  const wasmModule = (globalThis as Record<string, unknown>).__resvgWasm;
  if (!wasmModule) {
    throw new Error("resvg WASM module not found.");
  }
  await initWasm(wasmModule as WebAssembly.Module);
  wasmInitialized = true;
}

The build script in package.json chains them:

{
  "build": "qwik build && node scripts/patch-worker-wasm.js"
}

Issue 2: Satori Can't Fetch External Images on Workers

The Problem

Our plugin thumbnails are served from CloudFront (e.g., https://cdn.example.com/user/project/thumbnail.png). In a normal Node.js environment, Satori fetches these URLs automatically when it encounters <img src="..."> in the template.

On Cloudflare Workers, this silently fails. No error, no crash — the image just renders as a blank space. Satori's internal image fetching doesn't work in the Workers runtime.

The Solution

Fetch the image manually and embed it as a base64 data URL:

async function fetchImageAsDataUrl(url: string): Promise<string | null> {
  try {
    const res = await fetch(url, {
      headers: {
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ...",
        Accept: "image/png,image/*,*/*",
      },
    });
    if (!res.ok) return null;

    const contentType = res.headers.get("content-type") || "image/png";
    const mimeType = contentType.split(";")[0].trim();
    const buf = await res.arrayBuffer();

    return `data:${mimeType};base64,${arrayBufferToBase64(buf)}`;
  } catch {
    return null;
  }
}

Now instead of letting Satori fetch the image, we pre-fetch it and pass the base64 data URL directly. But this leads to the next issue...

Issue 3: satori-html Chokes on Large Data URLs

The Problem

A typical thumbnail encoded as base64 is ~400-500KB as a string. When you try to embed that directly in a satori-html tagged template literal:

const dataUrl = "data:image/png;base64,iVBORw0KGgo..."; // ~500KB string

const content = html`
  <div>
    <img src="${dataUrl}" width="324" height="324" />
  </div>
`;

satori-html's template literal parser breaks. It can't handle strings this large in interpolated positions. No useful error message — it just produces a malformed VNode tree.

The Solution

Use a short placeholder string in the template, then walk the parsed VNode tree and replace it with the actual data URL after parsing:

const IMG_PLACEHOLDER = "__IMG__";

// Template uses the short placeholder
const content = html`
  <div>
    <img src="${IMG_PLACEHOLDER}" width="324" height="324" />
  </div>
`;

// After parsing, replace it in the VNode tree
function replaceImgSrc(node: any, placeholder: string, newSrc: string): void {
  if (!node || typeof node !== "object") return;
  if (node.type === "img" && node.props?.src === placeholder) {
    node.props.src = newSrc;
  }
  const children = node.props?.children;
  if (Array.isArray(children)) {
    for (const child of children) replaceImgSrc(child, placeholder, newSrc);
  } else if (children && typeof children === "object") {
    replaceImgSrc(children, placeholder, newSrc);
  }
}

// Usage
replaceImgSrc(content, IMG_PLACEHOLDER, actualBase64DataUrl);

This bypasses the template parser entirely for the large string. Satori itself handles the data URL fine — it's only satori-html's parser that can't.

Issue 4: CloudFront Returns 403 for Server-Side Fetches

The Problem

Our thumbnails are served via CloudFront CDN. When fetching from a browser, everything works. But when fetching from a Cloudflare Worker:

Fetch FAILED: 403 Forbidden

CloudFront blocks requests that don't include browser-like headers. A bare fetch(url) from a Worker sends minimal headers, and CloudFront treats it as suspicious.

This was the most confusing issue because:

The URL works fine when you open it in a browser
The URL works with curl (which sends a User-Agent)
It only fails from server-side fetch() with no headers

The Solution

Include browser-like headers when fetching from CloudFront:

const res = await fetch(url, {
  headers: {
    "User-Agent":
      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
    Accept: "image/png,image/*,*/*",
  },
});

That's it. Adding User-Agent and Accept headers was enough to get a 200 OK from CloudFront.

Issue 5: Satori Doesn't Support WebP

The Problem

Our thumbnails were originally stored as WebP files. After solving the CloudFront 403 issue, we tried fetching the WebP version. The fetch succeeded (200 OK), but Satori crashed with a cryptic error:

Error: l is not iterable

No mention of "unsupported format" or "WebP" anywhere. Just a minified variable name in an error that tells you nothing.

Root cause: Satori's built-in image decoder supports PNG and JPEG but not WebP. When it encounters WebP image data, it fails with this unhelpful error deep in its internals.

The Solution

We stored both formats on upload (WebP for UI display, PNG for OG/social sharing), so the fix was simple — use the PNG variant:

if (plugin.thumbnailUrl) {
  // Use PNG variant — Satori doesn't support WebP decoding
  const pngUrl = plugin.thumbnailUrl.replace("thumbnail.webp", "thumbnail.png");
  const dataUrl = await fetchImageAsDataUrl(pngUrl);
  if (dataUrl) thumbnailDataUrl = dataUrl;
}

Lesson: If you're building an image processing pipeline, always keep a PNG copy for compatibility. WebP is great for browsers but not all server-side tools support it.

Issue 6: `node:buffer` Unavailable in Vite SSR Build

The Problem

To convert an ArrayBuffer to a base64 string, the natural approach in Node.js is:

import { Buffer } from "node:buffer";

const base64 = Buffer.from(arrayBuffer).toString("base64");

But Vite's SSR build (which compiles the code before it runs on Workers) can't bundle Node.js built-in modules:

Error: Cannot bundle Node.js built-in "node:buffer"

Cloudflare Workers do support Buffer at runtime, but Vite doesn't know that and refuses to build.

The Solution

Use Web APIs that work everywhere — chunked String.fromCharCode + btoa:

function arrayBufferToBase64(buffer: ArrayBuffer): string {
  const bytes = new Uint8Array(buffer);
  let binary = "";
  // Process in 8KB chunks to avoid call stack overflow
  for (let i = 0; i < bytes.length; i += 8192) {
    const chunk = bytes.subarray(i, Math.min(i + 8192, bytes.length));
    for (let j = 0; j < chunk.length; j++) {
      binary += String.fromCharCode(chunk[j]);
    }
  }
  return btoa(binary);
}

Why chunked? Because String.fromCharCode(...bytes) with spread on a large array (hundreds of thousands of bytes) will blow the call stack. Processing in 8KB chunks keeps it safe.

Key Takeaways

Cloudflare Workers have WASM restrictions. You can't dynamically compile WASM — use static imports and let wrangler pre-compile them. Post-build scripts are your friend when your build tool can't handle .wasm imports directly.
Satori's image fetching silently fails on Workers. Always fetch images manually and convert to base64 data URLs. Don't rely on Satori's internal fetch.
satori-html has template size limits. Large interpolated strings break the parser. Use placeholder strings and patch the VNode tree after parsing.
CDNs block bare server-side fetches. CloudFront (and likely others) return 403 when requests lack browser-like headers. Always include User-Agent when fetching from server-side code.
Satori only supports PNG and JPEG. WebP will crash with an unhelpful error message. Keep a PNG variant of your images for server-side rendering.
Avoid Node.js built-ins when targeting Workers via Vite. Use Web APIs (btoa, TextEncoder, crypto) instead of Buffer, crypto from node:.

Building OG images on the edge is worth it — sub-100ms generation times, no separate image service to maintain, and automatic global distribution. But the Workers runtime has sharp edges (pun intended) that aren't always well-documented. Hopefully this saves you a few hours of debugging.

Built with Qwik City + Cloudflare Pages. The full OG generator runs at the edge, generating dynamic social cards for every plugin in the MachiCrate store.

Using Auth.js in QwikJS with Modular Forms

DeVoresyah ArEst — Fri, 18 Apr 2025 13:07:07 +0000

TL;DR

Sending the credentials to Auth.js should be done inside options object.

In today's tech landscape, Vibe Coding has emerged as a trend where developers leverage AI to assist in coding. However, the journey isn't always smooth. As many of us know, AI requires substantial resources, including references from official documentation of frameworks and libraries.

The Importance of Community

This brings me to a crucial point: the significance of developers joining communities. When official documentation is incomplete or lacks clarity, we often find ourselves struggling to solve problems independently.

My Experience with Auth.js

Recently, I aimed to create an authentication system using the Auth.js library for ease of implementation. For the login form, I opted for @modular-forms/qwik to enable client-side validation without needing to send data to the server first.
In this scenario, I utilized Auth.js Credentials Provider, allowing users to log in with their email and password. However, I encountered a significant issue: neither the Auth.js nor the QwikJS documentation provided clear guidance on this matter!

For reference, you can check the documentation here: QwikJS Auth Integration and Auth.js Credentials. Initially, I followed the instructions from both sources, but I faced a roadblock. The credentials I received in the plugin@auth.ts file did not include the email and password sent from the client.

Seeking Help and Finding Solutions

Frustrated, I created a thread on the QwikJS Discord channel. There, I discussed my issue with @hollandjake, and together we discovered a solution. It turned out that the data being sent did not conform to the expected format, which was not clearly outlined in the documentation.

The Correct Code for Sending Data

Here is the correct format when you're submitting the login form:

import { component$, $, useTask$, useVisibleTask$ } from "@builder.io/qwik";
import { routeLoader$, Link } from "@builder.io/qwik-city";
import { z } from "zod";
import {
  useForm,
  zodForm$,
  type SubmitHandler,
  type InitialValues,
} from "@modular-forms/qwik";
import { useSignIn } from "../plugin@auth";

// Define the LoginForm schema with Zod
const LoginSchema = z.object({
  email: z.string().email({ message: "Email tidak valid" }),
  password: z.string().min(6, { message: "Password minimal 6 karakter" }),
});

// Define the form type from schema
type LoginForm = z.infer<typeof LoginSchema>;

// Initial values loader
export const useFormLoader = routeLoader$<InitialValues<LoginForm>>(() => ({
  email: "",
  password: "",
}));

export default component$(() => {
  const signIn = useSignIn();

  // Initialize the form
  const [loginForm, { Form, Field }] = useForm<LoginForm, LoginResponse>({
    loader: useFormLoader(),
    validate: zodForm$(LoginSchema),
  });

  // Client-side submit handler
  const handleSubmit = $<SubmitHandler<LoginForm>>((values) => {
    signIn.submit({
      providerId: "credentials",
      options: {
        ...values,
        redirectTo: "/dashboard",
      },
    });
  });

  return (
    <Form onSubmit$={handleSubmit} class="space-y-6">
      <Field name="email">
        {(field, props) => (
          <Input
            {...props}
            type="email"
            label="Email"
            placeholder="email@example.com"
            value={field.value}
            error={field.error}
            hasPrefix
          >
            <EnvelopeIcon q:slot="prefix" class="text-muted-foreground" />
          </Input>
        )}
      </Field>

      <Field name="password">
        {(field, props) => (
          <Input
            {...props}
            type="password"
            label="Password"
            placeholder="••••••"
            value={field.value}
            error={field.error}
            hasPrefix
          >
            <LockIcon q:slot="prefix" class="text-muted-foreground" />
          </Input>
        )}
      </Field>

      <div class="flex w-full justify-end">
        <Link href="/forgot-password" class="anchor text-sm">
          Forgot Password?
        </Link>
      </div>

      <Button type="submit" class="w-full">
        Sign In
        <ArrowRightIcon q:slot="trailing" size="sm" />
      </Button>
    </Form>
  )
})

Dockerizing NuxtJS with Bun

DeVoresyah ArEst — Wed, 08 Nov 2023 18:11:28 +0000

Background 💬

Previously, I'm using the old way to deploy my NuxtJS app into AWS EC2. Building the production locally, and then uploading it through sftp. It's because I don't understand yet about building a custom docker image

Learning by Doing ✍️

The best way to learn fast is by doing. Fortunately, I've a custom Dockerfile for my backend using AdonisJS. My friend who created it. Then I just read all the lines from that file and asked my friend what's the meaning of each line.

Thank god he understands well about docker, so he can explain it to me very well.

Time to Cook 🔥

Why Bun?

Bun is a fast JavaScript package manager. And previously I was using Yarn as my main package manager. But, Bun is faster.

First stage - Base

The first stage will be our base layer which will later on be used for other steps.



ARG NODE_IMAGE=oven/bun:1-alpine

FROM --platform=linux/amd64 $NODE_IMAGE AS base
WORKDIR /usr/src/app
RUN apk --no-cache add openssh g++ make python3 git

Second stage - Installing Dependencies

Our second stage will be used to install all dependencies, so we can build our app in later stages.



FROM base AS install
RUN mkdir -p /temp
COPY package.json bun.lockb /temp/
RUN cd /temp && bun install --frozen-lockfile

If you realize, I didn't use --production. It's because I still need to install devDependencies so I can run the nuxt command

Third stage - Build

We have everything to start our build phase! This very simple and self-explanatory stage.



FROM install AS prerelease

COPY --from=install /temp/node_modules node_modules

COPY . .

ENV NODE_ENV=production

RUN bun run build

Fourth stage - Production

Finally, we can create our last stage.



FROM base AS release

COPY --chown=bun:bun --from=install /temp/node_modules node_modules

COPY --chown=bun:bun --from=prerelease /usr/src/app/.output .

USER bun

ENV HOST 0.0.0.0

EXPOSE 3000

ENTRYPOINT [ "bun", "run", "server/index.mjs" ]

Test Locally 🤖

After I successfully built the docker image in under 5 minutes. I just need to test the docker image by running a container on my local. And I'm using Docker Desktop by the way.

Boom, it can run smoothly without any errors.

Using UUID in AdonisJS v5

DeVoresyah ArEst — Sun, 11 Jun 2023 17:55:09 +0000

Just want to share simple tips how to using UUID in AdonisJS v5. This will help you to define a migration file when using uuid data type and give the default value for it. So, you will no need to use @beforeCreate() on model file.

Before creating the column, you need to create extension of uuid-ossp first by using this query:

this.db.rawQuery('CREATE EXTENSION IF NOT EXISTS "uuid-ossp";').knexQuery

Next, define the uuid column and give default value:

table.uuid('id', { primaryKey: true }).defaultTo(this.db.rawQuery('uuid_generate_v4()').knexQuery)

Reasons Why You Should Use OsmiCSX in Your React Native Project

DeVoresyah ArEst — Wed, 07 Jul 2021 14:55:12 +0000

OsmiCSX v0.6.5 has came out, new features has been added along with new documentation website. In this article I will tell you why OsmiCSX so worth it to be used in your React Native project.

What is OsmiCSX ?

OsmiCSX is a utility React Native style framework for rapidly building custom user interfaces. OsmiCSX adopts the TailwindCSS concept. We want to implement the same coding style in React Native, styling the component just by calling the style name. But, because React Native does not use CSS browser, tailwind is not directly compatible with React Native. That's the problem OsmiCSX is trying to solve.

Simple Inline Style

The default code style in React Native require as an object. It will make the line code long, but with OsmiCSX it can be simplify. For example we want to create a container with flex, background white, and the content is center. Here's the code:

import React from "react"
import { View, Text } from "react-native"
import { apply } from "./OsmiProvider"

const App = () => {
  return (
    <View style={apply("flex items-center justify-center bg-white")}>
      <Text style={apply("text-2xl font-bold text-center")}>Hello World</Text>
    </View>
  )
}

Simple Right?

Separate Styling Code from Render Code

Don't like inline style? No worries, you can separate your styling from render logic. Let's say we gonna create a Button reusable component

Button.js

import React, { memo } from "react"
import { TouchableOpacity, Text } from "react-native"

// styles
import styles from "./ButtonStyle"

const Button = props => {
  const { buttonStyle, labelStyle, title } = props

  return (
    <TouchableOpacity activeOpacity={0.8} {...props} style={[styles.container, buttonStyle]}>
      {props?.children ?? (
        <Text style={[styles.label, labelStyle]}>{title}</Text>
      )}
    </TouchableOpacity>
  )
}

export default memo(Button)

ButtonStyle.js

import { connect } from "./OsmiProvider"

export default connect({
  container: "py-2 px-5 bg-blue-500 rounded-md",
  label: "text-white text-base font-bold"
})

With this pattern, you and your team can maintain the project more easier.

Fully Customize

Does your company have a Design System or Design Guidelines? If yes, you should consider using OsmiCSX in your React Native Project. Why? Because OsmiCSX is fully customized, you can write a design system or design pattern for your project.

OsmiCSX provides you with OsmiProvider that allows you to customize a theme for your app project, implement a design system or design pattern.

CustomTheme.js

export default {
  colors: {
    // custom colors
  },
  spacing: {
    // custom spacing
  },
  border: {
    width: {
        // border width
    },
    radius: {
        // border radius
    }
  },
  font: {
    family: {
        // font family
    },
    size: {
        // font size
    }
  }
}

Dark Theme

Ok, this is new feature that just came out in v0.6.5. OsmiCSX now support dark theme, and it's also provide switcher. So, you can switch your app theme to light, dark, or use system appearance based on user device.

First, to use dark theme you need to add prefix dark: to your style. Example:

apply("flex bg-white dark:bg-gray-900")

It will use bg-white on light mode, and bg-gray-900 on dark mode. Next step, step if you want add switch theme button in your app, the whole code will be like this:

import React, { useState } from "react"
import { TouchableOpacity, View, Text } from "react-native"

import { apply } from "./OsmiProvider"
import { appearanceHook } from "osmicsx"

const Settings = props => {
  const [currentTheme, setCurrentTheme] = useState(appearanceHook.theme)

  const switchTheme = (value) => {
    appearanceHook.switch(value)
    setCurrentTheme(value)
  }

  return (
    <View style={apply("flex bg-white dark:bg-gray-900 items-center justify-center")}>
      <Text style={apply("text-gray-900 dark:text-white text-center text-2xl font-bold")} onPress={() => switchTheme("light")}>Switch to Light</Text>
      <Text style={apply("text-gray-900 dark:text-white text-center text-2xl font-bold")} onPress={() => switchTheme("dark")}>Switch to Dark</Text>
    </View>
  )
}

There're 3 option that you can be used for .switch() method. light, dark, and system. For more details check Documentation

There're many more that I can't explain 1 by 1, go and explore OsmiCSX with yourself ;)

Looking for React Native Boilerplate? Try ⚡ Osmi Kit

DeVoresyah ArEst — Wed, 13 Jan 2021 18:56:42 +0000

Hello React Native Developers ~!
Do any of you use Ignite Andross to generate new React Native projects? If yes, you already know that Ignite Andross really really really save your time on initializing react-native app. You don't need to install the general dependency and config it from 0.

Also with Ignite CLI, you can easily generate screen, component, redux, saga, and many more. It really saves your time.

But unfortunately, in the Ignite latest update. They fully support Ignite Bowser boilerplate and leaves Ignite Andross behind. Because of that, I create an alternative boilerplate like Ignite Andross, plus with the CLI.

Welcome to ⚡ Osmi Kit ⚡

Battle-tested React Native boilerplate

The original concept of this boilerplate is from Ignite. We're really like the project structure from Ignite Boilerplate, especially for Ignite Andross. But we realize that Infinite Red team no longer maintains the Andross Boilerplate. So, therefore we create an alternative boilerplate like Ignite Andross.

This is the React Native boilerplate that the LibsCode and CloudGakkai team uses on a day-to-day basis to build client apps. Developers who use Osmi Kit report that it saves them two to four weeks of time on average off the beginning of their React Native project!

Tech Stack

Osmi Kit includes the following rock-solid technical decisions out of the box:

React Native
React Navigation 5
OsmiCSX
Redux-Saga
Redux-Persist
AsyncStorage
apisauce (to talk to REST servers)
Flipper-ready
Reactotron-ready
TDD-ready
And more!

Quick Start

Prerequisites:

Make sure you already setup React Native environtment (Android SDK, Java, etc.). See React Native docs

Install Global CLI:

// npm
npm install -g osmi-cli

// yarn
yarn global add osmi-cli

Run the CLI:

osmi new MyApp

And Osmi will walk you through the rest.

Install Osmi CLI now

Special Thanks

Special thanks to Infinite Red who create such a beautiful react-native boilerplate (Ignite CLI). And give the inspiration for me to create this alternative cli and boilerplate.

Reason Why you Should use OsmiCSX for React Native Styling

DeVoresyah ArEst — Wed, 18 Nov 2020 16:49:01 +0000

Most react native developer know that styling in react native will take up a lot of space especially inline style, for example:

<View style={{
  flex: 1,
  alignItems: 'center',
  justifyContent: 'center'
}}>
  <Text style={{textAlign:'center', fontWeight:'bold', fontSize:18}}>Hello World!</Text>
</View>

Imagine if you can make it more simple by doing this:

<View style={apply('flex items-center justify-center')}>
  <Text style={apply('text-center text-lg font-bold')}>Hello World!</Text>
</View>

It's more simple right? and if you came from web development and using TailwindCSS, you probably don't need to learn much about OsmiCSX because the pre-defined style is almost the same as TailwindCSS.

Simple External Style File

It will be too much space if you put your style in a view file (e.g. Screen files or Component files). My suggestion for you is to put your style in a different file / external style.
But if you use the default external style file in React Native like this:

import { StyleSheet } from 'react-native'

export default StyleSheet.create({
  container: {
    flex: 1,
    alignItems: 'center',
    justifyContent: 'center',
    backgroundColor: 'blue'
  },
  text: {
    color: 'white',
    fontSize: 18,
    textAlign: 'center'
  }
})

too many spaces, not simple, I don't like it. It takes 15 lines. Why we don't make it like this?

import { connect } from 'osmicsx'

export default connect({
  container: 'flex items-center justify-center bg-blue-500',
  text: 'text-white text-lg text-center'
})

more simple right? it only takes 6 lines. Let's move on

Fully Customize

OsmiCSX provides you with OsmiProvider that allows you to customize a theme for your app project, implement a design system or design pattern.

CustomTheme.js

export default {
  // colors
  "primary": "#46B5A7",

  // background colors
  "bg-primary": { backgroundColor: "#46B5A7" },
}

then you can call it with something like this:

apply('primary') // call the colors
apply('bg-primary') // use primary background

You can check more about OsmiProvider Here

Responsive Design

Alright, if you ask me is there any responsive design module? The answer is absolutely yes. OsmiCSX also provides Responsive Width, Height, and Font Size based on Dimensions Window.

Here's some example:

import { apply } from 'osmicsx'

apply('w/50') // return 50% width of window width
apply('h/50') // return 50% height of window height
apply('text/5') // return 5% font size based on window width

So, what do you think? Consider using OsmiCSX in your React Native Project? I highly recommend it. FYI, for the next OsmiCSX Major Update. It will give a new method of styling in React Native.

Something like this:

<View class="flex items-center justify-center" />

Check more about OsmiCSX here

Open Source Simple Online Shop With React Native

DeVoresyah ArEst — Tue, 22 Sep 2020 03:08:03 +0000

This is an open-source react native project that I and my friend did when we're at home because of the pandemic. I also doing live stream on Facebook while coding this project, you can check here. And this project made for both platforms (iOS & Android).

Here's the app preview:

What main library we used?

React Hooks

95% already use React Hooks. We want to create an open-source project that uses React Hooks for learning and the best practice.

Reusable Components

We try our best to always make a reusable component, so the community can learn about the reusable component in react-native.

Utility Style

Most react-native beginners will use pre-defined components such as NativeBase and UI Kitten. But on this project, we want to introduce OsmiCSX as a utility-style for react native to the community. It's like TailwindCSS on the website, easy to use, and easy to customize. Check OsmiCSX Docs

That's all, I hope it can help everyone to learn React Native and how to use React Hooks on React Native.
Project Repository => github.com/CloudGakkai/Alfredo-Mobile

OsmiCSX Release v0.5.0

DeVoresyah ArEst — Wed, 29 Apr 2020 14:00:01 +0000

In this update, we make more simplify for the styling method in React Native. We bring styling in web sensation to React Native.

Previously in OsmiCSX v0.4.0 we still use multiple arguments for multiple namespaces. But now, we only need one argument. Here's the difference

OsmiCSX v0.4.0

<View style={apply("flex", "items-center", "justify-center")} />

OsmiCSX v0.5.0

<View style={apply("flex items-center justify-center")} />

And also, we added Responsive Font Size. It means the font size will automatically scale depends on the device resolution. For more information please check our Release Notes

GitHub => github.com/OsmiCSX/osmicsx
Documentation => osmicsx.github.io/docs

Simplify Your React Native Style with OsmiCSX

DeVoresyah ArEst — Sun, 12 Apr 2020 09:56:56 +0000

Styling on react native is still quite long if we still use the full jsx object as is normal in react native. What if there is a framework for react native styling easily?

OsmiCSX is here to make styling in React Native even simpler. We no longer need to create objects for the style component. Just call style namespaces and boom, your components will look good.

here's the example of making reusable button component with OsmiCSX style

import React from 'react
import { TouchableOpacity, Text } from 'react-native'
import { apply } from 'osmicsx'

const button = props => {
  const { ...restProps } = props

  return (
    <TouchableOpacity
    {...restProps}
    style={apply(
      "bg-blue-500",
      "p-3",
      "px-5",
      "rounded-md"
    )}>
      <Text style={apply("text-white", "text-center", "text-sm")}>{restProps.title}</Text>
    </TouchableOpacity>
  )
}

export default button

or you prefer to split the styling code to another file, you also can use OsmiCSX to simplify it!

import { connect } from '../lib/OsmiConfig' // your osmi config path

export default connect({
  container: [
    "bg-blue-500",
    "p-2",
    "pl-5",
    "pr-5",
    "rounded"
  ],
  text: [
    "text-white",
    "text-base",
    "font-bold",
    "text-center"
  ]
})

Introducing OsmiCSX v0.4.0 🎉🎉🎉
in this version, we're more simplify the ability to styling in React Native. For inline style, you don't need to use an array anymore on apply() method helper.

What is OsmiCSX ?
OsmiCSX is a utility React Native style framework for rapidly building custom user interfaces. We adopted the Tailwind concept and implement it for styling in React Native. OsmiCSX designed for customizing UI in React Native and makes a reusable component with the style as you want with very simple code.

Why OsmiCSX ?
Most Style/UI framework in React Native only focused on the UI Component and not really customizable. They come with all sorts of predesigned components like buttons, cards, and alerts that might help you move quickly at first, but cause more pain than they cure when it comes time to make your site stand out with a custom design.

OsmiCSX is different.

Instead of opinionated predesigned components, OsmiCSX provides a low-level utility style that lets you build completely custom designs.

GitHub => github.com/OsmiCSX/osmicsx
Docs => osmicsx.github.io/docs

OsmiCSX - An utility React Native style framework

DeVoresyah ArEst — Thu, 02 Apr 2020 14:46:46 +0000

What is OsmiCSX ?

OsmiCSX is a utility React Native style framework for rapidly building custom user interfaces. We adopted the Tailwind concept and implement it for styling in React Native. OsmiCSX designed for customizing UI in React Native and makes a reusable component with the style as you want with very simple code.

Why OsmiCSX ?

Most Style/UI framework in React Native only focused on the UI Component and not really customizable. They come with all sorts of predesigned components like buttons, cards, and alerts that might help you move quickly at first, but cause more pain than they cure when it comes time to make your site stand out with a custom design.

OsmiCSX is different.

Instead of opinionated predesigned components, OsmiCSX provides low-level utility style that let you build completely custom designs.

Templating Friendly

While you can do a lot with just utility classes, as a project grows it can be useful to codify common patterns into higher level abstractions.

OsmiCSX provides tools for extracting component classes from repeated utility patterns, making it easy to update multiple instances of a component from one place:

import { connect } from '../lib/OsmiConfig' // your osmi config path

export default connect({
  container: [
    "bg-blue-500",
    "p-2",
    "pl-5",
    "pr-5",
    "rounded"
  ],
  text: [
    "text-white",
    "text-base",
    "font-bold",
    "text-center"
  ]
})

More Information

Example => OsmiCSX Example
GitHub => OsmiCSX on GitHub
Documentation => OsmiCSX Docs

Forem: DeVoresyah ArEst

Deploy Fumadocs to Cloudflare Workers with Vinext

Prerequisites

1. Install Dependencies

2. Create vite.config.ts

3. Update Scripts

4. Fix the React Context Boundary Problem

app/docs-layout.client.tsx

app/docs-page.client.tsx

Update app/layout.tsx

Update app/[[...slug]]/page.tsx

5. Fix OG Image Generation

6. Create the Worker Entry

7. Create wrangler.jsonc

8. Build and Test Locally

9. Deploy

Recap: The Three Pitfalls

Final Project Structure

6 Pitfalls of Dynamic OG Image Generation on Cloudflare Workers (Satori + resvg-wasm)

Issue 1: Cloudflare Workers Block Dynamic WASM Compilation

The Problem

The Solution

Issue 2: Satori Can't Fetch External Images on Workers

The Problem

The Solution

Issue 3: satori-html Chokes on Large Data URLs

The Problem

The Solution

Issue 4: CloudFront Returns 403 for Server-Side Fetches

The Problem

The Solution

Issue 5: Satori Doesn't Support WebP

The Problem

The Solution

Issue 6: node:buffer Unavailable in Vite SSR Build

The Problem

The Solution

Key Takeaways

Using Auth.js in QwikJS with Modular Forms

TL;DR

The Importance of Community

My Experience with Auth.js

Seeking Help and Finding Solutions

The Correct Code for Sending Data

Dockerizing NuxtJS with Bun

Background 💬

Learning by Doing ✍️

Time to Cook 🔥

Why Bun?

First stage - Base

Second stage - Installing Dependencies

Third stage - Build

Fourth stage - Production

Test Locally 🤖

Using UUID in AdonisJS v5

Reasons Why You Should Use OsmiCSX in Your React Native Project

What is OsmiCSX ?

Simple Inline Style

Separate Styling Code from Render Code

Fully Customize

Dark Theme

Looking for React Native Boilerplate? Try ⚡ Osmi Kit

Welcome to ⚡ Osmi Kit ⚡

Battle-tested React Native boilerplate

Tech Stack

Quick Start

Special Thanks

Reason Why you Should use OsmiCSX for React Native Styling

Simple External Style File

Fully Customize

Responsive Design

Check more about OsmiCSX here

Open Source Simple Online Shop With React Native

What main library we used?

React Hooks

Reusable Components

Utility Style

OsmiCSX Release v0.5.0

Simplify Your React Native Style with OsmiCSX

OsmiCSX - An utility React Native style framework

2. Create `vite.config.ts`

`app/docs-layout.client.tsx`

`app/docs-page.client.tsx`

Update `app/layout.tsx`

Update `app/[[...slug]]/page.tsx`

7. Create `wrangler.jsonc`

Issue 6: `node:buffer` Unavailable in Vite SSR Build