~~env-cmd 패키지를 다운받고, .env-cmdrc 파일을 만들어서 각 4가지 환경에 따른 디폴트 value(공개 환경변수)를 세팅해준다. 이 때, 이 파일은 .gitignore에 추가하지 않아야 한다. (시크릿 값이 아니니까)~~.env.development , .env.staging , .env.production 을 만들어서 그곳에 넣는다. 왜 .env-cmdrc 에 넣지 않고 기존 방식을 사용하는가? 하면 그 이유는 CI/CD 파이프라인 구축과 관련이 있다. CI를 위한 workflow 제작시에는, CI 서비스에 저장해둔 시크릿을 가져와서 echo로 .env 파일을 한줄한줄 추가하는 방식으로 제작해야 한다. 쉘 작업에 간편하고 유리하다. 만약 cmdrc 파일을 쓰려 한다면? step에서 JSON 을 만드는것 자체가 에너지 낭비.. 뭐 나름대로 시크릿이 이쁘게 잘 분리되는것 같으니 좋은 방식인것 같다..env.test 파일은 없는가? 그것은 test 에서 시크릿값을 쓰지 않겠다는 나의 강한 의지. API 호출하지 말고 DB 연결 절대 하지 말고 값이 공개될 수 있는 .env-cmdrc 선에서 모두 해결하자.⇒ env-cmd -e staging -f .env.staging react-scripts build 와 같이 env-cmd의 -e, -f 옵션을 동시에 사용하는게 안돼서 포기.. 나중에 오픈소스 Contribution 해보면 괜찮을듯??
.env 파일을 만들고 gitignore 하지 않으며, 템플릿의 역할을 하여 향후 배포환경별 파생될 필드명, 값들을 미리 정의해준다..env 파일을 바탕으로 .env.development , .env.staging , .env.production 세가지 파일을 만들고 gitignore 하고, .env.test 도 만들고 얘는 gitignore 하지 않는다. 왜냐면 test 환경에서는 시크릿 값이 필요없다. 애초에 필요한 테스트는 좋은 테스트의 조건도 아니고, 그냥 노출해도 될 뿐더러 CI 파이프라인시에 파일 작성할 필요가 줄어들게 된다.staging 을 cra에서 대응해주지 않으므로.. .local 파일은 포기해야 한다. 딱 저 파일들로 설정 덮어쓸 수 있도록. 이것마저 안되면 그때는, 라이브러리를 덮어쓰던가 eject 를 해야한다.
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"build:staging": "env-cmd -f .env.staging npm run build",
"test": "react-scripts test",
"eject": "react-scripts eject"
}