Jest: [버그] 별도의 디렉토리에서 발견 된 중복 수동 모의

+1

제 경우에는 cacheDirectory / var / folders / dm / vt920lmd6tzdq_709zkykwx40000gn / T / jest를 지우고 npm 종속성을 다시 설치하면 이러한 메시지가 사라졌습니다.

다음은 문제가되는 코드입니다.

https://github.com/facebook/jest/blob/cd8976ec50dbed79cfe07f275052cdd80d466e73/packages/jest-haste-map/src/index.js#L98

그러나 그것을 확인하는 테스트가 있기 때문에 동작이 명시 적으로 원할 수 있습니다.

https://github.com/facebook/jest/blob/8de90b320c87a0a36d68f6bd8177620a985df269/packages/jest-haste-map/src/__tests__/__snapshots__/index-test.js.snap#L15

추가 된 항목 :

https://github.com/facebook/jest/commit/cfade282fbbe2737b6dd2cee1cf3da3ee8624512

전체 경로가 아닌 basename 키로 사용하는 이유가 궁금합니다.

/ cc @flarnie

즉, 수동 모의를 사용할 때 모듈에 대한 basename 는 프로젝트에서 전역 적으로 고유해야합니다. 내 사용 사례의 경우 다음과 같은 작업을 할 수 없음을 의미합니다.

import { MyWhatever } from 'models/MyWhatever/schema';
import { MyOtherWhatever } from 'models/MyOtherWhatever/schema';

동시에 수동 모의를 사용합니다. Jest는 현재 둘 다 schema 를 조롱하고 불평하는 것으로보고 있습니다.

해결 방법은 사소한 것 (s / schema / MyWhateverSchema /)이지만 테스트가 아닌 코드의 이름을 바꾸고 재구성하여 농담을 즐겁게하는 버그처럼 느껴집니다 .🐞.

예, 이것은 정말 짜증납니다. 수동 조롱 시스템은 정말 좋지 않으며 상황을 개선 할 수있는 PR을 받아 들여서 기쁩니다. 우리가 모든 FB를 깨지 않도록 할 수 있다고 가정합니다.

멋있는. 내일 패치를 요리 할 시간이 있을지 모르지만 약속은 없지만 😅

@cpojer 이 동작에 대한 특별한 이유가 있습니까?

fb가 모듈에 고유 한 파일 이름을 사용한다는 사실과 관련이 있습니까? 같은 이름을 가진 두 개의 모의를 허용하지 않는 것이 어떻게 말이되는지 잘 모르겠습니다.

예, mock도 "글로벌"입니다. 이것은 불행히도 우리가 함께 살아야하는 끔찍한 디자인입니다. FB에는 잘못된 위치에 4000 개 이상의 모의 파일이 있습니다 (그리고 종종 적절한 위치도 없습니다). 내년 초반에이 문제를 해결할 가능성이 높으므로 Jest에서 개선 될 것입니다. 오픈 소스 용 Jest의 동작을 개선하는 PR을 지원하게되어 기쁩니다. 현재 FB에서 Jest의 이전 동작을 유지할 수 있다면 기쁩니다.

@cpojer 깃발은 어때? 플래그로 이것을 활성화 / 비활성화하는 홍보를 수락 하시겠습니까?

예, 구성 옵션이어야합니다. 그러나 저는 경고에 대해서만 말하는 것이 아니라 일반적인 기능에 대해서도 이야기하고 있습니다.

@cpojer 오른쪽-농담의 어느 부분이이 부분을 만지나요?

해결 코드는 jest-runtime : https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/index.js 에서 호출되며 jest-resolve 및 jest-resolve-dependencies 어딘가에 있습니다. .

@cpojer 포인터 주셔서 감사합니다 : +1 :

@cpojer 이 동작을 전환하기 위해 JEST_USE_BASENAME_FOR_CACHING 와 같은 전역 재정의는 어떻습니까?

적어도 우리는 고유하지 않은 파일 이름을 즐길 수 있으며 FB에서 어떤 것도 깨지지 않습니다.

물론 일시적인 해결책입니다.

내 말은, 이것은 /etc/profile 또는 ~/.bashrc

export JEST_USE_BASENAME_FOR_CACHING="true"

(또는 env가있는 일부 파일)
그리고

$ jest

또는 이것은 env 파일 수정없이 :

