https://swynx.io/assets/dead-code-in-graphql-BoVmnSdp.js

1import{j as e}from"./index-CBC1vxyu.js";import{u as r,S as i,B as a}from"./SwynxLayout-BcEFCgca.js";import{u as n}from"./useJsonLd-CzM7lf6u.js";import{C as t}from"./calendar--pAtOWNf.js";import{A as s}from"./arrow-right-BhBRSPkq.js";import"./utils-CkYB-R1u.js";import"./createLucideIcon-D63tVfJx.js";function x(){return r({title:"Dead Code in GraphQL: Unused Resolvers, Dead Mutations, and Orphaned Type Definitions | Swynx",description:"GraphQL APIs accumulate dead resolvers, unused mutations, and orphaned type definitions as schemas evolve. Here's how to find and remove unused code across your GraphQL server.",path:"/blog/dead-code-in-graphql"}),n([{"@context":"https://schema.org","@type":"Article",headline:"Dead Code in GraphQL: Unused Resolvers, Dead Mutations, and Orphaned Type Definitions",description:"GraphQL APIs accumulate dead resolvers, unused mutations, and orphaned type definitions as schemas evolve. Here's how to find and remove unused code across your GraphQL server.",author:{"@type":"Organization",name:"Swynx",url:"https://swynx.io"},publisher:{"@type":"Organization",name:"OYNK",url:"https://oynk.co.uk"},datePublished:"2026-02-02",keywords:["dead code graphql","unused resolvers graphql","graphql dead code detection","find unused code graphql"]}]),e.jsxs(i,{children:[e.jsx("article",{className:"py-24 bg-[#0a0a0a] text-white",children:e.jsx("div",{className:"container mx-auto px-6",children:e.jsx("div",{className:"max-w-3xl mx-auto",children:e.jsxs("div",{className:"mb-8",children:[e.jsxs("div",{className:"flex items-center gap-2 text-white/50 text-sm mb-4",children:[e.jsx(t,{className:"w-4 h-4"}),e.jsx("span",{children:"February 2026"})]}),e.jsx("h1",{className:"text-4xl md:text-5xl font-bold mb-6",children:"Dead Code in GraphQL: Unused Resolvers, Dead Mutations, and Orphaned Type Definitions"}),e.jsx("p",{className:"text-xl text-white/70",children:"Dead code in a GraphQL project is any resolver, mutation handler, subscription listener, type definition, or data loader file that exists in the codebase but is never executed by the running API. GraphQL's schema-first design encourages a tight coupling between type definitions and resolver functions — but as schemas evolve, that coupling breaks down. Fields are deprecated and never removed, mutations are replaced by newer versions, and entire type definitions become orphaned when no query path reaches them. Schema linters can catch missing descriptions and deprecated directives, but they cannot tell you that a resolver file has no corresponding schema field or that a data loader serves a type that nothing queries. Finding dead code in GraphQL requires tracing the full dependency graph from your server's entry point through every resolver, type definition, and utility file, then reporting everything that nothing reaches."})]})})})}),e.jsx("section",{className:"pb-24 bg-[#0a0a0a] text-white",children:e.jsx("div",{className:"container mx-auto px-6",children:e.jsxs("div",{className:"max-w-3xl mx-auto prose prose-invert prose-lg",children:[e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"Why GraphQL Projects Accumulate Dead Code"}),e.jsx("p",{className:"text-white/70",children:"GraphQL APIs accumulate dead code through mechanisms that are unique to how schemas are designed, evolved, and consumed. Three structural forces make GraphQL projects particularly susceptible."}),e.jsxs("p",{className:"text-white/70",children:[e.jsx("strong",{className:"text-white",children:"Schema-first versus code-first divergence."})," In schema-first development, you write ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".graphql"})," or ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".gql"})," schema files and then implement matching resolver functions. When a field is removed from the schema, the resolver function for that field should also be removed — but frequently it is not. The resolver file still exports a function, still compiles, and still passes linting. In code-first approaches (using libraries like TypeGraphQL, NestJS, or Pothos), the resolver class or function defines the schema programmatically. When the class is no longer registered with the server, both the schema contribution and the resolver logic become dead simultaneously, but the file remains in the repository because nothing flagged it as disconnected."]}),e.jsxs("p",{className:"text-white/70",children:[e.jsx("strong",{className:"text-white",children:"Additive schema evolution is the norm."})," GraphQL's type system and its tooling strongly encourage adding fields rather than modifying or removing them. The ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@deprecated"})," directive signals to clients that a field should no longer be used, but it does not remove the field from the schema or the resolver from the server. Teams add ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:'@deprecated(reason: "Use userV2 instead")'})," and move on. Months later, every client has migrated, but the deprecated field, its resolver, its tests, and its data loader all remain. The deprecation becomes permanent dead weight."]}),e.jsxs("p",{className:"text-white/70",children:[e.jsx("strong",{className:"text-white",children:"Deprecated fields are never actually removed."})," Removing a field from a public GraphQL API is a breaking change. Even in internal APIs, teams are reluctant to remove deprecated fields because they cannot be certain every consumer has migrated. The result is a ratchet effect: fields are added, deprecated, and never deleted. Each deprecated field leaves behind a resolver function, possibly a dedicated service call, input validation logic, and test coverage — all of which are dead code that c

1onsumes maintenance effort without serving any user."]}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"Types of Dead Code in GraphQL"}),e.jsx("p",{className:"text-white/70 mb-8",children:"Dead code in GraphQL projects spans both the server-side resolver layer and the schema definition layer. Seven categories recur across projects of every size."}),e.jsxs("div",{className:"grid gap-6 not-prose mb-8",children:[e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Dead Resolvers"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["Resolver files or functions that no longer correspond to any field in the active schema. The schema field was removed or the resolver was superseded by a newer implementation, but the old file remains in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/resolvers/"}),". It exports functions, imports utilities, and compiles cleanly — but the GraphQL server never calls it because no schema field maps to it. This is the most common form of dead code in GraphQL servers."]})]}),e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Unused Mutations"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["Mutation resolvers that are still defined in the schema but no client sends. A mutation like ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"updateUserLegacy"})," was replaced by ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"updateUser"}),", and every front-end has migrated. The mutation still exists in the schema, its resolver still runs if called, and its input validation logic is still maintained — but no client invokes it. Without query-level analytics, there is no way to know it is unused."]})]}),e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Orphaned Type Definitions"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["Types defined in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".graphql"})," schema files or via code-first decorators that no query, mutation, or subscription field returns or accepts. An ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"OldDashboardPayload"})," type was created for a feature that was later rewritten. The type definition remains in the schema, inflating its size and confusing developers who encounter it."]})]}),e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Dead Subscription Handlers"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["Subscription resolvers that define a ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"subscribe"}

