Next.js에서 .env는 빌드 타이밍 때 하드코딩되어서 들어간다.

하지만 간혹 빌드 타이밍이 아닌, 빌드 된 이미지를 돌릴 때, env를 세팅하고자하는 많은 니즈들이 존재한다.

보통은 local, dev, qa, prod 이렇게 다루기 때문이다.

그렇다면 우린 그걸 어떻게 해낼 수 있을까?

대부분의 맥락은 아래의 글과 대동소이하다.

그러나, 위 글은 윈도우를 배척한다.

package.json의 스크립트에 유닉스 문법을 박아놓는걸로 알 수 있다.

{"start": "node ./utils/cli.js next-env -e ${APP_ENV:-dev} && next start"}

더러운 유닉스를 사용하지않는 청렴결백하며, 깔끔하고 배려심이 넘치는 윈도우 유저는 위 스크립트를 사용 못한다는 의미다.

그러므로 깔끔하고 배려 넘치는 윈도우 유저는 유닉스 유저를 배려하여 두 os 위에서 멀쩡하게 돌아가는 스크립트를 대신 넣어줘야한다.

해결방법은 간단하다.

해당 문법과 같은 일을 하는 스크립트를 박으면 된다.

npm i --save-dev cross-env

위와 같은 커맨드로 cross-env를 설치해준다.

그리고 위에서 언급했던 start 커맨드를 아래와 같이 수정하면 해결이다.

{"start": "cross-env-shell node ./utils/cli.js next-env -e $APP_ENV && next start"}

하지만 스크립트가 과도하게 길어서 보기 힘들뿐만아니라, dev 커맨드에도 붙여줘야한다.

{
    "dev": "npm run _env:-local && next dev",
    "dev:dev": "npm run _env:dev && next dev",
    "start": "npm run _env:-local && next start",
    "_env:-local": "cross-env-shell node ./utils/cli.js next-env -e $APP_ENV",
    "_env:dev": "node ./utils/cli.js next-env -e dev"
}

따라서 필자는 위와 같이 정리했다.