$ JEST_USE_BASENAME_FOR_CACHING="true" jest

어떻게 생각하세요? 일종의 해킹입니까, 아니면 괜찮습니까? :눈짓:

두 가지 버전의 jest ( ^15.0.0 및 ^17.0.0 )를 사용하여 새 repo 를 사용해 보았습니다. 후자는 경고를 표시하지만 테스트는 예상대로 작동합니다.

@ColCh 여기서 문제가 캐시에 있다고 생각하지 않습니다. 아마도 더 적합한 이름은 JEST_USE_BASENAME_FOR_MOCKING 있습니다.

FB 코드에 이름의 고유성에 대한 제한이있는 경우 @cpojer , 전체 경로를 모의 맵의 키로 사용하면 문제가 발생하지 않습니다.

내가 맞습니까, 아니면 보이지 않는 것이 있습니까?

내가 보는 두 가지 솔루션은 다음과 같습니다.

• 기본 이름 또는 전체 경로를 사용하는 옵션을 수용하도록 getMockName 수정
• 그 기능을 모두 제거

@cpojer 답변을 보는 것이 좋을 것입니다.

안녕하세요 여러분, 지연되어 죄송합니다. 저는 지금 많은 자료를 백업하고 있습니다.

이 시스템을 개선하는 데 필요한 Jest의 주요 변경 사항은 무엇이든하기로 결정해도 괜찮다고 생각합니다. 수동 조롱은 정말 엉망이고 잘 작동하지 않습니다. 우리가하고 싶은 한 가지는 "haste_modules": ['path/a', 'path/b']" 와 같은 구성 옵션을 사용하여 "haste modules"(내부 FB 모듈 시스템)의 범위를 제한 한 다음이 이상한 조롱을 포함하여 해당 폴더에있는 haste 모듈 만 살펴 보는 것입니다. 행동. 누구든지이 변화를 만들고 싶다면 그것은 놀랍습니다.

알아 내야 할 한 가지는 다음과 같습니다. __mocks__/a.js 가 a.js 매핑되는 것처럼 모든 수동 모의가 로컬이면 node_module 모의로 무엇을할까요? 이를 위해 몇 가지 방법이 있습니다.

• 새로운 __node_modules_mocks__ 폴더를 소개합니다.
• rootDir (프로젝트 루트)에서 표시되는 최상위 __mocks__ 폴더는 전역 폴더 역할을 할 수 있습니다.

요약하면 다음과 같습니다.

• Jest에서 수동 모의를 고치자!
• haste 모듈을 네임 스페이스하고 특정 폴더 / 정규식으로 제한합시다.
• 서둘러 작업을 수행하기 위해 특정 폴더를 화이트리스트에 추가해야하는 경우에도 현재의 조롱 동작이 FB에서 여전히 작동하는지 확인하십시오 (지금은 ["<rootDir>"] 처럼 보일 것입니다).
• 여전히 노드 모듈을 모의 할 수있는 방법을 알아 내십시오.

어떻게 생각해?

순서대로 :

• Jest에서 수동 모의를 고치자!

만세 : 미소 :: 따다 :

• haste 모듈을 네임 스페이스하고 특정 폴더 / 정규식으로 제한합시다.
• 현재의 조롱 동작이 FB에 대해 여전히 작동하는지 확인하십시오. 즉, 서두르 기 위해 특정 폴더를 화이트리스트에 추가해야하는 경우에도 마찬가지입니다 ([ ""] 지금은 우리에게)

서둘러 요구 사항을 이해하고 있는지 잘 모르겠습니다.
당신이 의미하는 것은 "이 모듈은 서둘러 모듈이다"라고 말할 수있는 가능성을주는 것입니까?
4 개의 모듈 : /path_1/a , /path_1/b , /path_2/a , /path_2/c 이고 설정은 다음과 같습니다.

"haste_modules:" ["/path_1/a", "/path_2/c"]

/path_1/a 및 /path_1/b 만 /path_1 에만 존재하도록 제한되므로 /path_2/c 는 유효하며 /path_2/a 는 오류 / 경고를 발생시킵니다.

타겟은 싱글 / 더블 * 하더라도 특정 파일과 전체 디렉토리가 될 수 있습니다.

• 여전히 노드 모듈을 모의 할 수있는 방법을 알아 내십시오.

나는 현재의 행동을 유지할 것입니다.

