Mozilla/addons-server를 보완하는 프런트 엔드 인프라 및 코드입니다.
이 코드와 관련 생산 웹사이트는 Mozilla의 웹 및 서비스 버그 바운티 프로그램에 포함되어 있습니다. 보안 취약점을 발견한 경우 프로그램 및 FAQ 페이지에 설명된 프로세스를 통해 제출하십시오. 이 애플리케이션에 대한 자세한 기술 정보는 Bug Bounty Onramp 페이지에서 확인할 수 있습니다.
모든 보안 관련 버그는 웹 보안 버그 양식을 사용하여 Bugzilla를 통해 제출해 주시기 바랍니다.
절대로 Github 이슈나 이메일을 통해 보안 관련 버그를 제출하지 마세요.
개발 중인 여러 노드 버전을 관리하는 가장 쉬운 방법은 nvm을 사용하는 것입니다.
Windows를 사용하는 경우 Windows 지침도 따라야 합니다.
yarn
입력하세요.yarn amo:stage
입력하세요. 실행할 수 있는 몇 가지 명령은 다음과 같습니다.
명령 | 설명 |
---|---|
원사 아모:올림피아 | 로컬 애드온 서버 환경의 데이터를 사용하여 개발 서버/프록시(amo용)를 시작합니다. |
원사 아모:개발 | 개발 서버(https://addons-dev.allizom.org/)의 데이터를 사용하여 개발 서버/프록시(amo용)를 시작합니다. |
원사 아모:dev-https | amo:dev 와 동일하지만 HTTPS를 사용하며 https://example.com:3000/에서 사용할 수 있습니다. 이 환경 설정에 대해 읽어보세요. |
원사 아모:스테이지 | 스테이징 서버(https://addons.allizom.org/)의 데이터를 사용하여 개발 서버/프록시(amo용)를 시작합니다. |
원사 빌드 | 앱을 빌드합니다. |
원사 빌드-ci | build 및 bundlewatch npm 스크립트를 실행합니다. |
원사 묶음시계 | 생성된 AMO 번들 크기를 확인하려면 Bundlewatch를 실행하세요. 먼저 AMO 구축이 필요합니다. |
원사의 흐름 | 흐름을 실행합니다. 기본적으로 오류를 확인하고 종료합니다. |
실 흐름:확인 | 흐름 오류를 명시적으로 확인하고 종료합니다. |
원사 흐름:개발 | 흐름 오류를 지속적으로 확인하세요. |
원사 에스린트 | JS 린트 |
원사 시작 기능 테스트 서버 | 기능 테스트를 위해 Docker 컨테이너 시작 |
원사 스타일린트 | SCSS 린트 |
원사 린트 | 모든 JS + SCSS 린터 실행 |
실이 더 예뻐요 | Prettier를 실행하여 전체 코드베이스의 형식을 자동으로 지정하세요. |
원사 더 예쁜 개발 | 수정된 소스 파일을 마스터 브랜치와 자동으로 비교하고 포맷하려면 [Pretty-Quick][]을 실행하세요. |
원사 prettier-ci | Prettier를 실행하고 일부 코드가 형식화되지 않은 채 변경된 경우 실패합니다. |
원사 버전 확인 | 필요한 종속성이 있는지 확인하세요. |
원사 테스트 | 모든 테스트 실행( --watch 모드에서 jest 입력) |
원사 테스트 디버그 | 전체 콘솔 출력 및 전체 오류 메시지로 모든 테스트를 실행합니다( --watch 모드에서 jest 입력). |
원사 테스트 범위 | 모든 테스트를 실행하고 코드 적용 보고서 생성( --watch 모드에서 jest 입력) |
실 테스트 범위 - 한 번 | 모든 테스트를 실행하고 코드 적용 범위 보고서를 생성한 후 종료합니다. |
원사 테스트 1회 | 모든 테스트를 실행하고 모든 JS + SCSS 린터를 실행한 다음 종료합니다. |
원사 테스트-ci | 모든 지속적인 통합 확인을 실행합니다. 이는 CI에서만 실행하기 위한 것입니다. |
yarn test
또는 yarn test-debug
입력하여 대화형 Jest 모드로 들어갈 수 있습니다. 이는 새로운 기능을 개발하는 가장 쉬운 방법입니다.
다음은 몇 가지 팁입니다.
yarn test
대부분의 콘솔 출력과 자세한 테스트 실패 메시지를 숨기므로 전체 테스트 모음을 실행할 때 가장 좋습니다. 개별 테스트를 진행하는 경우에는 yarn test-debug
실행하고 싶을 것입니다.yarn test
시작하면 코드 편집기로 전환하여 테스트 파일을 추가하거나 기존 코드를 변경할 수 있습니다. 각 파일을 저장하면 jest는 변경한 코드와 관련된 테스트만 실행합니다.a
입력했다면 jest는 특정 파일을 변경하더라도 전체 제품군을 계속 실행합니다. 변경 중인 파일과 관련된 테스트만 실행하는 모드로 다시 전환하려면 o
입력합니다.p
또는 t
입력하여 이름별로 테스트를 필터링할 수 있습니다. 추가 정보.Error watching file for changes: EMFILE
과 같은 메시지가 표시되면 brew install watchman
이 문제를 해결할 수 있습니다. jestjs/jest#1767 참조 기본적으로 yarn test
작업 중인 코드와 관련된 테스트 하위 집합만 실행합니다.
테스트의 하위 집합을 명시적으로 실행하려면 jest watch 사용법에 설명된 t
또는 p
입력하면 됩니다.
또는 다음과 같이 특정 파일이나 정규식을 사용하여 테스트 실행기를 시작할 수 있습니다.
yarn test tests/unit/amo/components/TestAddon.js
모든 테스트를 실행하고 종료하려면 다음을 입력하십시오.
yarn test-once
테스트를 실행하면 테스트 출력 끝에 Eslint 오류 보고서가 표시됩니다.
yarn test
Eslint 검사 없이 테스트를 실행하려면 환경 변수를 설정하세요.
NO_ESLINT=1 yarn test
프로그램의 의도를 검증하기 위해 Flow를 사용하는 것에 대한 지원은 제한적입니다.
테스트를 실행하면 테스트 출력 끝에 Flow 오류 보고서가 표시됩니다.
yarn test
흐름 검사 없이 테스트를 실행하려면 환경 변수를 설정하세요.
NO_FLOW=1 yarn test
파일을 편집하는 동안 개발 중에 Flow 문제만 확인하려면 다음을 실행하세요.
yarn flow:dev
Flow를 처음 사용하는 경우 다음과 같은 몇 가지 팁을 참고하세요.
소스 파일에 흐름 적용 범위를 추가하려면 상단에 /* @flow */
주석을 추가하세요. Flow에 선택할 수 있는 소스 파일이 많을수록 좋습니다.
Flow 선언문은 다음과 같습니다.
getAllAddons
와 같은 함수가 객체 인수를 취하는 경우 해당 유형 객체 GetAllAddonsParams
호출합니다. 예: type GetAllAddonsParams = { |
categoryId : number ,
| } ;
function getAllAddons ( { categoryId } : GetAllAddonsParams = { } ) {
...
}
{| key: ... |}
)을 통해 정확한 객체 유형을 사용하세요. 때때로 스프레드 연산자가 '정확하지 않은 유형이 정확한 유형과 호환되지 않습니다'와 같은 오류를 유발하지만 이는 버그입니다. 필요한 경우 src/amo/types/util
에서 Exact<T>
해결 방법을 사용할 수 있습니다. 이는 $Exact를 대체하는 작업을 의미합니다. // 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 ;
Object
또는 any
와 같은 느슨한 유형은 피하십시오. 그러나 다른 유형에 의존하는 다른 유형에 의존하는 유형을 선언하는 데 너무 많은 시간을 소비하는 경우에는 자유롭게 사용하십시오.$FlowFixMe
주석을 추가하여 Flow 검사를 건너뛸 수 있습니다. 수정이 불가능하다고 생각되는 문제라면 대신 $FlowIgnore
사용하세요. 댓글에 근거를 설명하고 가능하다면 GitHub 문제에 대한 링크를 걸어주세요.yarn flow type-at-pos ...
명령을 사용하여 코드에 적용되는 유형을 추적해 보세요. 자세한 내용은 yarn flow -- --help type-at-pos
참조하세요.우리는 Prettier를 사용하여 JavaScript 코드의 형식을 자동으로 지정하고 스타일에 대한 모든 지속적인 논쟁을 중단합니다.
코드 적용 범위 보고서를 보려면 다음을 입력하십시오.
yarn test-coverage-once
그러면 코드 적용 범위를 나타내는 파일 테이블이 인쇄됩니다. 숨겨진 행은 오른쪽 열에 표시되지만 브라우저에서 전체 보고서를 열 수 있습니다.
open coverage/lcov-report/index.html
프런트엔드와 동일한 호스트에서 API를 사용하여 AMO 앱을 실행하기 위해 프록시 서버가 제공됩니다. 이는 우리의 생산 설정을 모방합니다.
다음과 같이 호스팅된 API에 대한 개발을 시작하세요.
yarn amo:dev
그러면 API 데이터에 https://addons-dev.allizom.org
사용하도록 프록시가 구성됩니다. 이 명령은 새로운 프런트엔드 기능을 개발하는 가장 일반적인 방법입니다. 서버를 실행하는 비슷한 방법은 위의 명령 표를 참조하세요.
Docker에서 실행되는 로컬 API 서버를 사용하려면 yarn amo
명령을 사용할 수 있습니다. 그러나 현재는 작동하지 않습니다. 문제-7196을 참조하세요.
인증은 addons-frontend에서 시작될 때 작동하고 addons-server에 유지되지만 addons-server 페이지에서 로그인할 때는 작동하지 않습니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 mozilla/addons-server#4684를 참조하세요.
yarn amo
, yarn amo:dev
또는 yarn amo:stage
실행하는 동안 설정을 재정의해야 하는 경우 먼저 다음과 같은 이름의 로컬 구성 파일을 만듭니다.
touch config/local-development.js
구성을 변경합니다. 예를 들어:
module . exports = {
trackingEnabled : true ,
} ;
서버를 다시 시작하여 적용되는지 확인하세요.
구성이 적용되는 방법에 대해 자세히 알아보려면 구성 파일 로딩 순서 문서를 참조하세요.
Android 장치에서 로컬 서버에 액세스하려면 몇 가지 설정을 변경해야 합니다. 네트워크의 IP 주소 10.0.0.1
에서 로컬 컴퓨터에 액세스할 수 있다고 가정해 보겠습니다. 다음과 같이 서버를 시작할 수 있습니다.
API_HOST=http://10.0.0.1:3000
SERVER_HOST=10.0.0.1
WEBPACK_SERVER_HOST=10.0.0.1
yarn amo:dev
그러면 Android 기기에서 http://10.0.0.1:3000
의 개발 사이트에 액세스할 수 있습니다.
참고 : 현재로서는 Mozilla 계정 클라이언트가 localhost:3000
으로 리디렉션되기 때문에 이 구성으로 로그인할 수 없습니다. localhost
개발 컴퓨터를 가리키도록 장치에서 /etc/hosts
편집하여 다른 접근 방식을 시도할 수 있지만 이는 완전히 테스트되지 않았습니다.
웹팩 서버를 사용하여 로컬로 개발할 때 임의로 생성된 자산 URL은 CSP(콘텐츠 보안 정책)에 실패하고 콘솔에 오류가 발생합니다. local-development-amo.js
와 같은 로컬 구성 파일에서 CSP를 false
로 설정하여 모든 CSP 오류를 끌 수 있습니다. 예:
module . exports = {
CSP : false ,
} ;
지금 읽고 있는 문서는 Github 버전의 Markdown으로 소스 저장소 내에 있습니다. 이러한 파일을 변경할 때 끌어오기 요청을 생성하여 미리 볼 수 있으며, 더 나은 방법으로는 그립을 사용하여 변경 사항을 로컬에서 미리 볼 수 있습니다. grip
설치한 후 다음과 같이 소스 디렉터리에서 실행합니다.
grip .
localhost
URL을 열면 렌더링된 README.md
파일이 표시됩니다. 수정하면 자동으로 업데이트됩니다.
다음은 배포에 사용되는 스크립트입니다. 배포 또는 빌드와 관련된 항목을 테스트하지 않는 한 일반적으로 필요하지 않습니다.
환경 변수는 다음과 같습니다.
NODE_ENV
: 노드 환경(예: production
또는 development
NODE_CONFIG_ENV
: 로드할 구성의 이름(예: dev
, stage
, prod
스크립트 | 설명 |
---|---|
실 시작 | Express 서버를 시작합니다(env 변수 필요) |
원사 빌드 | libs(모든 앱) 빌드(env vars 필요) |
예: 앱의 프로덕션 인스턴스 빌드 및 실행:
NODE_ENV=production NODE_CONFIG_ENV=prod yarn build
NODE_ENV=production NODE_CONFIG_ENV=prod yarn start
프로덕션 모드에서 로컬로 앱을 실행하려면 로컬 프로덕션 빌드용 구성 파일을 만들어야 합니다. 프로덕션 빌드는 dev
, stage
및 prod
( NODE_CONFIG_ENV
env var에 의해 제어됨) 등 다양한 환경용으로 빌드될 수 있지만 이러한 환경을 로컬로 실행하려면 추가 구성 파일이 하나만 필요합니다.
config/local.js.dist
라는 파일의 이름을 config/local.js
로 바꿉니다. 그런 다음 위에 설명된 대로 yarn build
및 yarn start
사용하여 다시 빌드하고 다시 시작합니다. 이전에 다른 구성으로 127.0.0.1
사용한 적이 있다면 쿠키를 삭제하세요. 응용 프로그램은 http://127.0.0.1:4000/에서 사용할 수 있습니다.
참고 : 현재로서는 이 접근 방식을 사용하여 로그인할 수 없습니다.
다음과 같은 요청을 통해 배포된 addons-frontend
커밋, 실행 중인 A/B 실험 또는 활성화된 기능 플래그를 확인할 수 있습니다.
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,
"enableFeatureStaticThemes": true
},
"source": "https://github.com/mozilla/addons-frontend",
"version": ""
}
version.json
파일이 루트 디렉터리에 없으면 415 응답이 반환됩니다. 이 파일은 일반적으로 배포 프로세스에서 생성됩니다.
모니터링 스크립트와의 일관성을 위해 다음 URL에서 동일한 데이터를 검색할 수 있습니다.
curl https://addons-dev.allizom.org/__version__
이 정보를 쉽게 보려면 amo-info 확장 프로그램을 설치하면 됩니다.
이 프로젝트에는 addons-frontend-blog-utils
라는 라이브러리를 빌드하는 코드도 포함되어 있으며 다음 명령을 제공합니다.
yarn build:blog-utils-dev
: 라이브러리를 빌드하고, 감시자를 시작하여 변경 시 라이브러리를 다시 빌드하고 http://127.0.0.1:11000에 개발 페이지를 제공합니다.yarn build:blog-utils-prod
: 프로덕션 모드에서 라이브러리 빌드이 라이브러리는 addons-blog와 함께 작동하도록 독점적으로 설계되었습니다.
addons-frontend-blog-utils
의 새 버전을 게시하려면 특수 태그를 기본 저장소에 푸시해야 합니다. 태그 이름은 blog-utils-
로 시작해야 하며 일반적으로 버전 번호를 포함합니다. 이는 다음 명령을 사용하여 자동화할 수 있습니다.
npm version [major|minor|patch]
master
브랜치에서 이 명령을 실행하면 package.json
의 버전이 업데이트되고 커밋이 생성되며 태그가 생성됩니다. 이 커밋과 태그를 모두 기본 저장소에 푸시합니다.
참고: 새로운 addons-frontend-blog-utils
릴리스가 addons-blog에 병합되면 WordPress 테마의 새 버전을 게시해야 합니다. addons-blog 저장소에서 다음 지침을 따르세요.