1)," function and a publish/subscribe channel, but no client connects to the subscription. Real-time features are often prototyped and abandoned, leaving behind WebSocket setup code, PubSub channel definitions, and filter functions that the server maintains but nothing consumes."]})]}),e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Unused Data Loaders"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["DataLoader instances created to batch and cache database queries for specific resolver fields. When the resolver that used a data loader is removed or rewritten, the data loader file persists. It imports database models, defines batching logic, and is often registered in the server context — but no resolver calls ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"context.loaders.oldUserLoader.load()"})," any longer."]})]}),e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Dead Directive Implementations"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["Custom directive transformer functions that were written for a schema directive that has since been removed. Directives like ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@cacheControl"}),", ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@rateLimit"}),", or ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@deprecated"})," require transformer code that wraps resolver execution. When the directive is removed from the schema, its transformer file becomes dead but remains in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/directives/"}),"."]})]}),e.jsxs("div",{className:"p-5 rounded-xl border border-white/10 bg-[#111]",children:[e.jsx("h3",{className:"text-lg font-bold mb-2",children:"Orphaned Input Types"}),e.jsxs("p",{className:"text-white/60 text-sm",children:["Input type definitions that were created for mutations or query arguments that no longer exist. An ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"UpdateUserLegacyInput"})," was used by ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"updateUserLegacy"})," — when the mutation was deprecated and its resolver abandoned, the input type stayed in the schema. Input types are often defined in shared schema files, making them easy to overlook during cleanup."]})]})]}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"What GraphQL Tooling Misses"}),e.jsx("p",{className:"text-white/70",children:"The GraphQL ecosystem has excellent schema-level tooling, but it has a fundamental blind spot when it comes to dead code at the file level."}),e.jsxs("p",{className:"text-white/70",children:[e.jsx("strong",{className:"text-white",children:"Schema linting catches deprecations but not dead resolver files."})," Tools like ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"graphql-eslint"})," and ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"graphql-schema-linter"})," can enforce naming conventions, require descriptions on fields, and flag unused variables within a single operation. But they operate on the schema definition, not on the resolver source files. A resolver file that exports a function for a field that no longer exists in the schema is invisible to schema linters. The file compiles, exports cleanly, and has no lint errors — it is simply never called."]}),e.jsxs("p",{className:"text-white/70",children:[e.jsx("strong",{className:"text-white",children:"Code generators create files that outlive their schema fields."})," Tools like GraphQL Code Generator produce TypeScript types, resolver type signatures, and React hooks from the schema. When a field is removed from the schema, the generated types for that field are regenerated (or rather, not regenerated). But any hand-written resolver files, service functions, and test files that were built on top of those generated types remain. The generated layer is kept in sync; the implementation layer is not."]}),e.jsxs("p",{className:"text-white/70",children:[e.jsx("strong",{className:"text-white",children:"Apollo Studio and Hive track field usage, not file usage."}),` Schema registries can tell you which fields are queried by clients and which are not. This is invaluable for identifying unused schema fields. But knowing that a field is unused does not automatically tell you which files in your codebase implement that field's resolver, which data loaders serve it, or which test files cover it. The gap between "this schema field is unused" and "these seven files can be deleted" requires dependency graph analysis across the codebase.`]}),e.jsxs("p",{className:"text-white/70",children:["The core problem is the same one that affects every language and framework: ",e.jsx("strong",{className:"text-white",children:'no schema-level tool answers "which files in my GraphQL server are never imported by anything?"'})," That question requires parsing every source file, building the full import graph from the server's entry point outward, and reporting every file that is unreachable. That is 

1what Swynx does."]}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"GraphQL-Specific Dead Code Patterns"}),e.jsx("p",{className:"text-white/70",children:"Beyond the general categories above, GraphQL projects have several patterns that create dead code in ways that are unique to the GraphQL ecosystem."}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"Resolvers for Deprecated Fields"}),e.jsxs("p",{className:"text-white/70",children:["The ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@deprecated"})," directive is GraphQL's official mechanism for signalling that a field should no longer be used. But deprecation is not removal. The field remains in the schema, introspection still returns it, and the resolver still executes if a client sends a query for it. Over time, every client migrates away, but the resolver — along with its service calls, database queries, and validation logic — remains active in the codebase. These resolvers are functionally dead: they execute zero times per day, but they consume maintenance attention every time someone refactors the codebase."]}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"Dead Fragments and Unused Query Files on the Client"}),e.jsxs("p",{className:"text-white/70",children:["GraphQL dead code is not limited to the server. Client applications that use ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".graphql"})," files or colocated ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"gql"})," tagged templates accumulate their own dead code. Fragment definitions created for components that were later removed sit in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/graphql/fragments/"})," without any query or mutation referencing them. Query files written for abandoned features persist in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/graphql/queries/"}),". Generated hook files from ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"graphql-codegen"})," that no component imports remain in the output directory. These files inflate the client bundle, slow down code generation, and clutter IDE autocomplete suggestions."]}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"Orphaned Schema Stitching and Federation Code"}),e.jsxs("p",{className:"text-white/70",children:["Projects that use Apollo Federation or schema stitching often maintain gateway-level code that merges subgraph schemas. When a subgraph is decommissioned, the gateway's stitching configuration for that subgraph should be removed — but frequently, the type extensions, reference resolvers, and entity resolution code for the old subgraph remain. These files are dead at the gateway level: they define resolvers and type extensions for a subgraph that no longer exists. In federated architectures, the subgraph service itself may also contain dead resolvers for ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"__resolveReference"})," functions that no other subgraph queries."]}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"Dead Middleware and Plugin Files"}),e.jsxs("p",{className:"text-white/70",children:["GraphQL servers commonly use plugin or middleware patterns for cross-cutting concerns: logging, tracing, error formatting, and complexity analysis. When a plugin is disabled or replaced, its implementation file often stays in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/plugins/"})," or ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/middleware/"}),". The plugin was removed from the server's configuration array, so it is never instantiated — but the file, its imports, and its tests all persist."]}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"Dead Code Across GraphQL Server Frameworks"}),e.jsx("p",{className:"text-white/70",children:"Each GraphQL server framework has 

1its own conventions for organising resolvers, and each creates its own patterns of dead code accumulation."}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"Apollo Server"}),e.jsxs("p",{className:"text-white/70",children:["Apollo Server projects typically organise resolvers as plain objects in files like ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/resolvers/user.ts"}),", which export a resolver map that is merged into the server's top-level resolver object. When a resolver file is no longer imported by the merging logic, it becomes dead. But the common pattern of using ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"merge-graphql-schemas"})," or manual object spreading can mask this — if resolvers are loaded dynamically via glob patterns like ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"require('./resolvers/**/*.ts')"}),", removing a schema field does not remove the resolver file from the glob match. The resolver is loaded, merged, and available at runtime, but no schema field triggers its execution."]}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"NestJS GraphQL"}),e.jsxs("p",{className:"text-white/70",children:["NestJS GraphQL projects define resolvers as decorated classes using ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@Resolver()"}),", ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@Query()"}),", and ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"@Mutation()"})," decorators. NestJS's dependency injection system automatically registers any resolver class that is included in a module's ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"providers"})," array. When a resolver class is removed from the module but its file stays in the repository, it becomes dead. But when the resolver class is still registered in the module and its methods are still decorated, the dead code is subtler: the class is instantiated, its methods are available, but no client ever calls them because the corresponding schema fields are unused. For a deeper treatment of dead code patterns in NestJS, see ",e.jsx("a",{href:"/blog/dead-code-in-nestjs",className:"text-primary hover:underline",children:"Dead Code in NestJS"}),"."]}),e.jsx("h3",{className:"text-xl font-bold mt-8 mb-4",children:"GraphQL Yoga and Envelop"}),e.jsx("p",{className:"text-white/70",children:"Yoga projects use a plugin-based architecture via Envelop. Plugins for authentication, caching, rate limiting, and tracing are registered in the server configuration. When a plugin is removed from the configuration, its implementation file and any supporting utilities become dead. Yoga's modular design means that each plugin often has its own directory with multiple files — a plugin definition, configuration schema, utility functions, and tests. Removing the plugin from the configuration leaves an entire dead subtree in the repository."}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"Practical Cleanup: Finding and Removing Dead GraphQL Code"}),e.jsx("p",{className:"text-white/70 mb-4",children:"Here is a practical workflow for identifying and removing dead code from a GraphQL project, whether you are running Apollo Server, NestJS, Yoga, or any other Node.js-based GraphQL server."}),e.jsxs("ol",{className:"space-y-4 text-white/70 mb-4",children:[e.jsxs("li",{children:["1. ",e.jsx("strong",{className:"text-white",children:"Scan with Swynx."})," Point Swynx at your project root. It parses every file — ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".ts"}),", ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".js"}),", ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".graphql"}),", ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".gql"})," — builds the full dependency graph from your entry points (",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"package.json"})," main, server entry file, NestJS module root), and reports every unreachable file.",e.jsx("pre",{className:"bg-[#0a0a0a] rounded-lg p-4 font-mono text-sm border border-white/10 overflow-x-auto mt-3",children:e.jsx("code",{children:"swynx scan ./my-graphql-api"})})]}),e.jsxs("li",{children:["2. ",e.jsx("strong",{className:"text-white",children:"Cross-reference with schema analytics."})," If you use Apollo Studio, GraphQL Hive, or any schema registry with field-level usage tracking, cross-reference the unused fields report with the dead files Swynx found. Fields with zero queries over the past 90 days that also have unreachable resolver files are safe candidates for removal."]}),e.jsxs("li",{children:["3. ",e.jsx("strong",{className:"text-white",children:"Review dead resolver files."})," Swynx categorises dead files by type: unused-module, unreachable-code, orphaned-test, and more. Focus on resolver files in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/resolvers/"}),", data loader files in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/loaders/"}),", and directive files in ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"src/directives/"}),". Check whether each file's corresponding schema field has been removed or deprecated."]}),e.jsxs("li",{children:["4. ",e.jsx("strong",{className:"text-white",children:"Remove dead files safely."})," Use Swynx's ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"--fix"})," flag to remove dead files with an automatic snapshot for rollback. Preview first with a dry run:",e.jsx("pre",{className:"bg-[#0a0a0a] rounded-lg p-4 font-mono text-sm border border-white/10 overflow-x-auto mt-3",children:e.jsx("code",{children:"swynx scan ./my-graphql-api --fix --dry-run"})})]}),e.jsxs("li",{children:["5. ",e.jsx("strong",{className:"text-white",children:"Clean up orphaned schema definitions."}

1)," After removing dead resolver files, review your ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:".graphql"})," schema files for type definitions, input types, and enum values that no remaining resolver references. Remove deprecated fields whose resolvers you have just deleted. Run your test suite and start the server to confirm the schema compiles and introspection returns a valid result."]})]}),e.jsxs("p",{className:"text-white/70",children:["Run your test suite after cleanup to confirm nothing breaks. In our research across ",e.jsx("a",{href:"/blog/we-scanned-1000-repos",className:"text-primary hover:underline",children:"1,001 repositories"}),", Swynx achieved a 99.9998% accuracy rate with only 2 false positives across 1.3 million files scanned. Genuinely dead files can be removed without side effects because, by definition, nothing in the application depends on them."]}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"Find Dead Code in Your GraphQL Project"}),e.jsxs("p",{className:"text-white/70 mb-8",children:["Swynx supports every major GraphQL server framework — Apollo Server, NestJS GraphQL, GraphQL Yoga, Mercurius, and plain ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"graphql-js"})," implementations. It resolves path aliases from ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"tsconfig.json"}),", handles barrel file re-exports, detects dynamic ",e.jsx("code",{className:"text-white/90 bg-white/10 px-1.5 py-0.5 rounded text-sm",children:"import()"})," expressions, and understands monorepo workspace boundaries. Point it at a public GitHub repository to get a full dead code report in under three minutes — or install the CLI and scan locally."]}),e.jsxs("div",{className:"flex flex-col sm:flex-row gap-4 mb-16",children:[e.jsx(a,{size:"lg",className:"text-base px-8",style:{height:"56px"},asChild:!0,children:e.jsxs("a",{href:"/scan",children:["Scan a Repository Free ",e.jsx(s,{className:"w-4 h-4 ml-2"})]})}),e.jsx(a,{size:"lg",variant:"outline",className:"text-base px-8 border-white/30 text-white hover:bg-white/10",style:{height:"56px"},asChild:!0,children:e.jsx("a",{href:"/docs",children:"Read the Documentation"})})]}),e.jsx("h2",{className:"text-2xl font-bold mt-12 mb-6",children:"Related Posts"}),e.jsxs("div",{className:"grid gap-6 not-prose",children:[e.jsx("a",{href:"/blog/dead-code-in-nestjs",className:"block group",children:e.jsxs("div",{className:"border border-white/10 rounded-lg p-6 transition-colors hover:border-white/25 hover:bg-white/[0.02]",children:[e.jsxs("div",{className:"flex items-center gap-2 text-white/50 text-sm mb-2",children:[e.jsx(t,{className:"w-4 h-4"}),e.jsx("span",{children:"February 2026"})]}),e.jsx("h3",{className:"text-lg font-bold mb-2 group-hover:text-white/90 transition-colors",children:"Dead Code in NestJS: Unused Providers, Dead Controllers, and Orphaned Modules"}),e.jsx("p",{className:"text-white/60 text-sm",children:"NestJS's module system and dependency injection create unique dead code patterns. Dead providers, unused guards, and orphaned modules accumulate as applications evolve."}),e.jsxs("span",{className:"inline-flex items-center gap-1 text-primary text-sm mt-3 group-hover:gap-2 transition-all",children:["Read more ",e.jsx(s,{className:"w-3 h-3"})]})]})}),e.jsx("a",{href:"/blog/find-unused-code-javascript",className:"block group",children:e.jsxs("div",{className:"border border-white/10 rounded-lg p-6 transition-colors hover:border-white/25 hover:bg-white/[0.02]",children:[e.jsxs("div",{className:"flex items-center gap-2 text-white/50 text-sm mb-2",children:[e.jsx(t,{className:"w-4 h-4"}),e.jsx("span",{children:"November 2025"})]}),e.jsx("h3",{className:"text-lg font-bold mb-2 group-hover:text-white/90 transition-colors",children:"Find Unused Code in JavaScript and TypeScript"}),e.jsx("p",{className:"text-white/60 text-sm",children:"How to find and remove unused files, dead exports, and unused dependencies in JavaScript and TypeScript projects."}),e.jsxs("span",{className:"inline-flex items-center gap-1 text-primary text-sm mt-3 group-hover:gap-2 transition-all",children:["Read more ",e.jsx(s,{className:"w-3 h-3"})]})]})}),e.jsx("a",{href:"/blog/dead-code-in-microservices",className:"block group",children:e.jsxs("div",{className:"border border-white/10 rounded-lg p-6 transition-colors hover:border-white/25 hover:bg-white/[0.02]",children:[e.jsxs("div",{className:"flex items-center gap-2 text-white/50 text-sm mb-2",children:[e.jsx(t,{className:"w-4 h-4"}),e.jsx("span",{children:"February 2026"})]}),e.jsx("h3",{className:"text-lg font-bold mb-2 group-hover:text-white/90 transition-colors",children:"Dead Code in Microservices: Cross-Service Dependencies and Orphaned Services"}),e.jsx("p",{className:"text-white/60 text-sm",children:"Microservice architectures hide dead code behind service boundaries. Orphaned services, dead API endpoints, and unused shared libraries accumulate across distributed systems."}),e.jsxs("span",{className:"inline-flex items-center gap-1 text-primary text-sm mt-3 group-hover:gap-2 transition-all",children:["Read more ",e.jsx(s,{className:"w-3 h-3"})]})]})})]})]})})})]})}export{x as default};