현재 백엔드 형은 세 대의 서버를 설정했다. 각각 정식 서버, 테스트 서버와 개발 디버깅 서버이다. 현재 이 세 대의 서버에는 모두 자동 배치가 설정되어 있다. 자동 배치의 원리는 우리가 해당 지점git를 제출할 때 서버가 이 새로운 제출을 끌어와 스크립트를 터치하는 것이다.스크립트의 명령은 우리가 서버와 약속한 패키지 명령(npmrunbuild,npmrunbuildDev,npmrunbuildTest)입니다. 그 목적은git를 제출하고 세 대의 서버가 각각 세 세트의 서로 다른 인터페이스의 전단 패키지를 만들 수 있도록 하는 것입니다.
정식 서버 대응 공식 환경 master Spoke(아직 배포되지 않음)
테스트 서버 대응test spoke
개발 서버 대응 개발자 지점
앞부분
？
우리는 이전에 개발할 때 수동으로 인터페이스를 개발된 인터페이스로 전환해야 했고, 정식 서버를 포장할 때 정식 서버의 인터페이스로 전환해야 했다.조작의 전환이 어느 정도 되지 않는다고 생각하면 전환을 잊어버리는 동시에 빈번한 전환도 매우 번거롭다. 비록 네 개의 인터페이스 주소(업무 인터페이스, 사용자 중심 인터페이스, 지도 에이전트, 지도 키)만.이제 설정이 끝난 후에 우리 앞부분은 인터페이스 전환에 더 이상 관심을 가질 필요가 없습니다. 개발할 때 npmrundev를 실행하고 정식 서버를 포장하여 npmrunbuild를 실행하면 됩니다. 배치할 때 더 이상 어떤 인터페이스 수정도 필요하지 않습니다.
전단 실현 방법
목표: 세 개의 서로 다른 인터페이스 주소를 포장할 수 있는 세 가지 명령을 설정하여 백엔드 형에게 자동 배치로 실행되는 명령을 제공해야 한다.
웹팩은 npmrun 명령을 어떻게 설정하는지: 패키지에서.json의 scripts 블록에서build 명령을 참고하여buildDev,buildTest 명령을 복사하고 수정합니다. 이 두 명령은 각각build 폴더 아래의buildDev를 가리킵니다.js 파일 및 buildTest.js 파일.왜 그랬을까?이 두 파일을 가리키는 이유는 우리가 다시 포장해야 할 때, 웹 팩이 config 폴더 아래의 어떤 인터페이스 프로필을 포장해야 하는지 알기 때문이다.이 중의 관건은build에 있다.js 파일의process.env.NODE_ENV라는 매개 변수에 값을 부여합니다. 이 매개 변수는 현재 실행 환경의 이름과 같습니다. 이 이름이 있으면 우리는 모든 프로젝트 파일에서 서로 다른 환경에 대해 서로 다른 조작을 할 수 있습니다. 예를 들어 우리가 axios를 봉인해야 한다고 가정하고 만약에 우리가 크로스 에이전트를 설정한다면 정식 서버를 배치하고 개발할 때 어떤 설정의 수정도 원하지 않는다면우리는 이 명령으로 인터페이스에 프록시 접두사를 추가할지 여부를 미리 구분할 수 있습니다. 이것은 게으른 프로그램 원숭이에게 매우 의미가 있습니다. 왜냐하면 tmd는 매번 정식 서버를 배치할 때마다 엉망진창인 설정을 바꿔야 하기 때문입니다!!!본론으로 돌아가서 이 NODE_를 수정했습니다ENV 이후 웹팩은 어떻게 이 이름에 따라 포장된 인터페이스를 구분합니까?
웹pakc 패키지 운행 프로세스
config 폴더 아래의prod.env를 보십시오.js, 모듈을 내보낼 때 NODE_ENV 는 production 으로 명명됨
build를 보십시오.js,build.js를 포장할 때prod 환경에 대한 모든 웹 팩의 설정은 웹 팩을 도입했습니다.prod.conf 이 파일, ok, 지금 이 전설적인 파일을 열어 주십시오. 패키지를 도입한 후에 논리를 정식으로 실행하는 첫 번째 부분은 인터페이스 주소를 지정한 파일입니다. 저는 이 곳에 있습니다. 프로세스에 따라.env.NODE_ENV에 따라 인터페이스 구성 파일이 달라집니다!!!이것은 서로 다른 명령이 서로 다른 인터페이스 주소를 포장하는 목적을 실현했다.
부족하다
물론 현재의 배치는 완벽하지 않다. 그리고 개선해야 할 점이 많다.
build.js와buildDev와buildtest 파일의 대부분은 똑같습니다. 사실은 중간 js를 추가하여 이 공용 설정을 도입할 수 있습니다. 그리고 이 세 js는 세 가지 명령이 다른 곳(NODE_DEV 이름)
만 구분합니다.
webpack.prod.conf.js라는 파일은 이름에서 보면 정식 환경에서 사용하는 설정인 것을 한눈에 알 수 있지만 나는 다른 두 환경의 설정을 모두 이 파일을 가리킨다. 이렇게 하면 한눈에 규범에 맞지 않는다.
만약에 지금 환경을 하나 더 추가한다면 나는 이 조작들을 다시 한 번 설정해야 한다. 매우 번거롭다!!!
이런 부족한 사고방식을 해결하다
현재의 사고방식의 관건은 웹팩이 현재 실행 중인 명령 이름이 무엇인지 알 수 있느냐 하는 것이다.해결 시간을 물어봐야지 lz 기분 좋을 때!!!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
