I noticed something odd on our Bun projects: every Dependabot alert was about a direct dependency. Never a transitive one.

It turns out GitHub's dependency graph doesn't read bun.lock yet. It supports package-lock.json, yarn.lock and pnpm-lock.yaml, but for Bun it falls back to package.json. So:

• Transitive dependencies aren't in the graph at all, so they never get an alert.
• Dependencies declared with catalog: are recorded with the literal version catalog:, which never matches an advisory.

In a minimal repro (zod, a package that pins an old uuid, and happy-dom through a catalog), bun audit finds 3 advisories and Dependabot raises 1.

Dependabot version updates do support Bun. This is only about alerts, which is what makes it easy to miss. And if you migrated from npm or Yarn, the alerts tied to your old lockfile get marked as fixed, even though the vulnerable packages are still in bun.lock.

Are you affected? Open Insights → Dependency graph. If your Bun projects only list package.json files, yes. Comparing your open alerts with bun audit makes it obvious.

Fix: until GitHub reads bun.lock itself, you can submit it through the dependency submission API. I made a GitHub Action for that: https://github.com/charpeni/bun-lock-submission

Full write-up, with a toggle that shows what GitHub reads versus what Bun installs: https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock

Hey r/reactjs,

Like many of you, I've used React Hook Form and Formik across several production projects. While they're powerful, I always felt friction with how modern form libraries force you to treat standard HTML forms as legacy: - Having to manually register every input with refs: {...register("email")} - Wrapping UI components in custom controllers - Giant bundle sizes once you add schema resolvers and adapters

I wanted to see if we could go back to standard HTML5 forms as the single source of truth without sacrificing React ergonomics or type safety.

So I built Native Form: 👉 GitHub: https://github.com/sunilsv26/native-form 👉 npm: npm i @native-form/react

What makes it different?

1. Zero Input Registration: You write plain HTML inputs with standard name attributes (<input name="email" />). Native Form discovers them automatically from the DOM via MutationObserver.
2. Uncontrolled DOM-First Performance: Keystrokes don't trigger component re-renders. Your view only re-renders when form state (validation errors, submission status) actually changes.
3. Microscopic Schema Adapters: Adapters for Zod, Yup, and Valibot are under 500 bytes. The core runtime has zero third-party dependencies.
4. Built-in Multi-Step Memory: useWizard and preserveUnmountedValues: true keep your unmounted step values hydrated without complex state contexts.
5. Framework Agnostic Under the Hood: The core runtime (@native-form/core) runs in pure Vanilla JS, Vue, or Svelte, while @native-form/react provides React 18 & 19 hooks (useForm, useField, useWatch, useWizard).

Quick Example:

```tsx import { useForm } from "@native-form/react"; import { zodResolver } from "@native-form/zod"; import { z } from "zod";

const schema = z.object({ email: z.string().email(), age: z.number().min(18), });

export function Form() { const { formRef, formState } = useForm({ schema: zodResolver(schema), serializationMode: "typed", // automatically coerces type="number" and range to numbers onSubmit: (values) => console.log(values), });

return ( <form ref={formRef} noValidate> <input name="email" type="email" placeholder="Email" /> {formState.errors.email && <span>{formState.errors.email}</span>}

  <input name="age" type="number" placeholder="Age" />
  {formState.errors.age && <span>{formState.errors.age}</span>}

  <button type="submit" disabled={formState.submitting}>Submit</button>
</form>

); } ```

I recently released v0.1.2 with fixes for discrete controls, range sliders, and custom design system integration (like Material UI).

I'd love to hear your feedback on the architecture, API design, or any edge cases you'd like to see covered!