>웹 프론트엔드 >JS 튜토리얼 >기본 내보내기 재작성을 위한 Codemod 도구 구축

기본 내보내기 재작성을 위한 Codemod 도구 구축

DDD
DDD원래의
2024-11-03 02:36:021013검색

Building a Codemod Tool for Rewriting Default Exports

최근 직장에서 명명된 내보내기/가져오기로 마이그레이션하고 eslint 규칙 no-default-export를 추가하기로 결정했습니다.

동기 부여는 다음과 같이 들렸습니다.

기본 내보내기를 사용하면 특히 대규모 코드베이스에서 코드를 유지 관리하기가 더 어려워질 수 있습니다. 가져온 이름은 동일한 엔터티에 대해 다를 수 있으며, 이는 코드 읽기 프로세스 및 정적 분석기 작성에 영향을 미쳐 더 어려워집니다. 반대로 명명된 내보내기로 전환하면 기본 내보내기의 모든 단점이 제거됩니다.

물론, 우리는 거대한 코드 기반을 가지고 있으며 ~1500개의 기본 내보내기와 ~12000개의 기본 가져오기를 수동으로 교체하는 것은 흥미로운 작업이 아닙니다.

가장 어려운 점은 명명된 내보내기를 위해 생성된 동일한 새 식별자로 연결된 모든 파일을 업데이트하는 것이었습니다.

예를 들어 보겠습니다.

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

제가 가정한 목표 결과는 다음과 같습니다.

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

인터넷에서 찾은 각 솔루션은 해당 파일 외부의 다른 내용을 알지 못한 채 각 파일을 독립적으로 변환하는 codemod에 불과했습니다.

저는 다음과 같은 파서에 대한 꿈을 꾸기 시작했습니다.

  1. 프로젝트의 모든 가져오기를 해결하고 파일 간의 관계를 저장합니다
  2. 기본 가져오기/내보내기에 대한 정보 수집
  3. 이름이 지정된 내보내기에 대한 새 식별자 이름을 생성합니다
  4. 저장소 전체의 모든 항목을 바꾸시겠습니까?

그래서 저는 기본 내보내기/가져오기를 이름이 지정된 항목으로 자동으로 다시 작성하는 codemod 도구를 개발하는 새로운 도전에 나섰습니다.

스포일러

이미 개발했어요! ? ?

개발 과정

첫번째 생각
이전 실험 시각화 반응 구성 요소 트리 직후에 발생했으며 첫 번째 아이디어는 babel 및 webpack 플러그인을 재사용하여 모든 모듈을 반복하고 AST를 구문 분석하는 것이었지만 jscodeshift에 이미 구문 분석기가 있고 대체 항목을 찾았다면 왜 그런 일이 발생했습니까? webpack 플러그인을 사용하면 번들러에 구애받지 않는 도구를 작성할 수 있습니다. 좋습니다.

도구
좋아요, 파서로 jscodeshift가 있습니다. 그러나 진입점에서 시작하는 모든 파일 간의 관계를 찾기 위해 네이티브 nodejs require.resolve와 같은 경로를 해결하는 데 도움이 되는 해결 패키지를 찾았지만 번들러와 같은 경로를 해결하는 것과 더 유사하며 확장, 동기화를 더 많이 제어할 수 있습니다. /async 동작 등

2단계 프로세스 엔지니어링
내 도구의 초기 버전은 하나의 스크립트에 있는 모든 것과 같았습니다. 그러나 유연성과 성능을 향상시키고 디버깅을 통해 개발 프로세스를 단순화하기 위해 도구를 두 단계로 리팩터링했습니다.

  1. 데이터 수집: 첫 번째 단계에서는 코드베이스 전반에 걸쳐 기본 가져오기 및 내보내기의 모든 인스턴스를 수집합니다

    • 이 단계를 제어하기 위해 환경 변수 IS_GATHER_INFO를 도입했습니다. 스크립트는 해결을 사용하여 기본 내보내기/가져오기의 모든 사용법을 찾습니다
    • 또 다른 env var ENTRY에는 코드 베이스 진입점에 대한 상대 경로가 포함되어 있으며, 해당 파일부터 시작하여 모든 가져오기가 해결되고 분석됩니다.
  2. 변환: 데이터가 수집되면 두 번째 단계에서는 기본 내보내기를 명명된 내보내기로 다시 작성합니다. jscodeshift를 사용하여 소스코드를 병렬로 쉽게 변환했습니다.

    • 이 단계를 제어하기 위해 환경 변수 IS_TRANSFORM을 도입했습니다

