사진 작성자Luca Bravo가 Unsplash
주: 비밀 협정 때문에 우리는 고객의 이름을 언급하지 않을 것입니다.
우리는 작년에 Angular CLI에서 Nx로의 마이그레이션을 마쳤는데, 이것은 우리가 한 가장 큰 재편 중의 하나이다.이 글은 우리가 왜 이렇게 하기로 결정했는지, 그리고 우리가 무엇을 했는지 소개할 것이다.

우리의 도전

코드 공유: 우리는 응용 프로그램 간에 코드를 공유한다.우리는 대부분의 리셋 가능한 코드를 응용 프로그램의 일부분으로 하고, 주요 응용 프로그램의 일부분으로 리셋 가능한 코드를 계속 추가할 것이다.

재구성: 앞에서 언급한 성능 최적화를 시작했습니다.기존 상태에서 코드 라이브러리를 재구성하는 것은 도전이다.코드의 어느 부분을 터치해야 하는지 확인하는 것은 도전이다.아니면 어디에 새로운 기능을 추가할지.

구축 시간: 우리의 구축 시간이 매우 길다.우리는 매번 PR/MR을 발표한 후에 매우 긴 시간을 기다려야 한다. 더 많은 구축 시간은 작업에 더 많은 시간을 머무르게 하고, 발표 주기마다 발표에 대한 변경이 더 적다는 것을 의미한다.

새로운 기능 추가: 이미 너무 큰 응용 프로그램에 새로운 기능을 추가하는 것은 매우 도전적이다.

코드 심사: 모든 코드 라이브러리를 가지고 있기 때문에 하나의 응용 프로그램으로 코드 소유자를 추가하기 어렵다.

이상의 통증은 NxDevTools가 우리의 최선의 선택이라는 것을 깨닫게 하고 우리는 계속 이렇게 해야 한다는 것을 깨닫게 한다.

우리 왜 이러는지

Angular CLI에서 Nx로 마이그레이션하는 것은 중요한 결정입니다.Nx로 마이그레이션하기 전에 Angular CLI를 사용하여 기본 애플리케이션에 프로젝트를 만들고 동일한 작업공간에 작은 독립 실행형 애플리케이션을 만들었습니다.그것은 마치 하나의 코드 라이브러리에 있는 거대한 코드 블록과 같아서, 우리는 이전할 때 많은 도전에 부딪혔다. 만약 우리가 Nx로 이전하지 않았다면 더욱 그렇다.
내가 팀에 가입했을 때 응용 프로그램의 성능 문제를 해결하기로 결정했기 때문에 우리는 곧 대량의 코드 재구성을 진행할 것이다.

Nx 소개

Nx는 모노 리콜 관리를 위한 개발 도구다.사용mono-repos 의 장점은 한 작업공간에서 여러 개의 응용 프로그램을 만들고 관리하며/share 라이브러리를 유지보수할 수 있다는 것입니다.
Nx가 한 것은 단일 환매만이 아니다.생성기와 구축기/실행기 (사용자 정의 명령) 를 작성하기 위해 devkit에 접근할 수 있습니다.
Nx는 또한 구축에 캐시를 제공하기 때문에 구축을 실행할 때마다 변경되지 않은 코드를 컴파일할 필요가 없습니다.만약 당신이 CI 파이프라인에서 캐시 우위를 얻고 싶다면, Nx Cloud는 아주 좋은 제품입니다.

우리가 시작하기 전의 걱정

이전을 시작하기 전에 프로그램에서 이동하고 라이브러리로 만들어야 할 코드 부분을 확인해야 합니다.
우리는 다음과 같은 조치를 취하기로 결정했다.

모든 것을 깨뜨리는 것은 우리가 하고 싶은 것이 아니다.첫 번째 교체에서common/legacy라는 큰 폴더만 이동하기로 결정했습니다. 다시 사용할 수 있는 코드 라이브러리를 가지고 새 라이브러리를 만듭니다.

