최근 직장에서 명명된 내보내기/가져오기로 마이그레이션하고 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에 불과했습니다.
저는 다음과 같은 파서에 대한 꿈을 꾸기 시작했습니다.
그래서 저는 기본 내보내기/가져오기를 이름이 지정된 항목으로 자동으로 다시 작성하는 codemod 도구를 개발하는 새로운 도전에 나섰습니다.
이미 개발했어요! ? ? 스포일러
첫번째 생각
이전 실험 시각화 반응 구성 요소 트리 직후에 발생했으며 첫 번째 아이디어는 babel 및 webpack 플러그인을 재사용하여 모든 모듈을 반복하고 AST를 구문 분석하는 것이었지만 jscodeshift에 이미 구문 분석기가 있고 대체 항목을 찾았다면 왜 그런 일이 발생했습니까? webpack 플러그인을 사용하면 번들러에 구애받지 않는 도구를 작성할 수 있습니다. 좋습니다.
도구
좋아요, 파서로 jscodeshift가 있습니다. 그러나 진입점에서 시작하는 모든 파일 간의 관계를 찾기 위해 네이티브 nodejs require.resolve와 같은 경로를 해결하는 데 도움이 되는 해결 패키지를 찾았지만 번들러와 같은 경로를 해결하는 것과 더 유사하며 확장, 동기화를 더 많이 제어할 수 있습니다. /async 동작 등
2단계 프로세스 엔지니어링
내 도구의 초기 버전은 하나의 스크립트에 있는 모든 것과 같았습니다. 그러나 유연성과 성능을 향상시키고 디버깅을 통해 개발 프로세스를 단순화하기 위해 도구를 두 단계로 리팩터링했습니다.
데이터 수집: 첫 번째 단계에서는 코드베이스 전반에 걸쳐 기본 가져오기 및 내보내기의 모든 인스턴스를 수집합니다
변환: 데이터가 수집되면 두 번째 단계에서는 기본 내보내기를 명명된 내보내기로 다시 작성합니다. jscodeshift를 사용하여 소스코드를 병렬로 쉽게 변환했습니다.
다음 두 단계로 나뉩니다.
사례가 축적되기 시작하면서(예: 동적 가져오기, 다시 내보낸 기본값, 내보낸 다른 엔터티: 변수, 함수 및 클래스, 이미 사용된 변수 문제의 이름) 그 시간에 테스트 사례를 설정하는 데 추가 시간을 보냈습니다. 약 30분 만에 견고한 테스트 설정이 완료되어 테스트 중심 개발(TDD)으로 전환할 수 있었습니다. 저를 믿으세요. 사례 수가 엄청나게 많은 도구를 위해 TDD에 시간을 투자할 가치가 있습니다. 더 나아가면 테스트 사례에서 더 많은 가치를 느낄 수 있습니다. 테스트 없이 사례의 절반을 처리한 후에는 변경 사항을 추가해야 할 때마다 다른 많은 사례가 중단될 수 있기 때문에 거대한 프로젝트에서 실행하고 디버깅하는 것이 악몽이 된다고 말하고 싶습니다.
AST:
저는 다음 유형의 AST 노드를 사용했습니다:
기술적 고려 사항 및 알려진 제한 사항
이 도구는 기능적이지만 아직 처리하지 못하는 몇 가지 극단적인 경우가 있습니다.
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분 만에 나머지 오류를 수동으로 수정하고 실제 프로젝트를 성공적으로 시작했습니다. 다시 쓰기 기본 내보내기입니다.
그렇습니다. 아래 댓글에 오신 것을 환영합니다! ?
위 내용은 기본 내보내기 재작성을 위한 Codemod 도구 구축의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
