{"slug": "i-shipped-my-first-npm-package-with-ai-and-it-s-already-in-production", "title": "I shipped my first npm package with AI — and it's already in production", "summary": "A frontend developer at Sima-Land built and published a React date picker npm package called daterly, written mostly with Claude Code and Claude Design. The package prioritizes first-class support for react-hook-form and customizable styling, and is already in production use at the company. The developer shares an honest account of where AI accelerated development and where it fell short.", "body_md": "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.\n\nThe 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.\n\nThe internet does not need another React date picker. I know. But we needed *this* one.\n\nAt 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:\n\nWhen 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.\n\nSo 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`\n\nlocale, `dd.MM.yyyy`\n\nby default). That's the takeaway I keep coming back to — the package exists to protect a way of working, not to chase npm downloads.\n\n[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:\n\n`dateFormat`\n\nyou pass`daterly/rhf`\n\nentry point — if you don't use RHF, you don't pay for it`--daterly-*`\n\nCSS variables and `data-*`\n\nstate attributes, so you can theme it without touching JavaScriptThe RHF wrappers are generic over your form's value type, so `name`\n\ngets autocomplete and type-safety:\n\n``` js\nimport { RHFDatePicker } from 'daterly/rhf';\n\n<RHFDatePicker<BookingFormValues>\n  name=\"checkIn\"\n  label=\"Check-in date\"\n  rules={{ validate: (v) => v !== undefined || 'Pick a date' }}\n/>\n```\n\nThat snippet is the whole reason the project exists, honestly.\n\nI 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.\n\nThe **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:\n\n`requestAnimationFrame`\n\nafter React re-renders the input — otherwise the caret jumps to the end and typing feels broken.`format(parse(masked)) === masked`\n\n. That elegantly catches things like `32.01.2024`\n\n— 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.\n\nIt wasn't magic, and pretending otherwise would be dishonest.\n\n**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.\n\n**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.\n\nThis 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:\n\n`size-limit`\n\n) 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.\n\nA small, very human lesson. Early on, I ran the Changesets CLI interactively and — distracted — picked `minor`\n\ninstead of `patch`\n\n. The version jumped to `0.4.0`\n\ninstead of `0.3.1`\n\n. No undo on a published version; you just live with the gap.\n\nThe 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`\n\nfor fixes, `minor`\n\nfor new backwards-compatible props, `major`\n\nfor breaking changes), and only then publish. A thirty-second mistake taught me more about release discipline than any tutorial.\n\nIf you're a frontend dev sitting where I was, three things:\n\ndaterly 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.\n\nI'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).", "url": "https://wpnews.pro/news/i-shipped-my-first-npm-package-with-ai-and-it-s-already-in-production", "canonical_source": "https://dev.to/tanella/i-shipped-my-first-npm-package-with-ai-and-its-already-in-production-2cl9", "published_at": "2026-07-01 10:13:27+00:00", "updated_at": "2026-07-01 10:49:18.315643+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "large-language-models", "ai-products"], "entities": ["Claude Code", "Claude Design", "Sima-Land", "daterly", "react-hook-form", "react-day-picker", "date-fns", "npm"], "alternates": {"html": "https://wpnews.pro/news/i-shipped-my-first-npm-package-with-ai-and-it-s-already-in-production", "markdown": "https://wpnews.pro/news/i-shipped-my-first-npm-package-with-ai-and-it-s-already-in-production.md", "text": "https://wpnews.pro/news/i-shipped-my-first-npm-package-with-ai-and-it-s-already-in-production.txt", "jsonld": "https://wpnews.pro/news/i-shipped-my-first-npm-package-with-ai-and-it-s-already-in-production.jsonld"}}