우리가 이 큰 유류 폴더를 다른 라이브러리로 옮겼을 때 우리는 또 다른 문제에 부딪혔다.최종적으로 남겨진 코드를 이동하는 계획은 올바른 선택이다.문제는 빔의 크기가 증가하고 지수가 증가했다는 것이다.우리는 계속 이렇게 할 수 없다.

우리는 다시 화판으로 돌아왔고, 우리는 모여서 토론하기로 결정했다.
다음과 같은 옵션이 있습니다.

나는 과거에 부차적인 입구점을 사용한 적이 있다.나의 건의는 두 번째 입구점을 선택하는 것이다.

이것은 가장 좋은 생각으로 들린다. 대부분의 경우 나는 이 옵션을 선택할 것이다.

문제는 우리가 라이브러리로 대량의 코드를 옮겨야 한다는 것이다.

만약에 우리가 이 옵션을 선택한다면 방대한 코드 라이브러리를 고려하면 우리는 1년이 넘게 걸릴 것이다. 왜냐하면 우리는 세 명의 팀이 있는데 나만 전업으로 이 옵션을 하기 때문이다.

솔루션 1의 복잡성을 고려하여 우리는 다른 해결 방안을 채택하기로 결정했다

다음과 같이 tsconfig.base.json에서 와일드카드 경로를 사용하기로 결정했습니다."@domain/common-legacy/*": ["libs/common/legacy/src/lib/*"]

이것은 좋은 생각입니다. 왜냐하면 우리는 우리가 필요로 하는 물건만 수입하기 때문입니다.

하지만 자신만의 도전도 있다

솔루션에 대해 아는 것이 거의 없음

전체 마이그레이션 프로세스를 세 부분으로 나누기로 했습니다.

공통점/유산을 이전하여 우리가 직면한 문제를 해결한다.

첫 번째 단계에서 나머지 코드를 이동합니다.

순환 의존 관계를 처리한다.

초기 솔루션의 일부로 사용되는 솔루션

우리는 2차 입구점을 만들 필요가 없고 더 적은 작업만 할 수 있다.각각component/module/service/ 등에 대한 폴더를 설정하여

import { HomeModule } from '@domain-common-legacy/home.module'

우리는 전체lib를 패키지의 일부분으로 삼지 않았다.우리는 우리가 필요로 하는 코드만 얻을 수 있다.번들 예산을 통제하다.새 코드를 이동할 때 경로를 정확하게 설정해야 합니다.

그러나 창설된 라이브러리는 구축할 수 없다는 문제를 가져왔다.그러나 우리는 창고 구축이 이전 과정의 첫 번째 부분이 아니기 때문에 계속 전진하기로 결정했다.

순환 의존항 검사를 사용하지 않기로 결정했습니다.

최종 솔루션

최초의 해결 방안이 어떻게 작동하는지 알게 되면, 코드 라이브러리를 훑어보고, 우리가 가지고 있는 모든 특성을 확인하고,lib로 나누기로 결정합니다.
세 가지 섹션을 포함하여 대부분의 기능을 파악했습니다.

기능/공통: 기능 및 기타 기능에 사용되는 공통 구성 요소/명령어.

핵심: 우리는 방대한 비대화 응용 프로그램을 얻지 못하도록 우리의 기능을 게으르게 불러온다.핵심libs는 구성 요소/서비스/지령/모듈로 구성되어 있으며, 이러한 구성 요소/서비스/지령/모듈은 로드 지연 특성의 일부로 외부에서 공유되지 않습니다.

상태: 모든 기능은 하나의 상태를 가진다. 우리는 NgRx를 사용하여 전역 상태를 표시하고 RX는 로컬 상태를 처리하며 상태 라이브러리에 기능을 저장하는 NgRx 코드를 표시하며 때로는 다른 기능과 공유한다.

공유 코드가 코어라는 폴더의 일부가 되기로 했기 때문에

핵심/명령

코어/공유 구성 요소

코어/상태

코어/모델

그 밖에 이 라이브러리들은 라이브러리에서 사용할 수도 있고 조직 내의 여러 응용 프로그램에서 사용할 수도 있다.

라이브러리를 만들면요.