모의하는 모듈이 노드 모듈 (예 : fs) 인 경우 모의는 node_modules 폴더와 동일한 상위 디렉토리에 있어야합니다.

내 생각:

서둘러 모듈 :

haste_modules 이 좋다고 생각합니다. collectCoverageFrom 및 기타 옵션 : glob 배열 과 똑같이 적합합니다.
모든 src 를 _haste_ 모듈로 가지고 있고 하나의 디렉토리 만 비 헤이스트 인 경우 :

haste_modules: [
  "src",
  "!src/foo"
]

node_modules

@EnoahNetzach 누군가가

서두르지 않고 작동하려면 ... 음, 다음과 같이 설명 할 수 있다고 생각합니다.

주어진 노드 모듈 project/node_modules/react , mock은 project/__node_modules_mocks__/react.js
project/react.js 파일이있는 경우 project/__mocks__/react.js

(물론 react.js 가 예입니다. 여기에는 모든 모듈 중 어떤 파일 이름도 가능하며 npm 에서 설치할 수 있습니다)

정말로, node_modules 모듈을 조롱하는 node_modules 조롱의 경우 _ugliness_를 보상 할 수 있습니까?

node_modules 내부의 모듈을 자주 조롱하는 사람이 있습니까?

더 생각 할까

내가 알 다시피 반응 네이티브 프로젝트의 경우 application modules 를 모의 처리하고 node_modules의 모듈을 lodash ).

이것은 다음을 의미합니다.

• 각 dumb 구성 요소에 대한 수동 생성 모의 구성 요소 (dumb 구성 요소는 레이아웃 구성 요소 임)
• 모든 테스트 파일에서 jest.mock 호출의 긴 목록

__ 내가 말하고 싶은 것 __ : 일부 경로에서 모듈을 _auto mock_하는 기능이 있으면 매우 좋을 것입니다.

config에서 잘 알려진 데이터 구조 array-of-jest-globs 를 중심으로 구현할 수 있으며 모듈을 필터링 할 수 있습니다.

단계별로 설명하겠습니다.

이 구성 항목이 주어지면

"autoMockingPaths": [
  "src/components/dumb/**/*.js",
]

이 코드는 src/screens/app.js .

import _ from 'lodash';
import Button from '../../components/dumb/button.js';

// blah blah AppScreen implementation skipped

src/screens/__tests__/app-test.js 화면에 대한이 테스트 코드 :

import AppScreen from '../app.js';

describe('AppScreen', () => /* testing app screen */);

우리는 app-test.js 맥락에서이 상황에 도달했습니다.

• AppScreen 은 (는) 조롱되지 않았습니다.
• lodash 은 (는) 조롱되지 않았습니다.
• Button 에 필요한, AppScreen , 조롱되고

... automock 구성 항목으로 어떻게 재생되는지 대답 할 수 있습니다.

간단히 말하면 automock: true 는 다음과 같습니다.

"autoMockingPaths": [
  "<rootDir>"
]

자동 조롱 ... 잠깐!

automock 대한 특별한 가치를 소개 할 수 있습니까? 적어도 사람들의 구성을 깨지 않을 것입니다.

예를 들어 다음 구성 항목을 사용합니다.

automock: "app"

jest는 모든 애플리케이션 모듈을 자동으로 모의하고 node_modules 부터 모듈의 실제 버전을 남깁니다.

앱 레벨 모듈 automocking, @cpojer 에 대해 어떻게 생각

"haste_modules" 전적으로 동의합니다.

우리는 개인적으로 automocking을 많이 사용하지 않기 때문에 무엇이 더 좋은지 말할 수 없습니다. 내 추측은 "autoMockingPaths" var가 유용하고 탄력적 일 수 있다는 것입니다.
반대로 내가 찾을 수 "automock": "app" 너무 뻣뻣한 (기본적으로 농담 이미 장애인 automocking을).

__node_modules_mocks__ 는 옵션이 될 수 있습니다. 저는 희소 함이 추악함을 보상한다는 데 동의합니다 (저의 특별한 경우에는 거의 node_modules 조롱하는 일이 거의 없으며,해야 할 때 jest.mock(...) ).
유일한주의 사항은 중첩 된 node_modules 폴더 (예 : src/node_modules )가있을 때 발생하는 일이며, 중첩 된 버전 인 전역 __node_modules_mocks__ 에서 모듈을 모의해야합니까? 또는 일반적으로 __mocks__ 함께 배치됩니까?

