# I shipped my first npm package with AI — and it's already in production

> Source: <https://dev.to/tanella/i-shipped-my-first-npm-package-with-ai-and-its-already-in-production-2cl9>
> Published: 2026-07-01 10:13:27+00:00

I'm a frontend developer with about three years of experience. Until a few months ago, "publish an npm package" lived on my someday list — the kind of thing you assume requires a deeper relationship with build tooling than you actually have. Then I built one. It's called [daterly](https://github.com/artemydottech/daterly), it's a React date picker, and it's already running in internal projects at the company I work for.

The twist: I wrote most of it with AI — specifically Claude Code and the wider Claude toolset. This is the honest version of how that went. Not "AI built my startup overnight," but a real account of where the AI carried me, where it slowed me down, and what I'd actually keep from the experience.

The internet does not need another React date picker. I know. But we needed *this* one.

At work (sima-land) we lean on [react-hook-form](https://react-hook-form.com/) everywhere. It's the backbone of how we handle forms across projects. The date picker we were using — react-datepicker — kept getting in the way of that. Two things drove us up the wall:

When the same papercut shows up in project after project, it stops being a papercut. We use one tech stack on purpose — a shared, repeatable way of building things so any of us can move between projects without relearning the basics. A date picker that fought both our styling approach and our form library was a crack in that consistency.

So the real motivation wasn't "wouldn't it be cool to publish a package." It was: **we want one tool that speaks our stack fluently.** First-class RHF support, styling that bends without a struggle, and the locale/format behavior we actually need (Russian market: `ru`

locale, `dd.MM.yyyy`

by default). That's the takeaway I keep coming back to — the package exists to protect a way of working, not to chase npm downloads.

[daterly](https://www.npmjs.com/package/daterly) is built on [react-day-picker v9](https://daypicker.dev/) (headless) and [date-fns v4](https://date-fns.org/). The headline features:

`dateFormat`

you pass`daterly/rhf`

entry point — if you don't use RHF, you don't pay for it`--daterly-*`

CSS variables and `data-*`

state attributes, so you can theme it without touching JavaScriptThe RHF wrappers are generic over your form's value type, so `name`

gets autocomplete and type-safety:

``` js
import { RHFDatePicker } from 'daterly/rhf';

<RHFDatePicker<BookingFormValues>
  name="checkIn"
  label="Check-in date"
  rules={{ validate: (v) => v !== undefined || 'Pick a date' }}
/>
```

That snippet is the whole reason the project exists, honestly.

I worked almost entirely inside Claude Code, with Claude Design for the visual side. The parts where the AI genuinely shone were the fiddly, self-contained algorithms — the stuff that's annoying to write by hand but easy to specify.

The **input mask** is the best example. We implemented our own digit-only mask instead of pulling in a masking library, and there's real subtlety in it:

`requestAnimationFrame`

after React re-renders the input — otherwise the caret jumps to the end and typing feels broken.`format(parse(masked)) === masked`

. That elegantly catches things like `32.01.2024`

— it parses, but it doesn't format back to the same string, so you know it's invalid.That round-trip trick is the kind of thing the AI proposed that made me go "oh, that's nice." Describing the edge cases in plain language and getting a working first pass back was a real accelerator. Same with boilerplate-heavy work: dual ESM/CJS build config, TypeScript declaration setup, test scaffolding. Tedious to set up from scratch, quick to generate and then review.

It wasn't magic, and pretending otherwise would be dishonest.

**The limits and the lag.** I was on the Pro plan, and I hit usage limits more than once mid-flow — exactly when you've built momentum and don't want to stop. On top of that, it noticeably slowed down on a larger context, which broke the rhythm. If you're going to lean on AI for a real project, budget for the friction of *waiting* and *rationing*, not just the writing.

**It needs a driver, not a passenger.** The AI is great at producing a plausible chunk of code. Whether that chunk is *correct*, fits the existing patterns, and doesn't quietly reinvent something three files over — that's still on me. The most valuable skill wasn't prompting; it was reading every diff like a code reviewer who doesn't trust the author. A junior who can't evaluate the output would have shipped subtly broken behavior here.

This is the part I underestimated, and the part I'm most glad I didn't skip. Going from a working component to something installable and maintainable is a whole second project:

`size-limit`

) so the thing doesn't quietly balloon.None of this is glamorous, but it's the difference between a gist and a package other people can depend on.

A small, very human lesson. Early on, I ran the Changesets CLI interactively and — distracted — picked `minor`

instead of `patch`

. The version jumped to `0.4.0`

instead of `0.3.1`

. No undo on a published version; you just live with the gap.

The fix was a process change I now recommend to anyone: **don't bump versions interactively.** I have it written into the project's instructions for the AI too — create the changeset file by hand, decide the bump deliberately (`patch`

for fixes, `minor`

for new backwards-compatible props, `major`

for breaking changes), and only then publish. A thirty-second mistake taught me more about release discipline than any tutorial.

If you're a frontend dev sitting where I was, three things:

daterly is MIT-licensed and on [npm](https://www.npmjs.com/package/daterly). Code and docs are on [GitHub](https://github.com/artemydottech/daterly). If you're fighting your date picker's styling or RHF integration, give it a look — and if you build your own thing instead, even better. That's the point.

I'm also open to freelance work and collaboration. If you've got something you're building and want a hand, or you just want to see what else I've made, it's all at [artemy.tech](https://artemy.tech).