내가 언급한 바와 같이 LIB를 만드는 것은 전체 이동의 일부분일 뿐이다.이 연습에서는 주 번들로 대량의 상태 관리/NgRx 코드를 계산했습니다.
우리는 그것들을 분리해서 우리가 필요로 하는 상태를 주 코드의 일부분으로만 불러와서 이 문제를 병행 처리하기로 결정했다.
우리는 메인 패키지의 약 2.9MB에서 시작해서 evergreen 브라우저의 구축 중인 2.30MB까지 갔다.

루프 종속 처리

라이브러리를 만든 후에 우리는 최종적으로 180여 개의 라이브러리를 얻었다. 이것은 한 응용 프로그램에서 시작된 것이다.
지금은 순환 의존성 문제를 처리할 때다.한 번의 성공은 불가능하다.
따라서 우리는 핵심 라이브러리부터 시작하고 순환 의존성 문제를 담당하는 대형 코드 라이브러리는 핵심 라이브러리의 일부이며 주로 인터페이스/서비스와 상태임을 발견하기로 했다.
비록 우리가 저지른 오류를 복구하고 있지만, 우리는 순환 의존성 검사를 금지해 왔다.
새 코드에 대한 검사를 사용할 수 있음을 깨달았습니다. 루트 eslint config를 추가해서 전체 리포에 대한 검사를 사용하고 순환 의존성을 가진lib를 모두 비활성화합니다.이런 방식을 통해 현재 새로운 라이브러리는 순환 의존 문제가 없는 상황에서만 합병할 수 있다.
라이브러리에 순환 의존성 검사를 사용하기로 결정했습니다. 왜냐하면 라이브러리를 복구하고 있기 때문입니다.
순환 의존 복구는 더 많은 라이브러리를 만들어야 합니다. 마지막으로 250개가 넘는 라이브러리를 얻었습니다.

도서관을 건설하다

앞에서 언급한 바와 같이, 이런 방법의 하나는 우리가 이 라이브러리를 구축할 수 없다는 것이다.
우리 동료들은 이 일을 직접 처리하기로 결정했고, 최종적으로 구축기를 만들어서 이런 방법으로 만든 모든 새 라이브러리를 구축했다.
Matt는 라이브러리 생성기도 작성했기 때문에 같은 구조로 모든 라이브러리를 만듭니다. 그러면 전체 라이브러리를 패키지의 일부분으로 사용하지 않습니다.

우리가 이룩한 성과

이번 이주 후에 우리는
코드 소유자: 코드 소유자 파일을 만들고 코드 심사의 책임과 코드의 특정 부분을 어느 그룹에 귀속시키기로 결정했습니다.

맞춤형 eslint 규칙: 우리의 절차의 일부로서 우리는 코드 심사 절차에 대해 몇 가지 검사를 실시했다.Nx로 이전하면 이 모든 검사를 사용자 정의 eslint 규칙으로 전환할 수 있어 더 많은 시간을 절약할 수 있습니다.

코드를 재구성하기 쉽다. 우리는 매주 대량의 코드를 복원/첨가한다. 이런 라이브러리를 가지고 있으면 우리의 생활이 더욱 수월해진다. 왜냐하면 지금은 수정해야 할 코드 부분을 쉽게 찾을 수 있기 때문이다.

결론

NX로의 마이그레이션 선택은 기능을 인식하고 라이브러리로 마이그레이션할 수 있는 효과적인 방법으로, 소규모 PRs의 이점을 제공합니다.그 밖에 우리는 사용되지 않고 중복된 코드도 식별할 수 있다.
사용자 정의 규칙과 코드 소유자를 추가하는 것은 우리에게 큰 도움이 된다.우리는 검사가 필요한 코드를 식별할 수 있다.
Nx로 이전한 경험과 그것이 어떻게 도움이 되는지 트위터에 공유해 주세요.
당신은 Nx 커뮤니티에 가입할 수 있습니다: https://go.nrwl.io/join-slack
그에게 귀중한 시간을 주어 이 문장을 읽어 주셔서 특히 감사합니다.사랑과 너의 일 주리.💙