|
| 1 | +# Expo Documentation |
| 2 | + |
| 3 | +This is the public documentation for **Expo**, its SDK, client and services. |
| 4 | + |
| 5 | +You can access this documentation online at https://docs.expo.io/. It's built using next.js on top of the https://github.com/zeit/docs codebase. |
| 6 | + |
| 7 | +### Running Locally |
| 8 | + |
| 9 | +Download the copy of this repostory. |
| 10 | + |
| 11 | +~~~sh |
| 12 | +git clone https://github.com/expo/expo-docs.git |
| 13 | +~~~ |
| 14 | + |
| 15 | +Then `cd` into the downloaded directory and install dependencies with: |
| 16 | + |
| 17 | +~~~sh |
| 18 | +yarn |
| 19 | +~~~ |
| 20 | + |
| 21 | +Then you can run the app with: |
| 22 | + |
| 23 | +~~~sh |
| 24 | +yarn run dev |
| 25 | +~~~ |
| 26 | + |
| 27 | +This starts two processes: a `next.js` server, and a compiler/watcher that converts markdown files into javascript pages that `next.js` understands. |
| 28 | + |
| 29 | +Now the documentation is running at http://localhost:3000 |
| 30 | + |
| 31 | +### Running in production mode |
| 32 | + |
| 33 | +~~~sh |
| 34 | +yarn run build |
| 35 | +yarn run start |
| 36 | +~~~ |
| 37 | + |
| 38 | +### Editing Docs Content |
| 39 | + |
| 40 | +[FUTURE] |
| 41 | + |
| 42 | +You can find the source of the documentation inside the `versions` directory. Documentation is mostly written in markdown with the help of some React components (for Snack embeds, etc). The routes and navbar are automatically inferred from the directory structure within `versions`. |
| 43 | + |
| 44 | +### Adding Images and Assets |
| 45 | + |
| 46 | +You can add images and assets in the same directory as the markdown file, and you just need to reference them correctly. |
| 47 | + |
| 48 | +### New Components |
| 49 | + |
| 50 | +Always try to use the existing components and features in markdown. Create a new component or use a component from NPM, unless there is no other option. |
| 51 | + |
| 52 | +### Quirks |
| 53 | + |
| 54 | +* You can can't have curly brace without quotes: '{}' -> `{}` |
| 55 | +* Make sure to leave a empty newline between a table and following content |
| 56 | + |
| 57 | +## Transition from current docs to next.js docs |
| 58 | + |
| 59 | +### Compile process |
| 60 | + |
| 61 | +#### FUTURE |
| 62 | + |
| 63 | +In both `yarn run start` and `yarn run dev`, we initially compile (see `mdjs` dir) all `.md` files in `docs` to `.js` files under `pages/versions` (which is git-ignored, and never commited). At this point, we also generate the json file `navigation-data.json` for the navbar, and move images in `docs` to the `static` folder. |
| 64 | + |
| 65 | +In `yarn run dev`, the watcher watches for changes to files in `docs`, and re-compiles as necessary. Note: navigation changes probably won't live-reload so make sure to restart the server. |
| 66 | + |
| 67 | +#### PRESENT |
| 68 | + |
| 69 | +On `yarn run start` and `yarn run dev`, we first fix all markdown files in `versions` (symlinked to `universe/docs/versions`) and copy them as new files under `docs` (which is git-ignored, and never commited). Then, we "compile" all markdown files in `docs` to javascript files under `pages/versions` (which is git-ignored, and never commited). At this point, we also generate the json file `navigation-data.json` for the navbar, and move images in `docs` to the `static` folder. |
| 70 | + |
| 71 | +### Temporary scripts |
| 72 | + |
| 73 | +At the moment, while we transition from the existing docs server to this next.js server, I have a `fix-markdown.js` that makes a couple of straightforward regex replacements, and moves markdown files in the workflow/distribution/expokit sections into seperate directories. |
| 74 | + |
| 75 | +### Not breaking existing incoming links |
| 76 | + |
| 77 | +`transition/sections.js` is used to figure out which URLs to alias. In order to not break existing URLs such as guides/configuration (the new URL is the more sensible workflow/configuration, automatically inferred from the fact that configuration.md is in the workflow subdir), in next.js, we support both so we need to keep a list of URLs to alias under guides. For future versions, the guides URL for `configuration` won't exist at all so we can slowly phase out this file. |
| 78 | + |
| 79 | +## A note about versioning |
| 80 | + |
| 81 | +Expo's SDK is versioned so that apps made on old SDKs are still supported |
| 82 | +when new SDKs are relased. The website documents previous SDK versions too. |
| 83 | + |
| 84 | +Version names correspond to directory names under `docs`. |
| 85 | + |
| 86 | +`unversioned` is a special version for the next SDK release. |
| 87 | + |
| 88 | +Sometimes you want to make an edit in version `X` and have that edit also |
| 89 | +be applied in versions `Y, Z, ...` (say, when you're fixing documentation for an |
| 90 | +API call that existed in old versions too). You can use the |
| 91 | +`./scripts/versionpatch.sh` utility to apply your `git diff` in one version in |
| 92 | +other versions. For example, to update the docs in `unversioned` then apply it |
| 93 | +on `v8.0.0` and `v7.0.0`, you'd do the following after editing the docs in |
| 94 | +`unversioned` such that it shows up in `git diff`: |
| 95 | + |
| 96 | +```./scripts/versionpatch.sh unversioned v8.0.0 v7.0.0``` |
| 97 | + |
| 98 | +Any changes in your `git diff` outside the `unversioned` directory are ignored |
| 99 | +so don't worry if you have code changes or such elsewhere. |
| 100 | + |
| 101 | +### Updating latest version of docs |
| 102 | + |
| 103 | +When we release a new SDK, we copy the `unversioned` directory, and rename it to the new version. Latest version of docs is read from `package.json` so make sure to update the `version` key there as well. However, if you update the `version` key there, you need to `rm -rf node_modules/.cache/` before the change is picked up (why? [read this](https://github.com/zeit/next.js/pull/1747/files)). |
| 104 | + |
| 105 | +That's all you need to do. The `docs` directory is listed on server start to find all available versions. The routes and navbar contents are automatically inferred from the directory structure within `docs`. So, `/versions/v24.0.0/guides/development-mode` refers to `pages/versions/guides/development-mode`. |
| 106 | + |
| 107 | +Because the navbar is automatically generated from the directory structure, the default ordering of the links under each section is alphabetical. However, for many sections, this is not ideal UX. So, if you wish to override the alphabetical ordering, manipulate page titles in `navbarOrder.js`. |
0 commit comments