Welcome to the Fern documentation! This repository contains the source code for Fern's comprehensive documentation site, currently live at buildwithfern.com/learn.
Before you begin, make sure you have the following installed:
-
Install the Fern CLI globally:
npm install -g fern-api
-
Clone this repository:
git clone <repository-url> cd docs
To run the documentation site locally:
-
Start the development server:
fern docs dev
-
Open your browser and navigate to:
http://localhost:3000
The development server will automatically reload when you make changes to the documentation files.
Thanks for contributing to Fern's documentation!
Keep the following principles in mind:
- Write for your audience - Consider why users are reading your documentation and explain the use case clearly. Focus on clarity and completeness without being verbose. Add examples and code snippets when relevant.
- Help users get something done. Don't try to sell users on the product, and avoid marketing language like "amazing features" or "the best solution."
- Avoid time-specific language. Don't mention a product or feature was just released or is the newest form, as this will quickly lead to stale documentation.
- Write in clear, concise language, using active voice whenever possible. Keep sentences and paragraphs short and to the point. Be conversational and friendly tone. Stay away from jargon as much as you can.
- Use Fern’s documentation components whenever you can.
- When editing an existing page - Match the existing heading structure, tone, and level of detail to ensure your changes integrate as seamlessly as possible.
- Use diagrams when it makes sense – Show, don't tell! Use Mermaid, a Markdown-like diagramming syntax, to illustrate a workflow.
- Use sentence case for page and section headings.
"Break any of these rules sooner than say anything outright barbarous."
—George Orwell, "Politics and the English Language"
Our style guide is influenced by Google's developer documentation style guide and Microsoft's writing style guide.
We use Vale to check contributions for grammar, style consistency, and adherence to our writing guidelines. Our Vale configuration uses the Microsoft style guide plus custom rules for Fern's style and terminology.
Vale runs automatically on PRs that modify .mdx files and comments with style suggestions (non-blocking).
Style guidelines enforced by Vale
The Vale linter enforces the following style guidelines:
Language and tone
- Avoid unnecessary adverbs (very, really, extremely, etc.) that don't add meaning
- Don't use "please" in technical documentation
- Use first person (I, me) sparingly
- Avoid first-person plural (we, our, let's)
- Write in an objective, instructional tone
Time-relative language
- Avoid terms that become outdated: currently, presently, now, future, soon, latest, upcoming, old
- Write documentation that remains accurate over time
Headings
- Use sentence-case capitalization (capitalize only the first word and proper nouns)
- Don't use end punctuation (periods, question marks, exclamation points)
Acronyms
- Define acronyms on first use unless they're in the exceptions list (common technical acronyms like API, SDK, CLI, HTTP, JSON, etc.)
- Format: "Application Programming Interface (API)"
Terminology
- Use "Fern Editor" instead of "Visual Editor"
- Use "API Reference" (capitalized) consistently
- Use "API Explorer" (capitalized) consistently
Formatting
- Don't hyphenate adverbs ending in -ly (e.g., "quickly moving" not "quickly-moving")
Use Vale locally
To catch issues earlier in your workflow, set up Vale to run automatically on your machine when you commit:- Install pre-commit:
brew install pre-commit - Install the hook:
pre-commit install
If you want to add a new page or make a large structural change:
- File an issue in GitHub and assign @devalog, @kgowru, or @dsinghvi. We'll review your issue to make sure your proposed page fits with Fern's overall documentation strategy and isn't duplicating any ongoing work.
For all other changes:
- Submit a PR directly with your suggested changes. A Fern docs member will review and confirm.
If you see something that is wrong or outdated in the documentation but don't know how to fix it, file an issue or reach out to @devalog, @kgowru, or @dsinghvi.