Filecoin network. This repository also contains the build scripts and tools to create the Filecoin docs website. Explore the docs β
This repository manages the documentation for theTable of contents
Getting Started
Follow these simple example steps to get a local version of the site up and running.
Prerequisites
To run these commands, you must have NPM installed. If you already have NPM installed, make sure you are running the latest version:
npm install npm@latest -g
Installation
Follow these steps to run a copy of this site on your local computer.
-
Clone this repository:
git clone https://github.com/filecoin-project/filecoin-docs
-
Move into the new folder and download the dependencies:
cd filecoin-docs npm install
-
Build and serve the project locally:
npm run start
- Visit localhost:1313 to view the site.
- Press
CTRL
+c
in the terminal to stop the local server.
If you want to just build the site but not serve it locally, run:
npm run build
A static site will be built and stored in the /public
directory.
About the project
This repository manages the documentation for the Filecoin project. This repository also contains the build scripts and tools to create the Filecoin docs website and the API documentation. If you want to learn about Filecoin, how it works, or how to build on it, then you're in the right place.
Merge process
This project receives a lot of pull requests from many individual contributors. Because of this, the Filecoin Docs team merges any new changes into production
on Wednesdays only. Any commits or PRs into this repo on any other day will land in the staging
branch. This process has several benefits:
- Reviewing and editing content is more manageable.
- Mass formatting, spelling, and grammar changes can happen on a single branch.
- Breaking changes are much less likely.
Only issues and PRs tagged as p0
will be merged directly into production
outside the Wednesday merge window. Take a look at the Priority section for information on how we tag issues.
Files and folders
This section lists the various files and folders and defines the purpose for each of them.
Name | Purpose |
---|---|
.git , .github |
Manage the git configurations and contain information for GitHub constant integrations. |
README.md |
This file. Acts as an introduction to this repository and how to spin up a local copy of the docs.filecoin.io site. |
archetypes/ |
Used by Hugo to programmatically create new pages. |
assets/ |
Assets like JavaScript and fonts used by Hugo to create the static site. These assets are not explorable in a built site. You must reference them in the code before building the site. |
babel.config.js |
A configuration file used for the Babel JS compiler. |
config/ |
Contains the configuration files for Hugo. You can manage things like the top-bar menu and site title within this directory. |
content/ |
This is where all the .md files live that control the content of this site. Most contributions happen in this directory. |
data/ |
You can supply extra variables for Hugo to use when building pages in this directory. These variables act just like front-matter variables. See Data Templates in the Hugo docs for more info. |
functions/ |
Functions callable from any template, partial, or shortcode within Hugo. |
i18n/ |
Contains files specific to managing different languages. |
layouts/ |
This is where web developers will likely spend most of their time. This folder contains the shortcodes and partials that Hugo uses to scaffold and build the site. |
node_modules/ |
Where NPM throws its packages. If you see this in GitHub, something's gone wrong. It should only exist on your computer after you run npm install . |
package-lock.json |
One of the NPM configuration files. Specify which version of packages to download. |
package.json |
Another one of the NPM configuration files. Specifies which packages to download but doesn't specify which version of the package to grab. |
resources/ |
A cache where Hugo throws generated files like CSS and JSON after npm run build has been called. Unless npm run clean is called, Hugo will re-use these files when calling npm run build . |
static/ |
Images, CSS, fonts, and other misc files that are available at docs.filecoin.io/ when the site is built. For example, docs.filecoin.io/site.webmanifest . |
theme.toml |
A Hugo configuration file that specifies which theme to use. This file should not change that often. |
Contributing
Want to help out? Pull requests (PRs) are always welcome! If you want to help out but aren't sure where to start, check out the issues board.
Front-matter variables
The front-matter is that small section of metadata you can find at the top of each .md
file within the /content
folder. Each variable has a specific purpose, and while not all are necessary, it's useful to know what they do and why they exist.
---
title: "Get started"
description: "The Filecoin Network is made with storage providers and clients. They make deals and contribute to maintaining the Filecoin blockchain, obtaining storage services, and receiving rewards in the process. This section walks you through how to get started, build a node, and create a simple application."
lead: "The Filecoin Network is made with storage providers and clients. They make deals and contribute to maintaining the Filecoin blockchain, obtaining storage services, and receiving rewards in the process. This section walks your through how to get started, build a node, and create a simple application."
menu:
getstarted:
parent: "getstarted-overview"
aliases:
- /get-started
- /how-to/install-filecoin
---
It's also good to note that we use the YAML as our front-matter format. We could use JSON or TOML if we really wanted, but we found YAML the easiest to read. Plus, YAML is fun to say.
This list has been created in order of commonality; variables you will come across most often are closer to the top of this list.
Title
The title
variable defines what the <h1>
tag on this page will say, along with the contents of <title>
in this page's <head>
. This variable also defines what is shown as the sidebar item; however, this can be overwritten in the menus
config file.
---
title: "Get started"
---
Description
The description
variable defines what is in the meta <description>
tag within the <head>
tag of this page's HTML. This description often shows up in search engine results and social network embeds. This description is meant to give the reader an idea of the content on this page and how it relates to their search query.
---
description: "The Filecoin Network is made with storage providers and clients. They make deals and contribute to [...]"
---
Lead
The lead
variable defines the content of the first paragraph on a page. This is usually an introduction, informing the reader what this page is referring to, what they're about to learn, and any prerequisites for understanding the content on this page. Often, the content of this variable is the same as the description
variable.
---
lead: "The Filecoin Network is made with storage providers and clients. They make deals and contribute to [...]"
---
Weight
The weight
variable defines where this page or menu item should be in a menu. The lower the number, the closer to the start of the menu this page will be. If set, weight
should be non-zero, as 0
is interpreted as an unset weight. There is no upper limit for a weight value.
In the top-bar menu, a lower number will cause the menu item to be further to the left in a regular view or further to the top in a mobile view.
This example is from the /config/_default/menus/menus.en.toml
file:
[[main]]
name = "About Filecoin"
url = "/about-filecoin/what-is-filecoin"
weight = 10
[[main]]
name = "Networks"
url = "/networks/overview"
weight = 20
[[main]]
name = "Get started"
url = "/get-started/overview"
weight = 30
In the sidebar menu, a lower number will cause the menu item or page to be higher up.
The weight of a page also defines the next and previous buttons at the bottom of the page. The previous page will be the page with the closest weight below the current page's weight. The next page will be the page with the closest weight above the current page's weight.
Menu
The menu
variable defines which sidebar menu this page is assigned to, along with which sub-menu this page falls under. This variable is made of three parts:
- The
menu
delimiter. This tells Hugo that were are about to define the menu object for this page. - The section/top-bar menu that this page falls under.
- The sub-menu within the sidebar that this page falls under.
---
menu:
store:
parent: "store-filecoin-plus"
---
Sidebar menu
Each section has its own sidebar menu. The name of each sidebar menu is usually a lowercase version of the name of the section. For sections that contain a space, the sidebar menu name is a lowercase version of the section without the space:
Section | Sidebar menu name |
---|---|
Basics | basics |
Store | store |
Storage providers | providers |
Nodes | nodes |
Smart contracts | smart-contracts |
Networks | networks |
Reference | reference |
menu:
smart-contracts:
parent: "smart-contracts-fundamentals"
identifier: "overview-3c010e7c403589b274c1d6d9dd0311c5"
Sub-menu
You can think of a sub-menu as the dropdown item in the sidebar menu. Sub-menus are defined in /config/\_default/menus/menus.en.toml
.
Each sub-menu is a child of a sidebar menu. A sidebar menu can contain multiple sub-menus, but a sub-menu can only belong to one sidebar menu.
Sub-menus are made up of:
name
: The visible text shown to the user.weight
: How high or low this sub-menu is shown within the sidebar.identifier
: A unique string used in the front-matter to specify this particular sub-menu.url
: The default page a user will go to if they click on this sub-menu link.
[[main]]
name = "Smart Contracts"
url = "/smart-contracts/fundamentals/the-filecoin-virtual-machine/"
weight = 40
identifier= "main-smart-contracts"
[[main]]
name = "Fundamentals"
url = "/smart-contracts/fundamentals/the-filecoin-virtual-machine/"
weight = 10
parent = "main-smart-contracts"
[[main]]
name = "Filecoin EVM runtime"
url = "/smart-contracts/filecoin-evm-runtime/actor-types/"
weight = 20
parent = "main-smart-contracts"
To assign a page to a sub-menu, you must supply both the menu object name and the identifier
value into the front-matter:
menu:
getstarted:
parent: "getstarted-overview"
The identifier of each sub-menu is usually the menu object name and the title of the sub-menu, all in lowercase with dashes -
:
Aliases
The aliases
variable defines URLs that will redirect to this page. Each page can have multiple aliases
, but each alias can only appear once throughout all the .md
files within the /content
folder.
For example, the /get-started/overview
page can list /get-started
as one of its aliases. However, no other page can list /get-started
as an alias. If you attempt to assign another page the /get-started
alias, Hugo will throw an error when you or Fleek try to build the website.
Aliases only work for internal links. You cannot assign a redirect to an external website using an alias.
---
aliases:
- /get-started
- /how-to/install-filecoin
---
Draft
The draft
variable, when set to true
, will hide the page from all site navigation. The page will still be accessible by visiting its URL. If this variable is not set, Hugo will assume that it is set to false
.
draft: true
This feature is generally used when we need to share content that isn't fully complete, but some users could benefit from its information at this exact moment.
Features
This project contains some handy features you can include within your project.
Pre-commit linters
This feature is currently in beta. If you believe that the pre-commit step incorrectly flagged something that it shouldn't have, or you just need help with the linters, please reach out to the docs team directly so we may assist you. For the fastest response, find us in the public #pl-docs channel.
Before local changes can be committed to filecoin-docs
, a custom shell script to check Markdown file quality using NPM packages is run. To use the pre-commit linters, follow the steps described below:
-
In a local copy of the repository, make changes to one or more more Markdown files.
-
Stage the changes:
git add .
-
Commit the staged changes locally with a short and useful message describing the commit
<commit-msg>
:git commit -m "<commit-msg>"
-
The pre-commit step is triggered, where the following open-source linters are run against all locally committed files, as described below:
Linter Usage Command used Configuration markdown-spellcheck
Flag misspelled words, improper terminology mdspell -r -a -n --en-us
.spelling
markdownlint-cli2
Flag improperly formatted markdown markdownlint-cli2
.markdownlint-cli2.jsonc
markdown-link-check
Flag broken URLs markdown-link-check --config .mdlinkcheck-config.json -q -p
.mdlinkcheck-config.json
The script combines the output of these linters, and does one of the following:
- Fails and rejects the commit if any issues are flagged, and reports those issues to the user:
- Spelling
- Markdown formatting
- Broken links
- Succeeds and accepts the commit if no markdown files were changed or no errors were found.
- Fails and rejects the commit if any issues are flagged, and reports those issues to the user:
Before you can commit to the repository, you must fix any errors identified. To do so, follow the steps below:
Fix broken links
- Fix any improperly formatted links.
- Remove or replace any links that are returning a 404.
Fix markdown formatting
-
Open a terminal window in the root directory of
filecoin-docs
and runformat-fix.sh
:sh format-fix.sh
The following occurs:
- The script attempts to auto-fix identified errors. Only certain errors are automatically fixable, so this will not usually catch everything.
- A summary of any remaining errors that the script could not automatically fix is displayed.
-
Fix the remaining Markdown formatting errors.
Fix spelling mistakes
Open a terminal window in the root directory of filecoin-docs
and run spell-fix.sh
:
sh spell-fix.sh
The following occurs:
- A summary of all spelling errors found in the changed file is displayed.
- Interactive spelling fix mode starts.
Using interactive spelling mode, you can quickly address each spelling error (highlighted in red) by doing the following:
- Using the arrow keys, select one of the following options:
Ignore
will ignore the word and not ask about it again in the current run. If spell check is run again, it will be flagged.Add to file ignores
will ignore the word in this file only.Add to dictionary - case insensitive
will add to the dictionary for all files and match any case. Because this option updates the repository dictionary, the docs team will require further review.Add to dictionary - case sensitive
will add to the dictionary for all files and match the case that has been used. Because this option updates the repository dictionary, the docs team will require further review.Enter correct spelling
will allow you to manually enter the correct spelling.- Any of the suggested fixes that the tool lists below
Enter correct spelling
.
- Once you've selected an option, press the Enter key.
- Repeat steps 2 and 3 until no more errors remain.
Archived content
Old pages can be archived and hidden from the sidebar view. However, they can still be accessed for historical purposes.
To archive a page:
-
Move the page and any associated images into the
/content/en/archive
directory. -
Add an alias redirect using the original location of this file:
--- ... aliases: - "/build/tools/filecoin-pinning-services/" ---
-
Add the following shortcode to the top of the page, just below the front-matter
--- {{< archived-content >}} ...
Take a look at the /content/en/archive
directory for examples.
Code tabs
We can use code tabs to split a section or instruction into different parts based on programming language, operating system, or something else.
The following code creates three code tabs called JavaScript, Go, and Rust:
{{< tabs tabTotal="3">}}
{{< tab tabName="JavaScript" >}}
<pre>
function main() {
console.log("Hello world");
}
</pre>
{{< /tab >}}
{{< tab tabName="Go" >}}
<pre>
package main
import "fmt"
func main() {
fmt.Println("Hello world")
}
</pre>
{{< /tab >}}
{{< tab tabName="Rust">}}
<pre>
fn main() {
println!("Hello World");
}
</pre>
{{< /tab >}}
{{< /tabs >}}
Tooltips
To make understanding terms in the docs a bit easier, users can hover over certain terms to get a short definition. These descriptions are located within a dict
variable at the top of the layouts/shortcodes/tooltip.html
shortcode:
<!-- Create an array/map of all possible tooltips. -->
{{ $tooltips := dict
"dApps" "Decentralized applications that don't rely on centralized infrastructure."
"IPFS" "The InterPlanetary File System (IPFS) is a peer-to-peer protocol for sharing and storing files on the internet, designed to be decentralized and distributed."
"Lotus" "The reference node implementation for the Filecoin network."
"Lily" "Software designed to simplify the recording of blockchain data."
"web3" "A new iteration of the World Wide Web which incorporates concepts such as decentralization, blockchain technologies, and token-based economics."
}}
Within your markdown, you can use one of these tooltips with the following syntax:
[...] storage on {{< tooltip "IPFS" >}} with blockchain-powered [...]
The tooltip should show up once the site has been built:
Issues
Found a problem with the Filecoin docs site? Please raise an issue. Be as specific and descriptive as possible; screenshots help!
Priority
We use p
tags to define the priority of an issue. The priority is defined by the docs team using the following definitions:
Label | Impact | Due date | Example |
---|---|---|---|
P0 | Severely business-impacting | Same day. Drop everything and fix it immediately. | The website is down. |
P1 | Business-impacting. | Within three days. | The API endpoint for a project is about to change. |
P2 | Planned project request. | Within two weeks. | A new method will soon be added to a project API. |
P3 | Suggestion or conceptual update. | No due date. | A blog post discussing the benefits of decentralization for web developers. |
P4 | Deprioritized suggestions. These will not be addressed unless significant activity or community requests are received. | No due date. | Add a dark theme to the docs. |
License
Dual-licensed: MIT, Apache Software License v2, by way of the Permissive License Stack.