The latest articles on Forem by Patrick Amey-Jones (@patrick_ameyjones_0379c1). https://forem.com/patrick_ameyjones_0379c1 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3754903%2Fd753c7e6-bc3f-4923-95eb-6f5db543b113.png https://forem.com/patrick_ameyjones_0379c1 en Patrick Amey-Jones Mon, 30 Mar 2026 18:34:46 +0000 https://forem.com/patrick_ameyjones_0379c1/we-scanned-4500-github-repos-heres-what-developers-are-actually-migrating-to-59ln https://forem.com/patrick_ameyjones_0379c1/we-scanned-4500-github-repos-heres-what-developers-are-actually-migrating-to-59ln <h1> We scanned 4,500 GitHub repos. Here's what developers are actually migrating to. </h1> <p>Developer tools come and go. Blog posts tell you what you <em>should</em> use. GitHub history tells you what people are <em>actually</em> doing.</p> <p>We built IndieStack to catalog developer tools — auth, payments, databases, email, the whole stack. As part of that, we scraped package.json files across thousands of public GitHub repos, tracking dependency changes over time. The result: 422 confirmed migration paths across 4,535 repos, plus 93,111 verified tool combinations showing what gets used together in production.</p> <p>Here's what the data shows.</p> <h2> Vitest is eating the testing ecosystem </h2> <p>The single strongest migration signal in our dataset: <strong>Jest to Vitest, in 37 repos</strong>. Add Mocha to Vitest (13 repos) and you have the dominant story in JavaScript testing right now.</p> <p>It's not hard to see why. Vitest runs natively in ESM, integrates with Vite's transform pipeline, and its API is close enough to Jest that migration is mostly mechanical. For projects already on Vite, it's a free lunch: one build tool, one config, one mental model.</p> <p>Mocha, meanwhile, is losing ground in both directions — to Vitest (13), to Jest (12), and even to Ava (10). That last one is interesting. Ava has been around since 2014 and is far from new, but it's still pulling developers away from Mocha in 2025. Mocha's decline isn't about one competitor winning — it's about an older paradigm (callback-based, no native ESM, verbose config) losing relevance broadly.</p> <h2> Webpack is losing. Vite is winning. The story is more nuanced than that. </h2> <p>Webpack → Vite showed up 18 times. Webpack → Rollup showed 12. Rollup → Vite showed 6. Webpack → esbuild showed 5.</p> <p>The simple read: Webpack is the loser. But look at where those repos are landing. Vite absorbs migrations not just from Webpack but from Rollup and esbuild too. It's not just a faster bundler — it's becoming the default dev environment. Rollup and esbuild were often intermediate steps (faster builds, simpler config), but Vite wraps both of them and adds HMR, dev server, and first-class framework integrations. The final destination for most of these migrations is Vite.</p> <p>One caveat: our dataset skews toward frontend-heavy repos. Webpack still dominates enterprise and SSR-heavy setups. These numbers reflect the direction of travel for greenfield projects, not the installed base.</p> <h2> The security swap nobody talks about </h2> <p>18 repos migrated from <code>bcrypt</code> to <code>bcryptjs</code>. That's the second-highest migration count in our entire dataset, tied with webpack → vite.</p> <p>This one doesn't get the conference talks. bcrypt (the native Node binding) has historically caused install headaches on certain architectures — especially ARM and Alpine Linux containers. bcryptjs is a pure JavaScript implementation: slower in benchmarks, zero native compilation. But for most web apps hashing a password on login, the difference is microseconds. The trade-off is obvious once you've hit it, which explains the quiet, consistent migration.</p> <h2> Cypress → Playwright: the E2E shift is real but slow </h2> <p>Cypress to Playwright showed up 7 times; Cypress to Vitest (unit testing as a substitute for E2E) showed 5 times. That's 12 repos moving away from Cypress.</p> <p>The reasons are well-documented: Playwright runs in multiple browsers natively, handles async better, and Microsoft is actively developing it. But 12 repos is not a flood. Cypress has a massive installed base and excellent DX. The migration cost for E2E tests is high — these are slow, brittle, hard to rewrite. We'd expect this number to grow slowly over the next two years, not spike.</p> <h2> The quiet signals </h2> <p>Two smaller migrations worth noting:</p> <p><strong>Moment → Day.js (6 repos).</strong> Moment officially went into maintenance mode in 2020. Five years later, repos are still migrating. The long tail of moment usage in production is real.</p> <p><strong>Recoil → Jotai (5 repos).</strong> Facebook's Recoil never achieved the adoption the React team expected, and Jotai — lighter, no string-keyed atoms, smaller API surface — is picking up the converts. In state management, the trend is consistently toward less abstraction, not more.</p> <h2> What this means </h2> <p>If you're starting a project in 2025, the migration data points to a clear default stack for JS tooling: <strong>Vite for bundling, Vitest for tests, Playwright for E2E</strong>. These aren't just the trendy choices — they're where repos are actually landing after paying the migration cost to move away from something else.</p> <p>The IndieStack migration database now covers 422 migration paths. You can browse them, see what tools your stack has in common with 4,500 real repos, and check whether the tools you're using are gaining or losing ground.</p> github javascript testing tooling Patrick Amey-Jones Thu, 05 Feb 2026 12:48:53 +0000 https://forem.com/patrick_ameyjones_0379c1/i-got-tired-of-checking-50-secretary-of-state-websites-so-i-built-an-api-8d5 https://forem.com/patrick_ameyjones_0379c1/i-got-tired-of-checking-50-secretary-of-state-websites-so-i-built-an-api-8d5 <p>Last year I was helping a fintech startup with their vendor onboarding.<br> Part of the process was verifying that each vendor was actually a registered business in good standing. Sounds simple enough. </p> <p>It wasn't. </p> <p>To verify a single business, I had to figure out which state they were registered in, find that state's Secretary of State website, navigate their(usually terrible) business search interface, solve a CAPTCHA, find the right entity among similarly-named ones, and screenshot the results for our compliance records. </p> <p>Each lookup took 10-15 minutes. We had hundreds of vendors to verify. I started looking for an API to automate this. There wasn't one. The existing options were either enterprise-only ($50k+ annual contracts) or aggregators with stale data. </p> <p>So I built one. </p> <p>What GovLink does </p> <p>You give it a company name and jurisdiction (state), it returns the official registration data: entity status, good standing, formation date,entity type, registered agent, and more. </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code> bash curl -X POST "https://govlink.fly.dev/api/v1/verify" \ -H "X-API-Key: your_key" \ -d "entity_name=Stripe Inc" \ -d "jurisdiction=DE" Response: { "result": { "entity_name": "STRIPE, INC.", "file_number": "5765498", "status": "Active", "good_standing": true, "formation_date": "2010-07-30", "entity_type": "Corporation", "agent_name": "CT Corporation" } } Covers all 50 US states. Data is sourced directly from Secretary of State offices, not scraped from third-party aggregators. The two-tier pricing thing I noticed that a lot of verification workflows involve filtering. You have a list of 100 potential vendors, but you only need full verification on the 10 that pass initial checks. So I built two endpoints: - Pre-check ($0.10) - Just returns status and good standing. Fast, cheap, good for filtering loops. - Full verification ($2.50) - Complete entity data, PDF certificate, audit trail. This is especially useful for AI agents. They can do cheap exploration ($0.10 checks in a loop), then only pay for full verification when they've found the right entity. MCP support I added native https://modelcontextprotocol.io support, so LLMs like Claude can call the API directly during conversations. Point your MCP client at govlink.fly.dev/mcp and the model can verify businesses mid-conversation. This felt like the right investment. AI agents are starting to handle real business workflows - procurement, compliance, due diligence. They need reliable data APIs, not web scraping. Technical notes The stack is straightforward: Python/FastAPI, SQLite for customer data, deployed on Fly.io. One thing I'm oddly proud of: the customer dashboard is a single 3,200-line Python file with embedded HTML/CSS/JS. No React, no webpack, no node_modules. The entire UI ships as one HTTP response. It has dark mode, skeleton loading, keyboard shortcuts, the works. Is this a good idea? Probably not for a team. But for a solo project where I want to iterate fast without context-switching between frontend and backend repos, it works great. Try it GovLink is live at https://govlink.fly.dev. 10 free lookups to test, then pay-as-you-go. If you're dealing with KYB compliance, vendor verification, or building AI agents that need to validate businesses, I'd love to hear what features would be useful. </code></pre> </div> api python fastapi startup