누군가 node_modules 와 app modules 같은 모듈 이름을 가지고 있다면 그냥 던질 수 있습니다.

예

app/express.js 를 앱 모듈로 사용 (내가 기차 게임을하고있을 수 있음)
npm에서 웹 서버로 app/node_modules/express
throw new Error("can't mock express.js file - it duplicates one from node_modules")

이 경우 __mocks__ 를 node_modules 에 사용할 수 있지만 개발자는 이러한 충돌에 대해 자체 모듈의 이름을 변경해야합니다.

아니 ... 이건 __node_modules_mocks__ 보다 더 못 생겼지?

내가 의미하는 바는 : npm install ed 모듈 x 이상이있는 경우 코드베이스의 더 깊은 곳에서 중첩 된 node_modules 폴더에 x 모듈을 정의합니다. ?

명명 충돌은 일반적으로 가장 가까운 노드를 선호하여 노드에서 처리되지만 이것이 어떻게 서둘러 작동하는지 모르겠습니다.

Create React App 과 같은 프로젝트에서 사용 중이거나 가까운 장래에 할 예정이기 때문에이 문제를 제기했습니다.

참고로 @cpojer 는이 문제 와 관련이 있습니까?

서둘러 작동 방식을 변경하는 데 중점을 두도록하겠습니다 (기본 설정이 아닌 화이트리스트 / 블랙리스트). 나는 <rootDir>/__mocks__ 이 노드 모듈 모의 기본값이어야한다고 유지하고 싶다고 생각합니다. 이를 구성 옵션으로 만들 수도 있습니다 : "globalMocks"기본값은 <rootDir>/__mocks__ 입니다. 누구든지 이것에 대해 기꺼이 노력합니까?

다음 주말보다 빨리이 작업을 수행 할 수있을 것입니다.

나는 이번 일요일에 PR 작업을 할 수있어, 나는 좀 자유 롭다

요약하기 위해 @cpojer- <rootDir>/__mocks__ 기본값으로 globalMocks 구성 항목을 만듭니다. 이 옵션은 경로를 지정하여 jest 내에서 node-haste 사용을 규제합니다. 아니면 경로의 배열일까요?

이 문제를 해결하기위한 더 큰 변화라고 생각하지만, 단수 globalMocks 옵션 (문자열 또는 문자열 배열 일 수 있음)과 haste 모듈 경로 배열 인 hasteModules 옵션이 모두 필요하다고 생각합니다. 이 코드의 대부분은 jest-haste-map 및 jest-resolve에 있습니다. 올바른 솔루션이 아직 어떤 모습 일지 100 % 확신하지 못합니다.

