Usually not. Every dependency a tutorial adds is code from another author that readers install, trust and must update, along with everything that package pulls in. If the task is a few lines and not security sensitive, write it inline. For crypto, parsing and protocols, use a maintained library.
What a dependency costs
A package in a sample is not free. It brings its maintainers, its own dependencies, its install scripts and its future advisories. A tutorial about a small task that installs a dozen packages gives readers a dozen things to track. The reader who copies the sample into a product inherits all of them.
At the same time, rewriting everything is not safer. Home made cryptography and hand rolled parsers fail in ways libraries have already learned to avoid. The skill is knowing which side of the line a task is on.
A decision guide
| Task | Write inline | Use a maintained library |
|---|---|---|
| Pad a string, flatten a list, format a date | Yes | No |
| Read an environment variable | Yes | No |
| Hash passwords, encrypt data, sign tokens | No | Yes |
| Parse a complex format such as XML or a markup language | No | Yes |
| Validate an email address properly | No | Yes, or keep it minimal |
| HTTP client for a single call | Standard library often suffices | If features are needed |
| Webhook signature check | Standard library functions | Provider SDK if one is maintained |
Questions to ask before adding one
- Does the standard library already do this? Many do more than readers expect.
- How many lines would the task take, and how risky is getting it wrong?
- Is the package maintained? Look at recent releases, open issues and the number of maintainers.
- How big is its dependency tree? Install it in a scratch folder and count.
- Does it run install scripts?
- Will the tutorial still teach the concept? Hiding the idea behind a library can defeat the purpose.
If you do add one
Pin an exact version and ship the lockfile. See should tutorials pin dependency versions. Link the registry page so readers can confirm they have the right package, as described in how do typosquatted package names reach tutorial readers. Put the licence in the notes so readers know what they are taking on.
Record why the dependency is there, in a comment or in the README. Six months later someone will ask whether it can be removed.
Keep the tree small over time
Review the sample's dependencies on a schedule. Remove any that are no longer used, and update the rest after checking advisories. A tutorial that was minimal on day one drifts toward bloat if no one prunes it.
Where your docs teach many tasks, consider a shared sample project with one reviewed dependency list, so readers see a consistent, small set.
Try it yourself
Counting what a project really pulls in is the first step. Click through an inventory.
Click through it at your own pace, or open it full screen.
Safeguard's dependency scanning, SBOM generation and reachability analysis show which packages a project uses and which known issues can actually be reached. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is writing it inline always safer?
No. For cryptography and complex parsing, a maintained library is safer than home made code.
How can I see what a package really adds?
Install it in a scratch folder and list the resulting dependency tree and any install scripts.
Last reviewed: 19 October 2026.
