DUB-LINT(1)

πŸ’… dub-lint(1) β€” the linter page, but make it make sense

okay so first things first: this is dub-lint(1), brought to you by The D Language Foundation, and it's genuinely one of the most underrated little corners of dub. it's the vibe check for your D code, and yes, it will tell you if your code is not slaying. 🫢


✨ NAME ✨

dub-lint β€” runs the linter tests of whichever package you picked, no cap.


🌸 SYNOPSIS 🌸

dub lint [<package>[@<version-spec>]] OPTIONS...  [-- <application arguments...>]

that's it. that's the whole thing. you give it a package (or don't, and it just does its thing), you throw some options at it, and if you're feeling spicy you can pass extra args after -- for the application itself. πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

it builds the package, then it runs the D-Scanner linter tests. that's literally the whole job. build β†’ lint β†’ you get told what's wrong β†’ you fix it β†’ you glow. periodt. ✨


πŸŽ€ OPTIONS πŸŽ€

here's the full menu, bestie β€” every single option, nothing skipped:

  • --syntax-check β€” lexes and parses sourceFile, then prints the line and column number of any syntax errors to stdout. like, "hey girl, line 42, column 7, that's not valid", but in machine output.
  • --style-check β€” lexes and parses sourceFiles and prints the line and column number of any static analysis check failures to stdout. this is the one that judges your formatting. it's giving strict best friend energy. πŸ‘€
  • --error-format=VALUE β€” sets the format for the errors that the style/syntax checkers spit out.
  • --report β€” generates a static analysis report in JSON format. for when you want receipts. πŸ“„
  • --report-format=VALUE β€” tells it what format the generated report should be in.
  • --report-file=VALUE β€” writes the report to a file. yes, file = the thing you save instead of just staring at it in your terminal.
  • --import-paths=VALUE β€” import paths. that's the whole description. it's import paths. go off. πŸ›£οΈ
  • --dscanner-config=VALUE β€” use the given d-scanner configuration file. tell the linter what rules it's playing by.
  • --dest=VALUE β€” the base directory where the output artifacts get placed. (the original has a lil typo here, "atifacts", but she means artifacts, we love her anyway πŸ’–)
  • -b, --build=VALUE β€” specifies the type of build to perform. important: if you set the DFLAGS environment variable, it will override the build type with your custom flags β€” so don't act surprised, i warned you. possible names: debug, plain, release, release-debug, release-nobounds, unittest, profile, profile-gc, docs, ddox, cov, cov-ctfe, unittest-cov, unittest-cov-ctfe, syntax and custom types.
  • -c, --config=VALUE β€” builds the specified configuration. configurations live in dub.json, so that's where you go define them, queen. πŸ‘‘
  • --override-config=VALUE β€” uses the specified configuration for a certain dependency. can be specified multiple times. format: --override-config=<dependency>/<config>
  • --compiler=VALUE β€” specifies the compiler binary to use (and yes, it can be a path). arbitrary pre- and suffixes on the identifiers below are recognized (e.g. ldc2 or dmd-2.063) and matched to the proper compiler type: dmd, gdc, ldc, gdmd, ldmd.
  • -a, --arch=VALUE β€” forces a different architecture (e.g. x86 or x86_64). sometimes you just gotta be a different architecture. 🌈
  • -d, --debug=VALUE β€” defines the specified debug version identifier when building β€” can be used multiple times. stack 'em.
  • --d-version=VALUE β€” defines the specified version identifier when building β€” also stackable multiple times. use sparingly, because with great power comes great responsibility! for commonly used or combined versions, and versions that dependees should be able to use, go create configurations in your package instead. fr fr, that's the move.
  • --nodeps β€” do not resolve missing dependencies before building. bold. slightly chaotic. πŸ’€
  • --build-mode=VALUE β€” specifies the way the compiler and linker are invoked. valid values: separate (default), allAtOnce, singleFile.
  • --single β€” treats the package name as a filename. that file has to contain a package recipe comment, so no funny business.
  • --force-remove β€” deprecated option that does nothing. it's literally just standing there, menacingly. πŸ™ˆ
  • --filter-versions β€” [Experimental] filters version identifiers and debug version identifiers to improve build cache efficiency. experimental means experimental, bestie, don't come for me if it's weird.

πŸ’œ COMMON OPTIONS πŸ’œ

see dub(1). the classics live over there, iykyk.


πŸ“ EXIT STATUS πŸ“

vibe check results, in number form:

  • 0 β€” DUB succeeded. slay. πŸŽ‰
  • 1 β€” usage errors, unknown command line flags. you typed something cursed.
  • 2 β€” package not found, package failed to load, miscellaneous error. the "it's not you it's the filesystem" category. 😭

🧚 FILES 🧚

dub.sdl, dub.json

these two, these are the ones. πŸ“


⭐ AUTHOR ⭐

Copyright (c) 1999-2026 by The D Language Foundation. they've been doing this since before you were born, probably. respect the elders. 🫢


πŸ”₯ ONLINE DOCUMENTATION πŸ”₯

http://code.dlang.org/docs/commandline ⟨⟩ β€” go read, it's free.


πŸ‘‘ SEE ALSO πŸ‘‘

the whole friend group, together at last. πŸ’–


okay that's the whole page!! brought to you by The D Language Foundation, dated 2026-08-16 β€” and yes, she's still serving. now go lint your code, bestie, your syntax deserves it. βœ¨πŸ¦‹πŸ’… periodt.

πŸ“¦ where this page comes from