보낸 사람 : Max Sysoev [email protected]
전송 : 2016 년 12 월 9 일 금요일 오전 8:18:44
받는 사람 : facebook / jest
참조 : Christoph Pojer; 언급하다
제목 : Re : [facebook / jest] [bug] 중복 된 수동 모의가 별도의 디렉토리에 있음 (# 2070)

나는 이번 일요일에 PR 작업을 할 수있어, 나는 좀 자유 롭다

@cpojer https://github.com/cpojer 요약하기-기본값으로 globalMocks 구성 항목 만들기/ __ mocks__. 이 옵션은 경로를 지정하여 jest 내에서 노드 헤이스트 사용을 규제합니다. 아니면 경로의 배열일까요?

-
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/facebook/jest/issues/2070#issuecomment-265958606 에서 보거나 https://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3WkAzks5rGQ7kgaJpZM4Kt2DW .

죄송합니다. 제 워크 스테이션이 고장 났고 몇 달 (1 ~ 2 개월) 안에 작동 할 방법이없는 것 같습니다. 이 PR에 대한 프로젝트도 잃어 버렸습니다.

getMockName 의 동작을 변경하는 구성 옵션

농담의 내부에 너무 익숙하지는 않지만 FB에 대한 농담을 깨지 않고 문제를 해결하는 가장 간단한 해결책 인 것 같습니다.

이것은 원래 생각했던 것보다 더 복잡 할 것입니다. 나에게 수동 모의는 가장 가까운 파일을 대체해야합니다. 이 같은:

{ 'aws-sdk': '/Users/project/__mocks__/aws-sdk.js',
  'slack': '/Users/project/__mocks__/slack.js',
  '/Users/project/db/index': '/Users/project/db/__mocks__/index.js',
  '/Users/project/slack/index': '/Users/projects/slack/__mocks__/index.js' }

require('aws-sdk') 받는 해결해야 /Users/project/__mocks__/aws-sdk.js 이가에 대한 모의입니다 node_module .

require('./db') (또는 db 대한 모든 경로)는 /Users/project/db/__mocks__/index.js 합니다.

jest 수동 모의를 설정하는 방법에 대한 나의 이해는 (위와 같은 것을 사용하는 경우 아마도 더 많은 문서가있을 것입니다) __mocks__ 디렉토리 내에서 가능한 한 모의되는 파일에 가까워 야한다는 것입니다.

수동 모의는 모듈 바로 옆에있는 __mocks __ / 하위 디렉토리에 모듈을 작성하여 정의됩니다. (https://facebook.github.io/jest/docs/manual-mocks.html)

이를 감안할 때 위의 행동이 가장 의미가 있습니다.

생각?

이것은 위와 같은 것을 구현하는 초기 단계입니다 : https://github.com/facebook/jest/compare/master...mhahn : issue-2070-new-mock-resolution

더 이상 다음과 같은 순수한 "이름이 지정된"모의를 허용하지 않기 때문에 대부분의 jest 단위 테스트를 중단합니다. https://github.com/facebook/jest/blob/master/packages/jest-runtime/src/__mocks__/ createRuntime.js

createRuntime 와 같은 IMO는 테스트 유틸리티 폴더에 있어야하며 필요한 테스트에서 가져와야하는 테스트 유틸리티입니다. 수동 모의로 구현되는 방식은 보존되어야하는 것으로 저에게 이해가되지 않습니다.

한 가지 옵션은 기존 동작과 위의 변경 사항을 정리 한 버전 사이를 전환하는 구성 변수를 추가하는 것입니다. 나는 그것이 무엇을 불러야하는지 정말로 잘 모르겠습니다.

우리는 Facebook에서 극도로 의존하고 있기 때문에 현재의 행동을 깨뜨릴 수 없습니다.

@cpojer 동의합니다. https://github.com/facebook/jest/issues/2070#issuecomment -265027510 코드를 읽은 후이 주석을 실제로 이해하지 못했습니다. 현재 동작을 해결할 디렉토리 목록을 허용 목록에 추가 할 수 있습니까?

두 가지 새로운 구성 옵션은 어떻습니까?

• fullPathMockResolution (기존 동작을 유지하기 위해 기본값은 false )
  결합:
• namedMockDirectories : fullPathMockResolution 가 활성화되면 해당 배열 내의 모든 디렉터리가 기존 동작으로 확인됩니다. FB 사용 사례의 경우 위에서 언급 한 것처럼 [<rootDir>] 됩니다.

이를 통해 개발자는 전체 경로 확인을 선택할 수 있으므로 기존 jest 설치에 의한 변경이 필요하지 않으며 원하는 경우 특정 디렉토리에 대한 기존 동작을 활성화 할 수도 있습니다.

cc @voideanvalue 이것은 당신이 생각해야 할 것입니다 (새로운 서둘러 구현의 일부로 네임 스페이스 매뉴얼 모의).

+1,이 문제를 해결할 방법이 있습니까?

+1

이 문제를 해결하는 방법에 대한 업데이트가 있습니까? 다음과 같은 구조를 따르면 정말 고통 스럽습니다.

project/
├── models
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/
├── challenges
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/

경로를 고려해야하기 때문에 실제로 충돌하는 이름이 없는데도 '충돌하는'이름을 가진 두 개를 사용하는 경우 테스트에서 모듈을 수동으로 모의해야합니다.

건배,
도미닉

@cpojer 여기에 업데이트가 있습니까? 해결 방법이 있습니까?

나를위한 약간의 해결 방법은 require로 모듈을 조롱하는 것입니다.

jest.mock('models/index', () => require('models/index/_mocks_/index'));

jest가 파일을 잡지 못하도록 __mocks__ 폴더 이름을 _mocks_ .

이것이 작동하는 어느 날 _mocks_ 을 __mocks__ 로 바꾸고 jest.mock에서 require 부분을 제거합니다.

첫째, 모든 멋진 작업에 감사드립니다.
둘째 : 이것은 정말, 매우 실망 스럽습니다. 모의 파일이 모의되는 전체 코드베이스의 다른 파일과 이름을 공유 할 때 테스트 파일에서 jest.mock을 사용해야하는 경우가 있습니다. 호이 스팅은 실제 모의 가져 오기도 허용하지 않으므로 해당 파일을 모의해야하는 두 테스트에서 모의를 복제해야하므로 테스트 스위트의 취약성이 추가됩니다. 이 문제를 해결하려고합니까? FB는이 물건을 사용합니까? 그렇다면 어떻게? 😞

이 경고를보고 매우 실망 스럽습니다. 수정을 기다릴 수 없습니다.

내가 가진 문제는 관련이 있다고 생각합니다.

jest.mock ( 'src / utils / history')가 있으면 'history'node_module도 잘못 조롱합니다.

https://github.com/cwmoo740/jest-manual-mocks-node-modules

얘들 아 어떤 업데이트?

@masoudcs 나는 이것이 경고를 제거했다고 생각합니다.

package.json

"jest": {
  /* other settings ... */
  "modulePathIgnorePatterns": ["<rootDir>/node_modules/react-native/Libraries/Core/__mocks__"]
}

modulePathIgnorePatterns 배열에 "중복"폴더를 추가하면 경고가 사라집니다.

감사합니다 @brunolm

그래서 그것은 단지 경고입니다, 맞습니까?!
나는 이것이 나쁜 일이 일어나지 않도록하고 싶다. 즉, 여러 디렉토리에서 index.js를 조롱하는 것
src/app/modules/module1/__mocks__/index.js 및 src/app/modules/module2/__mocks__/index.js

그게 중요한지는 모르겠지만 실행 중에는 다른 하나만 선택한다고 말했고 내가 나열한 것은 어느 쪽이든 무시할 것입니다.

그래서 무시하라고해도 괜찮다고 생각합니다. 어차피 사용하지 않았습니다.

예, 말씀하신대로, 지금까지 아무런 문제가 없었습니다.
바라건대, 그것은해야 할 일을하고 있습니다! :)
감사

이 마지막 두 커밋이 제안한 것을 시도했지만 경고를 제거하지 않았습니다.

jest.mock('dir/index', () => require('dir/__mocks_/index'));

내 구성에 testPathIgnorePatterns: ['/_book/', ...otherStuff] 이 있지만 GitBook ( ./_book 디렉터리)을 사용하기 때문에이 경고가 표시됩니다. 이 문제를 훑어 보면서 명확한 해결 방법을 찾지 못했습니다. 경고 표시를 중단하고 싶습니다. 어떤 도움을 주시면 감사하겠습니다.

+1

이것에 대한 업데이트가 있습니까?

또한 위에서 제안한 더 더러운 방법을 사용하지 않고 내 테스트 파일을 정기적으로 가져올 수 있도록 수정 사항을 찾고 있습니다.

jest.mock('models/index', () => require('models/index/_mocks_/index'));

우리의 디렉토리 구조는 여기를 참조 s의 '@dkundel 같은 모양 https://github.com/facebook/jest/issues/2070#issuecomment 와 자신의 네임 스페이스에서 모델과 구성 요소와 -301332202 index.js 기본 인 수출.

경고를 침묵 시키거나 모든 모의를 플랫 디렉토리에 던지지 않는 것을 선호합니다. 일부 모의는 깊게 중첩되어 있으며 제안 된 해결 방법은 다음과 같습니다.
jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index'));
우리 구조에서.

한마디?

@karomancer 구성을 사용하여 경고를 제거 할 수있는 PR # 6037을 제출했습니다. 아직은 병합되지 않았습니다. 기여자의 응답을 기다리고 있습니다.

이 문제는 매우 실망 스럽지만 더 깔끔한 명명 규칙을 만드는 좋은 해결 방법을 찾은 것 같습니다.

package.json

{
  "jest": {
    "setupFiles": [
      "<rootDir>/test.mocks.ts"
    ]
  }
}

/* test.mocks.ts */

// modules mocked before every test
// use `jest.unmock(...)` to undo for any single test case
const mockedModules = [
    "./path/to/module1/index.ts",
    "./path/to/module2/index.ts",
];

mockedModules.forEach((path) => {
    const mockPath = path.replace(/\.ts$/g, ".mock.ts");
    jest.mock(path, () => require(mockPath));
});

이렇게하면 anything.mock.ts 형제를 만들고 최상위 test.mocks 의 mockedModules 배열에서 원본 경로를 추가하여 anything.ts 를 모의 할 수 있습니다.

이 문제가 개선 사항으로 표시된 이유는 무엇입니까?

이것은 나를 위해 일하는 것 같습니다. jest.config.js에서 :

module.exports = {
  // ...
  modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]
};

