This code and its associated production website are included in Mozilla’s web and services [bug bounty program]. If you find a security vulnerability, please submit it via the process outlined in the program and [FAQ pages]. Further technical details about this application are available from the [Bug Bounty Onramp page].
| yarn amo:dev | Start the dev server/proxy (for amo) using data from the dev server (https://addons-dev.allizom.org/) |
| yarn amo:dev-https | Same as `amo:dev` but with HTTPS, available at: https://example.com:3000/. [Read about setting up this environment](docs/moz-addon-manager.md#developing-with-a-local-https-server-recommended) |
| yarn amo:stage | Start the dev server/proxy (for amo) using data from the staging server (https://addons.allizom.org/) |
- When you start `yarn test`, you can switch to your code editor and begin adding test files or changing existing code. As you save each file, [jest][] will only run tests related to the code you change.
- If you had typed `a` when you first started then [jest][] will continue to run the full suite even when you change specific files. Type `o` to switch back to the mode of only running tests related to the files you are changing.
- Sometimes running tests related to your file changes is slow. In these cases, you can type `p` or `t` to filter tests by name while you working fixing a specific test suite. [More info](https://github.com/jest-community/jest-watch-typeahead).
- If you see something like `Error watching file for changes: EMFILE` on Mac OS then `brew install watchman` might fix it. See https://github.com/facebook/jest/issues/1767
To explicitly run a subset of tests, you can type `t` or `p` which are explained in the [jest][] watch usage.
Alternatively, you can start the test runner with a [specific file or regular expression](https://facebook.github.io/jest/docs/en/cli.html#jest-regexfortestfiles), like:
- Check out the [getting started](https://flow.org/en/docs/getting-started/) guide.
- Read through the [web-ext guide](https://github.com/mozilla/web-ext/blob/master/CONTRIBUTING.md#check-for-flow-errors) for hints on how to solve common Flow errors.
To add flow coverage to a source file, put a `/* @flow */` comment at the top. The more source files you can opt into Flow, the better.
- We use Flow to **declare the intention of our code** and help others refactor it with confidence. Flow also makes it easier to catch mistakes before spending hours in a debugger trying to find out what happened.
- Avoid magic [Flow declarations](https://flowtype.org/en/docs/config/libs/) for any _internal_ code. Just declare a [type alias](https://flowtype.org/en/docs/types/aliases/) next to the code where it's used and [export/import](https://flow.org/en/docs/types/modules/) it like any other object.
- Never import a real JS object just to reference its type. Make a type alias and import that instead.
- Never add more type annotations than you need. Flow is really good at inferring types from standard JS code; it will tell you when you need to add explicit annotations.
- When a function like `getAllAddons` takes object arguments, call its type object `GetAllAddonsParams`. Example:
- Use [Exact object types](https://flowtype.org/en/docs/types/objects/#toc-exact-object-types) via the pipe syntax (`{| key: ... |}`) when possible. Sometimes the spread operator triggers an error like 'Inexact type is incompatible with exact type' but that's a [bug](https://github.com/facebook/flow/issues/2405). You can use the `Exact<T>` workaround from [`src/amo/types/util`](https://github.com/mozilla/addons-frontend/blob/master/src/amo/types/util.js) if you have to. This is meant as a working replacement for [\$Exact<T>](https://flow.org/en/docs/types/utilities/#toc-exact).
- Add a type hint for components wrapped in HOCs (higher order components) so that Flow can validate calls to the component. We need to add a hint because we don't yet have decent type coverage for all the HOCs we rely on. Here is an example:
- Try to avoid loose types like `Object` or `any` but feel free to use them if you are spending too much time declaring types that depend on other types that depend on other types, and so on.
- You can add a `$FlowFixMe` comment to skip a Flow check if you run into a bug or if you hit something that's making you bang your head on the keyboard. If it's something you think is unfixable then use `$FlowIgnore` instead. Please explain your rationale in the comment and link to a GitHub issue if possible.
- If you're stumped on why some Flow annotations aren't working, try using the `yarn flow type-at-pos ...` command to trace which types are being applied to the code. See `yarn flow -- --help type-at-pos` for details.
We use [Prettier][] to automatically format our JavaScript code and stop all the on-going debates over styles.
### Pre-commit hook
We use [husky](https://github.com/typicode/husky) and [lint-staged](https://github.com/okonet/lint-staged) to configure and run a pre-commit hook whenever you add a commit locally using Git. This hook will automatically run `Prettier` on your code, and will also check it for `eslint` and `flow` errors. If any errors exist, you will see a message similar to:
`✔ Reverting to original state because of errors...`
which will be followed by the details of the error(s). The last line of output will say:
`husky > pre-commit hook failed (add --no-verify to bypass)`
As per this message, you can bypass this hook by adding `--no-verify` to your `git commit` command, but we do not recommend doing this. Instead, you should fix any errors reported and then run `git commit` again, and it should succeed.
This will print a table of files showing the percentage of code coverage. The uncovered lines will be shown in the right column but you can open the full report in a browser:
This configures the proxy to use `https://addons-dev.allizom.org` for API data. This command is the most common way to develop new frontend features. See the table of commands up above for similar ways to run the server.
To use a [local API server running in Docker](https://addons-server.readthedocs.io/en/latest/topics/install/index.html), you can use the `yarn amo` command. However, this is currently not working. See [issue-7196][].
Authentication will work when initiated from addons-frontend and will persist to addons-server but it will not work when logging in from an addons-server page. See [mozilla/addons-server#4684](https://github.com/mozilla/addons-server/issues/4684) for more information on fixing this.
If you need to override any settings while running `yarn amo`, `yarn amo:dev`, or `yarn amo:stage`, first create a local config file named exactly like this:
Consult the [config file loading order docs](https://github.com/lorenwest/node-config/wiki/Configuration-Files#file-load-order) to learn more about how configuration is applied.
### Configuring an Android device for local development
If you want to access your local server on an Android device you will need to change a few settings. Let's say your local machine is accessible on your network at the IP address `10.0.0.1`. You could start your server like this:
```
API_HOST=http://10.0.0.1:3000 \
SERVER_HOST=10.0.0.1 \
WEBPACK_SERVER_HOST=10.0.0.1 \
yarn amo:dev
```
On your Android device, you could then access the development site at `http://10.0.0.1:3000`.
**NOTE**: At this time, it is not possible to sign in with this configuration because the Firefox Accounts client redirects to `localhost:3000`. You may be able to try a different approach by editing `/etc/hosts` on your device so that `localhost` points to your development machine but this has not been fully tested.
When developing locally with a webpack server, the randomly generated asset URL will fail our Content Security Policy (CSP) and clutter your console with errors. You can turn off all CSP errors by settings CSP to `false` in any local config file, such as `local-development-amo.js`. Example:
The documentation you are reading right now lives inside the source repository as [Github flavored Markdown](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown). When you make changes to these files you can create a pull request to preview them or, better yet, you can use [grip](https://github.com/joeyespo/grip) to preview the changes locally. After installing `grip`, run it from the source directory like this:
**To run the app locally in production mode you'll need to create a config file for local production builds.** Production builds can be built for different environments: `dev`, `stage` and `prod` (controlled by the `NODE_CONFIG_ENV` env var), but only one extra config file is needed for these environments to run locally.
Rename the file named `config/local.js.dist` to `config/local.js`. After this, re-build and restart using `yarn build` and `yarn start` as documented above. If you have used `127.0.0.1` before with a different configuration, be sure to clear your cookies. The application should be available at: http://127.0.0.1:4000/.
You can check to see what commit of `addons-frontend` is deployed, which A/B experiments are running, or which feature flags are enabled by making a request like this:
-`yarn build:blog-utils-dev`: build the library, start a watcher to rebuild the library on change and serve a development page at http://127.0.0.1:11000
In order to publish a new version of `addons-frontend-blog-utils`, a special tag has to be pushed to the main repository. The tag name must starts with `blog-utils-` and usually contains the version number. This can be automated using the following command:
```
npm version [major|minor|patch]
```
Once the commit and the tag have been created, push them to the main repository.