다음 두 단계로 나뉩니다.

  • 데이터 수집과 변환을 분리하여 개발 및 디버깅 중에 실행되는 코드의 양과 소요되는 시간을 줄일 수 있었습니다.
    • gatherInfo 함수의 결과를 보고, 분석하고, 코드를 다시 실행하는 매우 편리한 방법입니다
    • 데이터 수집으로 전체 파이프라인을 반복적으로 실행하지 않고 변환 테스트
  • 데이터 덤프를 수집하는 것은 다양한 진입점에 대해 이 도구를 실행해야 하지만 수집된 데이터를 재사용해야 하는 경우에 유용합니다

사례가 축적되기 시작하면서(예: 동적 가져오기, 다시 내보낸 기본값, 내보낸 다른 엔터티: 변수, 함수 및 클래스, 이미 사용된 변수 문제의 이름) 그 시간에 테스트 사례를 설정하는 데 추가 시간을 보냈습니다. 약 30분 만에 견고한 테스트 설정이 완료되어 테스트 중심 개발(TDD)으로 전환할 수 있었습니다. 저를 믿으세요. 사례 수가 엄청나게 많은 도구를 위해 TDD에 시간을 투자할 가치가 있습니다. 더 나아가면 테스트 사례에서 더 많은 가치를 느낄 수 있습니다. 테스트 없이 사례의 절반을 처리한 후에는 변경 사항을 추가해야 할 때마다 다른 많은 사례가 중단될 수 있기 때문에 거대한 프로젝트에서 실행하고 디버깅하는 것이 악몽이 된다고 말하고 싶습니다.

AST:
저는 다음 유형의 AST 노드를 사용했습니다:

  • import default 문만 찾는 ImportDefaultSpecifier
    • '...'에서 항목 가져오기
  • 내보내기 기본 문만 찾는 내보내기DefaultDeclaration
    • 기본 항목 내보내기
  • import default 및 import default 문을 찾는 ImportNamedDeclaration
    • '...'에서 { 기본값으로 } 내보내기 - 기본 내보내기
    • '...'에서 { 기본값을 무언가로 } 내보내기 - 기본 가져오기
    • 내보내기 { 기본 } from '...' - 기본 가져오기와 기본 내보내기를 동시에
  • ImportExpression을 사용하여 동적 가져오기를 찾고 해당 파일을 필요에 따라 표시하여 기본 내보내기를 유지합니다. React.lazy와 같은 일부 도구는 기본 내보내기로만 작동합니다.
    • 가져오기('...')
  • 또한 프록시 파일에 대한 정보를 저장했는데 기본 항목을 가져오고 해당 항목을 기본값으로 내보내는 파일입니다.
    • 모든 파일에서 명명된 내보내기의 새 이름을 찾는 데 사용되었습니다. file a -> 파일 b -> C 파일

기술적 고려 사항 및 알려진 제한 사항
이 도구는 기능적이지만 아직 처리하지 못하는 몇 가지 극단적인 경우가 있습니다.

namespace.default 사용법
다음 코드는 아직 변환되지 않습니다.

// Button/Button.tsx
const Button = () => {};
export default Button;

// Button/index.ts
export { default } from './Button.tsx';

// SomePage1.tsx
import OldButton from './component/Button';

// SomePage2.tsx
import TestButton from './component/Button';

프록시 파일 충돌
출처:

// Button/Button.tsx
export const Button = () => {};

// Button/index.ts
export { Button } from './Button.tsx';

// SomePage1.tsx
import { Button as OldButton } from './component/Button';

// SomePage2.tsx
import { Button as TestButton } from './component/Button';

결과:

import * as allConst from './const';
console.log(allConst.default);

다음과 같은 엉망인 내보내기
출처:

export { Modals as default } from './Modals';
export { Modals } from './Modals';

이제 구현이 다른 두 개의 동일한 내보내기가 있으므로 논리가 손상됩니다.

export { Modals } from './Modals';
export { Modals } from './Modals';

그리고 이전 엔터티에 대한 가져오기도 수동으로 수정해야 합니다
출처:

export class GhostDataProvider {}
export default hoc()(GhostDataProvider);

결과:

export class GhostDataProvider {}
const GhostDataProviderAlias = hoc()(GhostDataProvider);
export { GhostDataProviderAlias as GhostDataProvider };

이러한 제한에도 불구하고 저는 15~20분 만에 나머지 오류를 수동으로 수정하고 실제 프로젝트를 성공적으로 시작했습니다. 다시 쓰기 기본 내보내기입니다.

모래밭

  • jscodeshift
  • 아스트 익스플로러

그렇습니다. 아래 댓글에 오신 것을 환영합니다! ?

위 내용은 기본 내보내기 재작성을 위한 Codemod 도구 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.