작은 프로젝트가 있기 때문에이 변경의 범위 나 영향을 잘 모르겠습니다.

@amccloud 감사합니다! 이것은 내 문제를 해결했습니다! 아래 세부 정보.

내 프로젝트 루트 디렉토리에 helpers 모듈이 있습니다. 도우미가 parseNodeFromString 함수를 내보내고 있습니다.
다른 모듈 로컬 파일 helpers 에서 만들었습니다. 그런 다음 테스트 중 하나를 조롱했습니다. 그리고 parseNodeFromString 함수를 사용하는 모든 테스트가 다음 오류와 함께 실패하기 시작했습니다.

FAIL  src/some_dir/bla/tests/SomeClass.test.js
  ● Test suite failed to run

    TypeError: (0 , _helpers.parseNodeFromString) is not a function

이 문제는 어떻습니까? @amccloud 솔루션이 올바른 것 같습니다.

modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]

이 솔루션은 노드 모듈에 대한 최상위 모의가 실패하더라도 작동합니다. 그래서 "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"], 루트 __mock__ 폴더를 무시하지 않도록 변경했습니다. 여전히 mock이 루트의 전체 경로 를 기반으로 고유하지 않다는 것은 매우 이상합니다. users/helper.js & posts/helper.js 는 매우 일반적입니다. 경고는 상당한 공간을 차지하며 실제 경고를 완전히 숨기고 싶지 않습니다.

