어떤 조건 하에서 귀하의 flow-typed 폴더를 귀하의 패키지에 NPM에 게시해야하는지 궁금합니다. 어쩌면 (그리고 내가 생각해 왔던) 해답은 절대로 아니며 애플리케이션 개발자가 직접 플로우 유형을 사용하는 것이지만 아마도 flow-typed install은 패키지 내의 종속성이 아니라 스스로 선언 한 종속성에 대한 정의 만 선택합니다.유동 유형 폴더를 NPM에 게시해야합니까?
간단히 말해, 패키지에 피어 흐름 유형이없는 종속성이있는 경우 내 flow-typed 폴더를 게시해야합니까, 아니면이를 npmignore해야합니까?
이 폴더를 게시해서는 안됩니다. 패키지 크기를 불필요하게 늘리는 것 외에 게시하는 것이 좋지 않을 것이라고 생각하지 않습니다. 그러나 선한 일도 일어나지 않을 것입니다.
flow-typed의 요점은 해당 라이브러리 정의를 사용하는 경우 흐름은 라이브러리 코드을 확인할 필요가 없다는 것입니다. 대신 주어진 라이브러리 정의를 사용합니다. 라이브러리를 소비하는 경우 내 프로젝트의 Flow가 라이브러리를 유형을 확인하지 않습니다. 따라서 종속성에 대해 알 필요가 없습니다.
물론 이것은 라이브러리 인터페이스를 flow-typed으로 게시 할 때도 마찬가지입니다. 불행하게도이 도구는 아직 쉽게 만들 수 없지만 할 일은 옳습니다. 소스를 npm에 게시하는 경우 클라이언트가 사용했던 버전과 다른 버전의 Flow를 사용하고있을 수 있습니다. 따라서 거의 모든 Flow 릴리스가 변경되기 때문에 버전 차이로 인한 단순한 오류 메시지가 표시 될 수 있습니다. .flowconfig 옵션이 다른 경우에도 Flow 버전이 일치하더라도 오류가 발생할 수 있습니다.
우수. .. 실제로'$ flowFixMe'와 같이 사용자가 가지고 있지 않은 경우'.flowconfig'에 대한 응답으로 오류가 발생한다는 이전의 질문이있었습니다. ... 또한'flow-copy-source'를 사용하여 플로우 파일도 분산 패키지에 포함되어 있습니다. 'flow-typed'로 게시하는 대신 작동해야합니다. 맞습니까? –
여기 이전 질문 : http://stackoverflow.com/questions/42154415/in-flow-npm-packages-whats-the-properway-to-suppress-issues-so-user-apps-don –
그게 많은 경우에 작동해야하지만 config에서의 차이 (질문에서 언급했듯이) 또는 Flow 버전의 차이로 인해 100 % 신뢰할 수 없습니다. 확실한 유일한 방법은 typedef를 flow-typed에 게시하고 라이브러리 사용자가 거기에서 가져 오는 것입니다. 불행히도 툴링은 아직 쉽게 만들 수 없다는 점을 지적했습니다. –