addons-frontend/README.md

392 строки
18 KiB
Markdown
Исходник Обычный вид История

2016-02-22 21:53:09 +03:00
# Addons-frontend 🔥
2016-02-19 21:00:53 +03:00
2020-12-16 18:24:18 +03:00
[![Code of Conduct](https://img.shields.io/badge/%E2%9D%A4-code%20of%20conduct-blue.svg)](https://github.com/mozilla/addons-frontend/blob/master/CODE_OF_CONDUCT.md) [![CircleCI](https://circleci.com/gh/mozilla/addons-frontend.svg?style=svg)](https://circleci.com/gh/mozilla/addons-frontend) [![codecov](https://codecov.io/gh/mozilla/addons-frontend/branch/master/graph/badge.svg)](https://codecov.io/gh/mozilla/addons-frontend) [![Documentation](https://readthedocs.org/projects/addons-frontend/badge/?version=latest)](http://addons-frontend.readthedocs.io/en/latest/)
2018-06-27 23:24:49 +03:00
Front-end infrastructure and code to complement [mozilla/addons-server](https://github.com/mozilla/addons-server).
2016-02-19 21:00:53 +03:00
2016-09-08 14:18:04 +03:00
## Security Bug Reports
2017-08-02 06:22:16 +03:00
This code and its associated production website are included in Mozillas 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].
2016-09-08 14:18:04 +03:00
Please submit all security-related bugs through Bugzilla using the [web security bug form].
Never submit security-related bugs through a Github Issue or by email.
2018-06-27 23:24:49 +03:00
[bug bounty program]: https://www.mozilla.org/en-US/security/web-bug-bounty/
[faq pages]: https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/
[bug bounty onramp page]: https://wiki.mozilla.org/Security/BugBountyOnramp/
[web security bug form]: https://bugzilla.mozilla.org/form.web.bounty
2016-09-08 14:18:04 +03:00
2016-02-22 21:53:09 +03:00
## Requirements
2020-11-02 16:56:19 +03:00
- You need [Node](https://nodejs.org/en/) 10.x which is the current [LTS](https://github.com/nodejs/Release) (long term support) release.
2018-06-27 23:24:49 +03:00
- Install [yarn](https://yarnpkg.com/en/) to manage dependencies and run scripts.
2016-02-22 21:53:09 +03:00
2020-11-02 16:56:19 +03:00
The easiest way to manage multiple node versions in development is to use [nvm](https://github.com/nvm-sh/nvm).
2016-02-22 21:53:09 +03:00
2016-02-23 19:01:58 +03:00
## Get started
If you are on Windows, please make sure to follow [windows guidelines](docs/windows.md#windows) too.
2018-06-27 23:24:49 +03:00
- type `yarn` to install all dependencies
- type `yarn amo:stage` to start a local server that connects to a hosted staging server
## Development commands
Here are some commands you can run:
| Command | Description |
| --- | --- |
| yarn amo:olympia | Start the dev server/proxy (for amo) using data from a local addons-server environment. |
| 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/) |
| yarn build | Build the app. |
| yarn build-ci | Run the `build` and `bundlesize` npm scripts. |
| yarn bundlesize | Run [bundlesize][] to check the generated AMO bundle sizes. [Building AMO is required first](#building-and-running-services). |
| yarn flow | Run Flow. By default this checks for errors and exits |
| yarn flow:check | Explicitly check for Flow errors and exit |
| yarn flow:dev | Continuously check for Flow errors |
| yarn eslint | Lint the JS |
| yarn start-func-test-server | Start a Docker container for functional tests |
| yarn stylelint | Lint the SCSS |
| yarn storybook | Run [storybook](https://storybook.js.org/) |
| yarn lint | Run all the JS + SCSS linters |
| yarn prettier | Run [Prettier][] to automatically format the entire codebase |
| yarn prettier-dev | Run [Pretty-Quick][] to automatically compare and format modified source files against the master branch |
| yarn prettier-ci | Run [Prettier][] and fail if some code has been changed without being formatted |
| yarn version-check | Check you have the required dependencies |
| yarn test | Run all tests (Enters [jest][] in `--watch` mode) |
| yarn test-coverage | Run all tests and generate code coverage report (Enters [jest][] in `--watch` mode) |
| yarn test-coverage-once | Run all tests, generate code coverage report, then exit |
| yarn test-once | Run all tests, run all JS + SCSS linters, then exit |
| yarn test-ci | Run all continuous integration checks. This is only meant to run on TravisCI. |
### Running tests
2018-06-27 23:24:49 +03:00
You can enter the interactive [jest][] mode by typing `yarn test`. This is the easiest way to develop new features.
Here are a few tips:
2018-06-27 23:24:49 +03:00
- 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
#### Run a subset of the tests
2018-06-27 23:24:49 +03:00
By default, `yarn test` will only run a subset of tests that relate to the code you are working on.
2018-06-27 23:24:49 +03:00
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:
2017-05-29 23:14:24 +03:00
```
yarn test tests/unit/amo/components/TestAddon.js
2017-05-29 23:14:24 +03:00
```
#### Run all tests
If you want to run all tests and exit, type:
2018-06-27 23:24:49 +03:00
2017-05-29 23:14:24 +03:00
```
yarn test-once
2017-05-29 23:14:24 +03:00
```
2016-07-05 20:54:08 +03:00
2018-11-19 22:30:57 +03:00
### Eslint
As you run tests you will see a report of Eslint errors at the end of the test output:
yarn test
If you would like to run tests without Eslint checks, set an environment variable:
NO_ESLINT=1 yarn test
2017-04-17 21:37:35 +03:00
### Flow
There is limited support for using [Flow](https://flowtype.org/) to validate the intention of our program.
2017-04-17 21:37:35 +03:00
As you run tests you will see a report of Flow errors at the end of the test output:
yarn test
If you would like to run tests without Flow checks, set an environment variable:
NO_FLOW=1 yarn test
To only check for Flow issues during development while you edit files, run:
2017-04-17 21:37:35 +03:00
yarn flow:dev
2017-04-17 21:37:35 +03:00
If you are new to working with Flow, here are some tips:
2018-06-27 23:24:49 +03:00
- 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.
2017-04-17 21:37:35 +03:00
Here is our Flow manifesto:
2018-06-27 23:24:49 +03:00
- 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:
2017-04-17 21:37:35 +03:00
2017-05-29 23:14:24 +03:00
```js
2017-04-17 21:37:35 +03:00
type GetAllAddonsParams = {|
categoryId: number,
|};
function getAllAddons({ categoryId }: GetAllAddonsParams = {}) {
...
}
2017-05-29 23:14:24 +03:00
```
2017-04-17 21:37:35 +03:00
2018-11-07 13:12:28 +03:00
- 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/core/types/util`](https://github.com/mozilla/addons-frontend/blob/master/src/core/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).
2018-06-27 23:24:49 +03:00
- 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:
```js
// Imagine this is something like components/ConfirmButton/index.js
import { compose } from 'redux';
import * as React from 'react';
// This expresses externally used props, i.e. to validate how the app would use <ConfirmButton />
type Props = {|
prompt?: string | null,
|};
// This expresses internally used props, such as i18n which is injected by translate()
type InternalProps = {|
...Props,
i18n: I18nType,
|};
export class ConfirmButtonBase extends React.Component<InternalProps> {
render() {
const prompt = this.props.prompt || this.props.i18n.gettext('Confirm');
return <button>{prompt}</button>;
}
}
// This provides a type hint for the final component with its external props.
// The i18n prop is not in external props because it is injected by translate() for internal use only.
const ConfirmButton: React.ComponentType<Props> = compose(translate())(
ConfirmButtonBase,
);
export default ConfirmButton;
```
2018-06-27 23:24:49 +03:00
- 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.
2018-06-27 23:24:49 +03:00
- 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.
2017-04-17 21:37:35 +03:00
2018-06-22 21:55:18 +03:00
### Prettier
We use [Prettier][] to automatically format our JavaScript code and stop all the on-going debates over styles. As a developer, you have to run it (with `yarn prettier-dev`) before submitting a Pull Request.
2018-06-22 21:55:18 +03:00
### Code coverage
To see a report of code coverage, type:
2018-06-27 23:24:49 +03:00
2017-05-29 23:14:24 +03:00
```
yarn test-coverage-once
2017-05-29 23:14:24 +03:00
```
2018-06-27 23:24:49 +03:00
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:
2017-05-29 23:14:24 +03:00
```
open coverage/lcov-report/index.html
2017-05-29 23:14:24 +03:00
```
### Running AMO for local development
A proxy server is provided for running the AMO app with the API on the same host as the frontend. This mimics our production setup.
Start developing against a hosted API like this:
```
yarn amo:dev
```
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.
### Local configuration
2016-07-22 20:24:06 +03:00
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:
2016-07-22 20:24:06 +03:00
touch config/local-development-amo.js
2016-07-22 20:24:06 +03:00
Make any config changes. For example:
2016-07-22 20:24:06 +03:00
2017-05-29 23:14:24 +03:00
```javascript
2016-07-22 20:24:06 +03:00
module.exports = {
trackingEnabled: true,
2016-07-22 20:24:06 +03:00
};
2017-05-29 23:14:24 +03:00
```
2016-07-22 20:24:06 +03:00
Restart the server to see it take affect.
2016-07-22 20:24:06 +03:00
2018-06-27 23:24:49 +03:00
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.
### Disabling CSP for local development
2017-01-17 20:36:39 +03:00
2018-06-27 23:24:49 +03:00
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:
2017-01-17 20:36:39 +03:00
2017-05-29 23:14:24 +03:00
```javascript
2017-01-17 20:36:39 +03:00
module.exports = {
CSP: false,
};
2017-05-29 23:14:24 +03:00
```
2017-01-17 20:36:39 +03:00
### Working on the documentation
2018-06-27 23:24:49 +03:00
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:
```
grip .
```
2018-06-27 23:24:49 +03:00
Open its `localhost` URL and you will see the rendered `README.md` file. As you make edits, it will update automatically.
### Storybook
If you run `yarn storybook`, you can see storybook locally here: http://localhost:9001/.
You can find the source files under the ./stories directory.
Check it out on Github Pages: https://mozilla.github.io/addons-frontend/
More info coming soon :)
2016-07-05 20:54:08 +03:00
### Building and running services
2018-06-27 23:24:49 +03:00
The following are scripts that are used in deployment - you generally won't need unless you're testing something related to deployment or builds.
2016-04-15 22:29:27 +03:00
2016-07-05 20:54:08 +03:00
The env vars are:
2016-04-15 22:29:27 +03:00
- `NODE_ENV`: the node environment, e.g. `production` or `development`
- `NODE_CONFIG_ENV`: the name of the configuration to load, e.g., `dev`, `stage`, `prod`
2016-07-05 20:54:08 +03:00
2018-06-27 23:24:49 +03:00
| Script | Description |
| ---------- | ---------------------------------------------- |
| yarn start | Starts the express server (requires env vars) |
| yarn build | Builds the libs (all apps) (requires env vars) |
2016-04-15 22:29:27 +03:00
**Example:** Building and running a production instance of the app:
2016-04-15 22:29:27 +03:00
2017-05-29 23:14:24 +03:00
```
NODE_ENV=production NODE_CONFIG_ENV=prod yarn build
NODE_ENV=production NODE_CONFIG_ENV=prod yarn start
2017-05-29 23:14:24 +03:00
```
2017-05-18 00:07:06 +03:00
**Note: To run the app locally in production mode you'll need to create a config file for local production builds.** It must be saved as `config/local-prod-amo.js` and should look like:
2017-05-18 00:07:06 +03:00
2017-05-29 23:14:24 +03:00
```js
const amoCDN = 'http://127.0.0.1:4000';
2017-05-18 00:07:06 +03:00
module.exports = {
// CDN URL points to the Node server.
amoCDN,
2017-05-18 00:07:06 +03:00
// Configure CSP with 'self' since we serve the compiled files from `dist/`.
2017-05-18 00:07:06 +03:00
CSP: {
directives: {
fontSrc: ["'self'"],
imgSrc: ["'self'", 'data:', 'https://addons.cdn.mozilla.net'],
scriptSrc: ["'self'"],
2017-05-18 00:07:06 +03:00
styleSrc: ["'self'"],
},
reportOnly: true,
2017-05-18 00:07:06 +03:00
},
// Serve static via Node.
staticHost: undefined,
2017-05-18 00:07:06 +03:00
enableNodeStatics: true,
// No need for Sentry.
2017-05-18 00:07:06 +03:00
publicSentryDsn: null,
};
2017-05-29 23:14:24 +03:00
```
2017-05-18 00:07:06 +03:00
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/.
2017-05-18 00:07:06 +03:00
**NOTE**: At this time, it's not possible to sign in using this approach.
2016-02-24 14:26:46 +03:00
### Working with UX Mocks
When implementing user interfaces you will need to refer to the [Sketch](https://www.sketchapp.com/)-based mocks that are hosted on InVision: https://mozilla.invisionapp.com/share/YCCYEOFRH#/screens.
If you need to explore the Sketch source file, you will need a license to run Sketch and you also need to install some fonts (which are free). Install [Fira Sans](https://www.fontsquirrel.com/fonts/fira-sans), [Open Sans](https://www.fontsquirrel.com/fonts/open-sans), [Fira Mono](https://www.fontsquirrel.com/fonts/fira-mono) and [Chivo](https://www.fontsquirrel.com/fonts/chivo).
2018-06-27 23:24:49 +03:00
On MacOS, you can use the Homebrew tap [Caskroom-fonts](https://github.com/Homebrew/homebrew-cask-fonts):
```
brew tap homebrew/cask-fonts
brew cask install font-fira-sans font-open-sans font-chivo font-fira-mono
```
## What version is deployed?
You can check to see what commit of `addons-frontend` is deployed as well as which A/B experiments are running and which feature flags are enabled by making a request like this:
2017-05-29 23:14:24 +03:00
```
curl https://addons-dev.allizom.org/__frontend_version__
{
"build": "https://circleci.com/gh/mozilla/addons-frontend/10333",
"commit": "47edfa6f24e333897b25516c587f504e294e8fa9",
"experiments": {
"homeHero": true
},
"feature_flags": {
"enableFeatureAMInstallButton": true,
"enableFeatureExperienceSurvey": false,
"enableFeatureStaticThemes": true
},
"source": "https://github.com/mozilla/addons-frontend",
"version": ""
}
2017-05-29 23:14:24 +03:00
```
2018-06-27 23:24:49 +03:00
This will return a 415 response if a `version.json` file doesn't exist in the root directory. This file is typically generated by the deploy process.
2018-06-27 23:24:49 +03:00
For consistency with monitoring scripts, the same data can be retrieved at this URL:
2017-05-29 23:14:24 +03:00
```
curl https://addons-dev.allizom.org/__version__
2017-05-29 23:14:24 +03:00
```
:bulb: You can install the [amo-info extension](https://addons.mozilla.org/en-US/firefox/addon/amo-info/) to easily view this information.
2016-02-19 21:00:53 +03:00
## Core technologies
2018-06-27 23:24:49 +03:00
- Based on Redux + React
- Code written in ES2015+
- Universal rendering via node
- Unit tests with high coverage (aiming for 100%)
2018-08-06 22:26:17 +03:00
[bundlesize]: https://github.com/siddharthkp/bundlesize
2020-11-02 16:56:19 +03:00
[jest]: https://jestjs.io/docs/en/getting-started.html
2018-06-27 23:24:49 +03:00
[prettier]: https://prettier.io/