그렇다면 PR의 현재 상태는 무엇입니까? 적절한 해결책이나 해킹이 있습니까?

제 경우에는 모의 모듈이 모든 빌드와 함께 Dist 디렉토리에 복사되었습니다.

이것은 typescript가 더 깊은 dir 구조에 속하는 경로 / 패턴을 제외 할 수없는 문제인 것 같습니다. 여전히 "typescript@^3.4.5"에 문제가 있습니다.

이 문제를 해결하기 위해 모든 테스트 실행 전에 "rimraf dist"로 Dist 디렉터리를 청소하기 시작했습니다.

"test:unit": "npm run clean && stencil test --spec --snapshot",

나는 해킹이라는 것을 알고 있지만 작동합니다.

이봐 내가 여기에서 일어난 일을 해결했으며 아마도 이것을 복제하는 데 도움이 될 수 있습니다.

세 가지 솔루션 또는 시나리오 :

1, 텍스트 편집기에서 내 앱을 두 번 편집했습니다. 즉, 두 개의 다른 창에서 pod 설치 / 업데이트 및 react-native run-ios를 실행했습니다. 이 오류가 발생하여 Xcode와 내 앱에서 중복 파일을 검색했지만 찾을 수 없었습니다. 그래서 시뮬레이터에서 앱을 삭제하고 react-native run-ios를 다시 실행했는데 작동했습니다. 두 개의 node_modules가 내 scr 파일에서 node_modules와 node_modules0과 같이 복제 된 것으로 나타났습니다.

2, 때때로 내 Mac에서 임의의 키를 누르면 node_modules가 예를 들어 SRC 폴더에 복제되므로이 경우에도 마찬가지이므로 폴더에서 node_modules 중복을 살펴 보는 것이 좋습니다.

3, 동일한 시뮬레이터에서 다른 앱을 시작하고 종료 할 때까지 앱을 시작할 수 없었습니다. 그런 다음 중복 된 앱을 재부팅 한 다음 오류없이 실행되었습니다.

아직도 아무것도? CRA에서 modulePathIgnorePatterns를 사용할 수 없습니다.

3 년 10 개월

또는 경고 만하는 것이 아니라이 문제가 발생했을 때 Jest가 오류를 발생 시키도록 강제 할 수 있다면 좋을 것입니다. 경고는 쉽게 무시됩니다. 내 프로젝트에서 오류가 발생하는 것을 선호하므로이를 도입 한 개발자가 처리해야합니다.