React: 최상위 ES 수출 공식화

Imho import * 는 갈 길입니다. 기본 내보내기도 반대하지 않지만 이 예와 같이 다른 항목을 다시 내보내는 데 사용해서는 안 됩니다.

export const Component = ...
export default React
React.Component = Component

그러나 다음 예와 같이 다른 항목을 다시 내보내는 데 사용해서는 안 됩니다.

기술적인 이유가 있습니까? (같은 일을 하는 두 가지 방법을 제외하고.)

내 인상은 * 가져오고 기본값을 사용하지 않는 사람들은 기본값이 사용되지 않은 상태로 유지되기 때문에 트리 흔들림에 문제가 없을 것이라고 생각합니다. 하지만 롤업 등을 과대평가한 것일 수도 있습니다.

그 질문은 @lukastaegert가 가장 잘 답할 수 있습니다. https://github.com/facebook/react/issues/10021#issuecomment -335128611 이후로 무언가가 변경되었는지 확실하지 않습니다.

또한 Rollup이 유일한 트리 셰이커는 아니며 webpack의 트리 셰이킹 알고리즘이 롤업의 알고리즘보다 나쁘지만 사용률은 아마도 롤업보다 훨씬 높을 것입니다(두 도구 모두 우수한 작업을 수행하므로 누군가의 기분을 상하게 하고 싶지 않습니다) , 사실만 언급) 그리고 우리가 할 수 있다면 (커뮤니티로서) 두 도구를 동시에 도울 수 있다면 언제든지 그렇게 해야 합니다.

모든 것이 단일 플랫 번들로 사전 처리된다는 점을 감안할 때 트리 흔들기가 React의 경우 무엇이든 _do_ 합니까? React의 기본 가져오기 스타일이 무엇인지 궁금합니다. 개인적으로 React.Component , React.Children 와 같이 기본 내보내기처럼 처리하는 경향이 있지만 가끔 cloneElement 명명된 작업을 수행합니다.

@gaearon은 이미 다른 곳에서 언급했듯이 반응 시 크기 개선은 최소화될 것으로 예상됩니다. 그럼에도 불구하고 다음과 같은 장점이 있습니다.

• React.Children은 경우에 따라 제거될 수 있습니다(그래서 😉)
• React 자체는 이것을 지원하는 모듈 번들러에 의해 최상위 범위로 호이스트될 수 있습니다. 이것은 다시 꽤 많은 바이트를 제거할 수 있고 약간의 성능 향상을 제공할 수도 있습니다. 주요 개선 사항은 모든 모듈에 대해 React.Component 를 참조하는 또 다른 변수가 필요하지 않고 모든 곳에서 공유되는 변수만 있다는 사실에 있습니다(이것이 일반적으로 롤업이 수행하는 방식입니다). 또한 이것은 내가 추측한 것일 뿐 웹팩의 ModuleConcatenationPlugin이 빠져나갈 가능성을 줄일 수 있습니다.
• 반응에 대한 정적 분석은 모듈 번들러뿐만 아니라 IDE 및 기타 도구에서도 더 쉽습니다. 이러한 많은 도구는 이미 CJS 모듈에 대해 합리적인 작업을 수행하지만 결국에는 많은 추측이 관련되어 있습니다. ES6 모듈을 사용하면 분석이 간단합니다.

내보내기의 종류에 관해서는 물론 명명된 내보내기만 실제로 손쉬운 트리 흔들기의 이점을 제공합니다(GCC를 사용하지 않는 한 공격적인 움직임과 운이 좋으면 최신 롤업에서 더 많은 작업을 수행할 수 있음) . 기본 내보내기도 제공하는지에 대한 질문은 결정하기 더 어렵습니다.

• PRO: 기존 ES6 코드 베이스를 위한 손쉬운 마이그레이션(예:
• CON: 모든 것이 공통 개체에 연결되어 있기 때문에 이 개체가 포함되면 모든 키가 한 번에 포함되어 트리 흔들기 시도를 다시 무력화합니다. GCC조차도 여기에서 어려움을 겪을 수 있습니다.

두 가지 버전 마이그레이션 전략으로 호환성을 위해 더 이상 사용되지 않는 것으로 선언된(게터 등을 통해 경고를 표시할 수도 있음) 다음 버전에 기본 내보내기를 추가한 다음 이후 버전에서 제거할 수 있습니다.

이것은 흥미로운 사례이기도 합니다: https://github.com/facebook/react/issues/11526. 테스트를 위한 몽키패칭은 다소 애매하지만, 우리는 이것을 깨는 것에 대해 의식하고 싶을 것입니다(또는 이에 대한 해결 방법이 있음).

이 Twitter 대화 를 통해 여기에 왔습니다. 저에게는 이 질문에 대한 명확한 정답이 있습니다. React와 ReactDOM은 명명된 내보내기 만 내보내야 합니다. 상태를 포함하거나 다른 라이브러리가 속성을 변경하거나 추가할 수 있는 개체가 아닙니다(#11526에도 불구하고) — 존재하는 유일한 이유는 Component , createElement '넣는' 장소입니다

(그것은 또한 번들러의 삶을 더 쉽게 만들어 주지만 그것은 여기도 저기도 아닙니다.)

물론 이는 현재 기본 가져오기 및 트랜스파일을 사용하는 사람들에게 주요 변경 사항을 나타냅니다. @lukastaegert 는 접근자를 사용하여 지원 중단 경고를 인쇄하는 올바른 생각을 가지고 있을 것입니다. 버전 17에서 제거될 수 있습니까?

하지만 #11526에 대한 기성품 제안이 없습니다. 아마도 ESM을 배송하는 것은 어쨌든 그런 이유로 v17을 기다렸을 것입니다. 이 경우 사용 중단 경고에 대해 걱정할 필요가 없습니다.

사람들이 정말 좋아하게 되었습니다.

import React, { Component } from 'react'

그래서 포기하도록 설득하는 것은 어려울 수 있습니다.

약간 이상하더라도 이것이 너무 나쁘지는 않다고 생각합니다.

import * as React from 'react';
import { Component } from 'react';

명확히 하자면 JSX가 React.createElement() 변환되기 때문에 React 가 범위 내에 있어야 합니다(이 경우에는 네임스페이스로). JSX를 깨고 대신 전역 jsx() 함수에 의존한다고 말할 수 있습니다. 그런 다음 가져오기는 다음과 같습니다.

import {jsx, Component} from 'react';

괜찮을 수도 있지만 큰 변화입니다. 이것은 또한 React UMD 빌드가 이제 window.jsx 도 설정해야 함을 의미합니다.

왜 내가 제안하고 jsx 대신 createElement ? 글쎄, createElement 는 이미 오버로드( document.createElement )되었으며 React. 한정자로는 괜찮지만 전역에서 주장하지 않는 것은 너무 많습니다. Tbh 저는 이러한 옵션 중 하나에 대해 그다지 흥분하지 않으며 이것이 아마도 가장 좋은 중간 지점이 될 것이라고 생각합니다.

import * as React from 'react';
import { Component } from 'react';

기본적으로 JSX를 React.createElement 로 계속 변환합니다.

고백: 저는 JSX를 사용하기 위해 명시적으로 React 를 가져와야 한다는 사실이 항상 약간 이상하다는 것을 알았습니다. 비록 실제로 그 식별자를 어디에도 사용하고 있지는 않지만요. 아마도 미래에는 트랜스파일러가 JSX를 만날 때 import * as React from 'react' (Preact 등을 위해 구성 가능)를 삽입할 수 있습니다(아직 존재하지 않는 경우)? 이렇게 하면 됩니다만...

import { Component } from 'react';

... 네임스페이스 가져오기가 자동으로 처리됩니다.

먼 미래에, 아마도. 지금은 트랜스파일러가 다른 모듈 시스템(CommonJS 또는 전역)과 작동하는지 확인해야 합니다. 이것을 구성 가능하게 만드는 것도 장애물이며 커뮤니티를 더욱 분열시킵니다.

@Rich-Harris가 제안한 것(jsx를 사용할 때 특정 가져오기 삽입)은 트랜스파일러 플러그인으로 쉽게 수행됩니다. 커뮤니티는 babel-plugin-transform-react-jsx 를 업그레이드해야 합니다. 물론 기존 설정도 파일에 import * as React from 'react'; 만 추가하면 계속 작동합니다.

물론 다른 모듈 시스템도 생각해볼 필요는 있지만 풀기 어려운 문제는 아닌 것 같다. 염두에 두고 있는 특정 문제가 있습니까?

물론 다른 모듈 시스템도 생각해볼 필요는 있지만 풀기 어려운 문제는 아닌 것 같다. 염두에 두고 있는 특정 문제가 있습니까?

잘 모르겠습니다. 처리 방법에 대한 구체적인 제안은 무엇입니까? Babel JSX 플러그인의 기본값은 무엇입니까?

사람들이 정말 좋아하게 되었습니다.

import React, { Component } from 'react'

어떤 사람들? 내가 조롱할 수 있도록 나오십시오.

많이 했어요 🙂 확실히 다른 곳에서도 본 적이 있어요.

기본값은 현재 React.createElement 이며 거의 동일하게 유지됩니다. 유일한 문제는 현재(또는 이미 범위에서 사용 가능) 전역으로 가정한다는 것입니다.

es 모듈은 기본적으로 모듈을 수행하는 표준 방식(아직 모두 채택되지는 않았지만)이므로 대다수가 사용하거나 사용해야 한다고 가정하는 것이 합리적입니다. 대다수는 이미 다양한 빌드 단계 도구를 사용하여 번들을 생성 합니다 . React.createElement 를 범위에 자동 삽입하도록 jsx 플러그인의 기본 동작을 변경하는 것은 합리적인 일입니다. 우리는 babel@7 이 곧 제공될(-ish) 이러한 변경을 위한 완벽한 시간에 있습니다. 최근 babel-helper-module-imports 추가로 올바른 유형의 가져오기(es/cjs)를 파일에 삽입하는 것이 그 어느 때보다 쉬워졌습니다.

오늘날의 동작(범위에 있다고 가정)을 구제하기 위해 이 구성을 갖는 것은 소수의 사용자에게 필요한 구성의 사소한 변경과 대다수의 사용자에게는 개선(확실히 큰 것은 아니지만 여전히)처럼 보입니다.

더 나은 나무 흔들기를 위해 사람들이 *를 가져오도록 권장해야 합니까?

@alexlamsl 덕분에 uglify-es 는 일반적인 시나리오에서 export default 패널티를 제거했습니다.

$ cat mod.js 
export default {
    foo: 1,
    bar: 2,
    square: (x) => x * x,
    cube: (x) => x * x * x,
};

$ cat main.js 
import mod from './mod.js'
console.log(mod.foo, mod.cube(mod.bar));



md5-d6d4ede42fc8d7f66e23b62d7795acb9

$ uglifyjs -V
uglify-es 3.2.1

```js
$ cat bundle.js | uglifyjs --toplevel -bc
var mod_foo = 1, mod_bar = 2, mod_cube = x => x * x * x;

console.log(mod_foo, mod_cube(mod_bar));

$ cat bundle.js | uglifyjs --toplevel -mc passes=3
console.log(1,8);

와우, 새롭네요 👏 지금 uglify-es 가 안정적인 것으로 간주되나요? 나는 그것이 아직 거기에 아직 없다고 몇 달 전에 언급했던 것을 기억합니다. 그러나 나는 그것을 잘못 기억할 수 있으므로 확실하지 않습니다.

어쨌든 - 롤업 세계에서는 그게 전부이고 훌륭하지만 React 가 대부분 앱에 번들되어 있고 기본적으로 범위 호이스팅을 수행하지 않는 대부분 webpack 를 사용한다는 점을 고려하면 여전히 그렇게 말하고 싶습니다. uglisy-es + rollup 이외의 다른 도구가 더 작은 번들 크기를 생성하는 데 도움이 되도록 개체를 기본으로 내보내는 것을 피해야 합니다. 또한 나에게는 이것을 피하는 것이 의미적으로 더 좋습니다. 이러한 경우에 라이브러리가 실제로 하는 일은 네임스페이스를 제공하는 것이며 import * as Namespace from 'namespace' 사용할 때 더 잘 표현됩니다.

uglify-es는 이제 안정적인 것으로 간주됩니까?

JS 생태계의 다른 무엇보다 안정적입니다. 매주 500K 이상의 다운로드.

롤업 세계에서는 그게 전부이고 훌륭하지만 React가 주로 앱에 번들되어 있고 기본적으로 범위 호이스팅을 수행하지 않는 대부분의 webpack을 사용하는 것을 고려하면

어쨌든 옵션입니다. 어쨌든 Webpack 기본값은 이상적이지 않습니다. 아시다시피 ModuleConcatenationPlugin 를 사용해야 합니다.

여기에 몇 센트 추가:

• 의미상 명명된 내보내기가 올바른 선택이라는 @Rich-Harris의 말에 전적으로 동의합니다.
• JSX 구문을 사용할 수 있다는 이유로 import React from 'react' 또는 import * as React from 'react' 정말 좋아하지 않습니다. 내 눈에 이 디자인은 createElement 부분을 ​​사용할 수 있도록 사용자가 모든 React를 가져오도록 강제한다는 점에서 인터페이스 분리 원칙을 분명히 위반하고 있습니다. 불필요한 수출을 다시 제거하십시오)

따라서 획기적인 결정을 내릴 수 있는 시점에 있는 경우 JSX가 단일(전역 또는 가져온) 기능에 종속되도록 이를 변경하는 것이 좋습니다. 나는 그것을 createJSXElement() 라고 불렀을 것입니다. 제 생각에는 createElement() 보다 더 잘 설명하고 더 이상 의미가 있는 React 컨텍스트가 필요하지 않습니다. 그러나 모든 바이트가 중요한 세상에서는 jsx() 도 괜찮을 것입니다.

이것은 또한 다른 라이브러리가 동일한 변환을 사용하고 다른 jsx 함수를 제공하여 JSX를 지원하도록 선택할 수 있는 방식으로 React에서 JSX를 마지막으로 분리합니다. 물론 여기에서 이러한 변환을 통해 수많은 기존 응용 프로그램을 안내하는 많은 책임이 있지만 아키텍처 관점에서 보면 React와 JSX가 지향해야 하는 부분이 바로 여기입니다. Babel을 사용하여 그러한 변환의 무거운 작업을 수행하는 것은 나에게 좋은 아이디어처럼 들립니다!

개인적으로 babel 플러그인의 기본 IMHO가 react 패키지에서 가져와야 하므로 jsx 도우미로 마이그레이션하는 데 많은 이점이 없습니다. 따라서 실제 도우미의 이름은 실제로 문제 - 나머지는 구성할 수 있는 문제입니다.

이것은 아마도 주요 논의와 약간 접할 수 있지만 ES 모듈이 dev/prod 번들을 조건부로 내보내기 위해 process.env.NODE_ENV 를 검사하는 데 얼마나 잘 작동하는지 궁금합니다. 예를 들어,

https://github.com/facebook/react/blob/d9c1dbd61772f8f8ab0cdf389e70463d704c480b/packages/react/npm/index.js#L3 -L7

여기에 분명한 것을 놓쳤을 수도 있지만 이 패턴을 ES 모듈로 변환하는 방법을 보기 위해 고군분투하고 있습니까?

@NMinhNguyen ES 모듈에서는 조건부 내보내기가 불가능합니다.

process.env.NODE_ENV 검사는 더 세분화된(코드) 수준일 수 있으며 적절한 값을 가진 번들러로 교체할 준비가 되어 있습니다.

@Andarist @milesj 제 의심을 확인해 주셔서 감사합니다 :)

process.env.NODE_ENV 검사는 더 세분화된(코드) 수준일 수 있으며 적절한 값을 가진 번들러로 교체할 준비가 되어 있습니다.

React 16 블로그 게시물 에서 process.env.NODE_ENV 수표가 의도적으로 맨 위로 뽑혔다고 생각했습니다. ), Node.js의 성능을 돕기 위해?

더 나은 서버 측 렌더링

React 16에는 완전히 재작성된 서버 렌더러가 포함되어 있습니다. 정말 빠르네요. 스트리밍을 지원하므로 클라이언트에 바이트 전송을 더 빠르게 시작할 수 있습니다. 그리고 process.env 검사를 컴파일하는 새로운 패키징 전략 덕분에(믿거나 말거나, Node에서 process.env 를 읽는 것은 정말 느립니다!), 더 이상 좋은 서버를 얻기 위해 React를 번들로 묶을 필요가 없습니다. 렌더링 성능.

마찬가지로, 내가 하나가 사용할 수있는 방법을 모르겠어요 module 필드 package.json ES를 유지하는 평면 번들 및 영향을주지 않으면 서 ESM에 대한 dev에 / 자극 사이의 차별화를 Node.js를 반환 한

예를 들어 package.json의 모듈 필드를 어떻게 사용하고 ES 번들을 플랫하게 유지하고 Node.js 성능에 영향을 미치지 않으면서 ESM용 dev/prod를 구별할 수 있는지 잘 모르겠습니다.

현재로서는 이를 수행하는 표준 방법이 없기 때문에 이것은 확실히 단점입니다. OTOH 그것은 단지 도구의 문제일 뿐이며, 오늘날에도 애플리케이션의 빌드 단계에서 이것을 컴파일하는 것이 가능합니다(그리고 오히려 쉽습니다). 패키지가 dev/prod 빌드를 노출할 수 있고 리졸버가 어느 것을 고를지 알면 더 쉬울 것입니다.

학급을 위해:

import Component from 'react/Component'

class MyButton extends Component{
  constructor(){
    this.state = {}
  }

  render() {
    return <button> Button <Button>
  }
}

여기서 변환은 super.createElement()를 사용하여 jsx로 변환하거나 정적 Component.createElement()를 사용합니다.

상태 비저장 구성 요소의 경우:

import jsx from 'react/jsx'

const MyButton = () => jsx`<button> Button <Button>`;

태그가 지정된 템플릿 리터럴을 사용할 수 있습니까?

노드가 이 PR을 수락하기를 바랍니다. https://github.com/nodejs/node/pull/18392

@Rich-Harris의 의견에 동의합니다.

실제로 구체적으로 언급되지 않은 이 스레드에 대한 의견을 남기는 것입니다.

나는 번들러를 전혀 사용하지 않고 브라우저( <script type="module" src="..."> )를 통해 기본적으로 사용하기 위해 반응 및 다양한 구성 요소를 가져오려는 상황에 있습니다. 즉,

import React from “https://unpkg.com/[email protected]/umd/react.development.js”;
import ReactDOM from “https://unpkg.com/[email protected]/umd/react-dom.development.js”;
ReactDOM.render(
  React.createElement(...),
  document.getElementById('root')
);

내가 말할 수 있는 바에 따르면 이것은 오늘날 불가능합니다. 대신 CDN의 <script> 태그를 통해 react의 UMD 버전을 포함해야 하며 다음과 같이 내가 작성하는 <script type="module"> 모듈의 창에 있다고 가정해야 합니다.

// myPage.html
<div id="myComponentRoot"></div>
<script src="https://unpkg.com/[email protected]/umd/react.development.js"></script>
<script type="module" src="/assets/scripts/components/MyComponent.js"></script>

// MyComponent.js
import AnotherComponent from "/assets/scripts/components/AnotherComponent.js";
window.ReactDOM.render(
  window.React.createElement(AnotherComponent),
  document.getElementById('root')
);

// AnotherComponent.js
export default class AnotherComponent extends window.React.Component {...}

CDN에서 반응 가져오기가 있으면 환상적일 것입니다. 파일 분리를 유지하면서 브라우저에서 프로토타이핑을 매우 빠르고 쉽게 만들 수 있습니다. 번들러 없이 React를 사용할 때 내가 항상 희생한다고 느꼈던 한 가지는 구성 요소(및 기타 유틸리티 기능 등)를 파일로 분리하는 기능이었습니다. 하지만 이제 기본 ES 모듈에 대한 브라우저 지원을 통해 React 구성 요소를 별도의 파일에 작성하고 작성된 대로 브라우저에서 사용하도록 할 수 있습니다. JSX를 사용하지 않는 경우지만 JSX를 사용하더라도 빌드 단계를 통해 모든 파일을 제자리에 둘 수 있고 모든 가져오기가 브라우저에서 계속 작동합니다.

// /assets/scripts/entry.js
import React from “https://unpkg.com/[email protected]/umd/react.development.js”;
import React from “https://unpkg.com/[email protected]/umd/react-dom.development.js”;
import RelatedPosts from "/assets/scripts/components/RelatedPosts.js";
ReactDOM.render(
  React.createElement(RelatedPosts),
  document.getElementById('root')
);

// /assets/scripts/components/RelatedPosts.js
import React from “https://unpkg.com/[email protected]/umd/react.development.js”;
import ListItem from "/assets/scripts/components/ListItem.js"
export default class MyComponent extends React.Component {
  componentDidMount() { /* fetch some data */ }
  render() { 
    return React.createElement(
      'ul',
      {},
      this.state.items.map(item => React.createElement(ListItem, { item: item })
    )
  }
}

// /assets/scripts/components/ListItem.js
import React from “https://unpkg.com/[email protected]/umd/react.development.js”;
export default function ListItem(props) {
  return React.createElement('li', null, ...)
}

어떤 사람들은 CDN URL을 항상 입력하는 것이 문제(일부 사람들은 해결하려고 하는 문제)라고 주장하지만 저에게는 그만한 가치가 있습니다. 해당 URL을 변경/업데이트는 간단한 찾기/바꾸기입니다. 내 사용 사례의 경우 번들러를 설정하는 수고를 능가합니다.

React가 이와 같은 것을 지원했다면 도구가 필요하지 않았을 것입니다. 저는 그냥 브라우저를 사용하고 있습니다. 나는 최신 브라우저를 가정하고 페이지에서 점진적인 향상으로 반응하는 몇 가지 개인 프로젝트에서 이와 같은 코드를 제공할 수 있습니다. 이것을 환상적으로 만드는 것은 12개월 만에 코드 베이스로 돌아왔을 때 많은 도구 API를 변경하거나 NPM을 패키지 관리자로 사용할 필요가 없다는 것입니다. 저는 브라우저에서 API를 사용하고 있을 뿐입니다. 다른 것은 없습니다.

FWIW는 : / 반작용 할 때이 같은 지원으로 배를 않는 경우, 당신 반응 활용을 통해 각 구성 요소 로직을 분리하여 그 구성 모델 수 있다는 가르침, 당신이 문서에서 다음과 같이 반작용 사용할 수있는 방법을 보여 매우 도움이 될 수 있다고 생각의 자신의 파일을 만들고 이를 수행하기 위해 번들러가 필요하지 않습니다. 네이티브 <script type="module"> 를 사용하고 CDN(또는 자체 로컬 복사본)에서 React를 가져오면 해제됩니다!”

이제 모바일 버전을 포함한 모든 최신 브라우저가 ESM을 지원합니다. ESM은 더 이상 미래의 모듈 시스템이 아니라 현재의 사실상의 표준입니다.

표준화된 모듈을 제공하지 않는 것은 특히 사실상의 표준 웹 라이브러리의 경우 중요한 문제입니다.

import * as React from 'react';
import * as ReactDOM from 'react-dom';

이것은 React 라이브러리를 적용하는 일반적인 코드이며 실제로 가져올 수 있는 라이브러리가 없는 대신 타사 트랜스파일러와 번들러가 가져오기 프로세스를 에뮬레이트합니다.

어쨌든 브라우저가 기본 ESM을 지원하지 않았기 때문에 실제 ESM을 제공하지 않는 것이 약간 정당화되었지만 분명히 시간이 지났고 이제 import 일반적인 샘플 코드에 지정된 대로 ESM을 제공할 때입니다.

나는이 작업을 시작 여기 와 여기에

@TrySound 기여해 주셔서 감사합니다.
ESM 빌드를 가져와 테스트할 수 있는 곳이 있습니까?

react-is 패키지에만 사용할 수 있습니다.

@TrySound
좋아, https://github.com/TrySound/react/tree/react-is-esm 지점을 찾았고 구축했으며 이제 당신이 의미하는 바를 압니다. react-dom 도 기대됩니다.

나는 React 커뮤니티에서 이 문제에 대해 한동안 충분히 논의했다고 생각합니다.
https://discuss.reactjs.org/t/es6-import-as-react-vs-import-react/360/

공식 ES6 모듈 사양을 결정하고 곧 게시하십시오.

@kenokabe 가는 중입니다. 우리를 강요하지 마십시오. 그렇게 쉬운 일이 아닙니다.

현재 계획은 명명된 내보내기만 있는 모든 패키지를 마이그레이션하는 것입니다. 이 변경 사항은 라이브러리 코드에 영향을 미치지 않으며 문서에서 명명된 내보내기도 사용하므로 주요 변경 사항이 도입되어서는 안 됩니다.

다른 패키지의 경우 다양한 도구와 다르게 작동하는 기본 내보내기와 명명된 내보내기를 모두 처리해야 합니다.

@TrySound 죄송합니다.
이 주제의 헤드 멘션이

각 패키지에서 최상위 ES 내보내기가 어떻게 보일지 실제로 결정하지 않았기 때문에 이 작업을 쉽게 수행할 수 없습니다. 예를 들어, react에는 이름이 지정된 내보내기가 많이 있지만 React라는 기본 내보내기도 있습니까? 더 나은 나무 흔들기를 위해 사람들이 *를 가져오도록 권장해야 합니까?

그리고, 언급된 날은 얼마 전이고, React 커뮤니티에서 논의된 것으로 생각했기 때문에 결정이 명확해야 한다고 제안하고 싶었습니다. 감사 해요!

이것에 대한 업데이트를 원하십니까...

저는 우리 애플리케이션을 번들링하기 위해 webpack v4를 사용하고 있습니다. 반면 제 IDE 인텔리센스(WebStorm)에서는 import * as React from 'react'; 를 사용하라고 제안하고 동료는 코드 검토에서 import React from 'react'; 를 변경하도록 요청합니다. 둘 다 잘 작동하므로 그가 말도 안 되는 말을 하고 있다고 생각했지만 그를 기쁘게 하기 위해 어쨌든 변경하고 있습니다. 이 스레드를 찾는 방법이기도 합니다.

궁금해서 최종 빌드 크기의 차이점을 비교합니다(React 16.8.1 사용).

import * as React from 'react'; : 6,618,723바이트
import React from 'react'; : 6,619,077바이트

그래서 분명히 약간의 차이가 있었지만 미미했습니다. (참고. 나는 propTypes 와 동일하게 했습니다)

이 스레드에 대한 내 이해가 정확하다면 import * as React from 'react'; 를 갖는 것이 유리할 것입니다. 맞습니까? (1) 예, 약간의 크기를 절약했기 때문입니다. (2) ESM은 표준화된 방식이므로 더 이상 CJS가 남지 않습니다. 그렇다면 오늘 이것을 변경하고 내 IDE에 맞추고 싶습니다.

@leoyli 장기적으로 그렇습니다. 그러나 먼저 기존 코드를 손상시키지 않도록 명명된 내보내기와 기본 내보내기가 둘 다 있을 것입니다.

나는 내 프로젝트에서 더 이상 번들러를 사용하지 않고 여전히 반응을 사용하기를 원했기 때문에 여기에서 직접 문제를 해결했습니다(Vue, Hyperapp 등과 같은 다른 라이브러리에서 할 수 있는 것처럼 unpkg.com에서 직접). . 이것은 내가 생각해 낸 것입니다. 멋진 것은 아니며 손으로 편집 한 umd입니다.

https://github.com/lukejacksonn/es-react

React 및 ReactDOM 의 최신 버전을 노출하는 ES6 모듈

README에 설명된 대로 이것은 대부분 POC이지만 이 빌드가 착륙할 때까지 기다릴 수 없는 사람들을 위해 후크, 서스펜스, 게으름 등을 포함하고 다음을 수행하여 예상대로 작동하는 16.8.3 빌드입니다.

import { React, ReactDOM } from 'https://unpkg.com/es-react'

이 스레드의 일부는 유용할 것입니다. 개인적으로 저는 이 접근 방식을 사용하여 빌드 단계가 없는 반응 스타터 프로젝트 를 만들었습니다. 또한 아직 진행중인 작업입니다.

@lukejacksonn 우리는 프로덕션에서도 이러한 솔루션을 사용하고 있지만 현재 프로젝트에서 UMD 버전의 React 및 ReactDOM에 대한 변환기 스크립트라는 점에서 접근 방식이 다릅니다. 그리고 이 파일을 개별적으로 출력하므로 대부분의 코드에 대해 교체용 드롭인이어야 합니다. https://github.com/wearespindle/react-ecmascript에 관심이 있고 unpkg https://unpkg.com/react-ecmascript/ 에서 로드할 수도

@ PM5544 오 와우.. 이것은 내 것보다 훨씬 포괄적 인 솔루션입니다! 잘했어 💯

멋진 물건 @ PM5544. 언젠가 그것에 대해 더 듣고 싶습니다. Xebia에 다시 게스트로 출연할까요?
저는 최근에 UNPKG를 지원하는 오픈 소스 패키지를 묶기 위해 팩 을 채택했습니다.
번들러를 사용하는 대신 UNPKG에서 직접 종속성을 로드하는 방법에 대한 좋은 기사를 아는 사람이 있습니까?

저는 현재 하나를 작성 중이며 6월에도 React 노르웨이에서 강연으로 제공할 예정입니다!

@TrySound 2월 이후에 이에 대한 업데이트가 있었습니까? 이 문제를 옮기기 위해 남은 것은 무엇이며 일부 코딩 작업으로 이 문제를 해결하는 데 참여할 수 있습니까? 저는 이미 CA에 서명했으며 오늘 작업할 시간이 있습니다.

이것은 먼저 병합해야 합니다 https://github.com/facebook/react/pull/15037

@TrySound 알겠습니다. 해당 스레드에 대한 지원 제안을 전달했습니다.

기본 React 내보내기를 사용할 때 다음 접근 방식을 사용할 수 있습니다.

// react/index.js
import * as React from "./react";
export { React as default }
export * from "./react";

// react/react.js
export function createElement() {}
...

이것은 기본 내보내기가 웹팩 5 및 롤업에서 이러한 구성에 대해 트리 흔들림을 허용하는 네임스페이스 객체라는 것을 정적으로 분석할 수 있게 합니다.

import React from "react";

React.createElement(); // <- only `createElement` export is used

롤업 은 그것을 매우 좋아할 것입니다.

나는 1.5 년 동안 롤업 gitter chat에 있었고 이러한 종류의 문제는 2 주 정도마다 나타납니다 ...

BTW, @lukejacksonn 은 es-react 포크에서 엄청난 일을 했으며 강력히 추천할 수 있습니다.

BTW, @lukejacksonn 은 es-react 포크에서 엄청난 일을 했으며 강력히 추천할 수 있습니다.

공식 FB 팀이 왜 이것에 대해 아무것도하지 않는지 궁금합니다.

나는 또한 이것이 앞으로 나아가는 데 약간의 압력을 가하기를 바 랐고 @lukejacksonn 자신도

이것도 참으로 바랐다. 사실 저는 패키지를 만드는 과정에서 react 팀의 지원을 거의 받지 못했습니다(@threepointone의 격려의 말 외에). 최근에 여기 Formidable의 동료가 프로그래밍 방식으로 패키지를 빌드하는 데 도움을 주었습니다. 이는 새로운 버전의 react가 릴리스될 때마다 수동으로 수행하는 것보다 개선되었지만 네트워크 탭에서 훨씬 덜 깨끗한 출력을 가져오므로 그렇게 될지 확신할 수 없습니다. 아직 이대로 있어. 우리는 보게 될 것이다!

이제 거의 2020년인데 공식 FB 팀에서 업데이트가 있는지 알고 싶습니다. React v17에서 이와 관련된 변경 사항이 있습니까?

업데이트된 ES 모듈 React NOW가 필요한 경우 이미 v16.13.x에 있는 @pica/react 를 시도하십시오.
https://www.npmjs.com/package/@pika/react
https://www.npmjs.com/package/@pika/react -dom
https://github.com/pikapkg/react

먼 미래에, 아마도.

좋아, 이미 미래에. 지금은 가까운 미래인가요?

@gaearon 내보내기(기본 내보내기 대 명명된 내보내기)를 구성하는 방법을 결정하기 위한 차단기는 무엇입니까? 이 결정을 내리는 데 커뮤니티에서 도움을 줄 수 있는 것이 있습니까?

분명히 그 결정은 이미 얼마 전에 내려진 것 같습니다: #18102. 이 문제는 지금 닫을 수 있습니다.

이에 대해 약간의 업데이트를 드리겠습니다.

기본 내보내기 없음

우리의 최종 계획은 기본 내보내기에서 완전히 벗어나는 것입니다.

import { useState } from 'react';

그 세계에서는 다음과 같이 작동 하지 않습니다 .

import React from 'react'; // no

약간 시끄럽지만 작동합니다.

import * as React from 'react';

하지만 여기에 키커가 있습니다. 실제로 React 를 가져올 이유가 많지 않습니다.

JSX 자동 가져오기

오늘날 사람들이 React 수입하는 이유는 대부분 JSX 때문입니다. 그러나 @lunaruan 은 새로운 JSX 변환 및 관련 codemod에 대한 작업을 마무리 중이므로 필요하지 않습니다.

그래서 당신은 이것에서 갈 것입니다 :

import React from 'react';
import { useState } from 'react';

function Button() {
  const [pressed, setPressed] = useState(false)
  return <button />
}

이에:

import { useState } from 'react';

function Button() {
  const [pressed, setPressed] = useState(false)
  return <button />
}

JSX는 후드 아래에 올바른 가져오기를 자동으로 삽입하므로 범위에 React 가 필요하지 않습니다.
이것이 기본 내보내기를 제거하려는 움직임을 허용하는 이유입니다. 당신은 그것들이 그다지 필요하지 않습니다.

ES 모듈

전반적으로 소수의 애호가를 넘어 ESM을 배포하는 것은 어려운 일입니다. 광범위한 생태계는 실제로 준비되지 않았으며 다양한 도구 조합으로 인해 문제가 발생하는 방법이 많이 있습니다. CJS와 ESM이 상호 작용하는 방식은 매우 복잡하며 해당 상호 운용성(및 실패 방식)이 이러한 문제의 대부분의 원인입니다.

그래서 우리의 현재 생각은 우리가 ESM을 할 때 ESM을 끝까지 시도하고 싶을 수도 있다는 것입니다. CJS가 전혀 없거나 호환되는 레거시 패키지로 분리됩니다. 이것은 React 17에서는 발생하지 않으며 18에서는 가능성이 낮지만 React 19에서 시도하는 것은 그럴듯합니다.

@pika/react 의 ESM 빌드에 대한 대안을 찾는 사람은 https://github.com/esm-bundle/react 및 https://github.com/esm-bundle/react-dom을 확인 import React from 'react'; 는 전체 CDN URL에서 React를 가져오도록 변경됩니다. 또 다른 차이점은 수동 단계 없이 새 반응 버전이 게시될 때마다 새 버전이 자동 게시된다는 것입니다.

코드 샌드박스 시연: https://codesandbox.io/s/gifted-roentgen-qcqoj?file=/index.html

몇몇 사람들은 생태계가 준비되지 않았다는 개념에 이의를 제기했습니다. 이에 대한 전체 맥락은 없지만 지금이 변경을 시작하기에 좋은 시기라고 생각하시면 https://github.com/reactjs/rfcs/pull/38을 살펴보고 그것에 대한 우려. 대략적으로 염두에 두었습니까, 아니면 다른 접근 방식을 선호합니까?

하지만 여기에 키커가 있습니다. 실제로 React를 가져올 이유는 많지 않습니다.

TypeScript를 사용하고 있다면 앞으로도 그럴 것입니다. TS가 babel의 이 새로운 마술 동작에 대해 배울 때까지 개발자는 계속해서 명시적으로 React를 가져와야 하고 올바른 import 문이 무엇인지 알아야 합니다.

JSX는 후드 아래에 올바른 가져오기를 자동으로 삽입하므로 범위에 React가 필요하지 않습니다.

s/JSX/새로운 babel react jsx 변환 플러그인/. JSX는 JavaScript에 대한 구문 확장이며 자체적으로는 아무 것도 하지 않습니다.

TypeScript를 사용하고 있다면 앞으로도 그럴 것입니다. TS가 babel의 이 새로운 마술 동작에 대해 배울 때까지 개발자는 계속해서 명시적으로 React를 가져와야 하고 올바른 import 문이 무엇인지 알아야 합니다.

TypeScript 팀은 이 변경 사항을 알고 있으며 https://github.com/microsoft/TypeScript/issues/34547 에서 추적 중

s/JSX/새로운 babel react jsx 변환 플러그인/

예, 이것이 내가 의미했던 것입니다!

reactjs/rfcs#38을 살펴보고 이에 대한 우려 사항을 표현해 주시면 감사하겠습니다. 대략적으로 염두에 두었습니까, 아니면 다른 접근 방식을 선호합니까?

RFC의 원본 텍스트 중 일부가 오래되었습니다. NodeJS를 사용하면 package.json에 "type" 를 지정할 때 .mjs 대신 .js 파일에서 ESM을 실행할 수 있습니다. ( 문서 ).

특히 RFC 원본 텍스트는 다음과 같이 사실이 아니라고 말합니다.

ESM 코드 는 .mjs 파일 안에 있어야 합니다.

@frehner 와 대화한 후 React가 ESM으로 점진적으로 변환될 수 있는 방법에 대한 제안이 있습니다. ESM 버전의 React를 게시할 때 명명된/기본 내보내기 문제를 연결하지 않습니다. @gaearon 은 기본 내보내기가 결국 사라질 것이라고 밝혔지만 이는 4단계까지 제안서에 나열되지 않습니다.

| | 1단계 | 2단계 | 3단계 | 4단계 |
| - | -------- | -------- | -------- | ------- |
| ESM 게시? | ✔️ | ✔️ | ✔️ | ✔️ |
| 패키지.json "module" | ❌ | ✔️ | ✔️ | ✔️ |
| 웹팩/롤업 사용 esm ^{1 , 2} | ❌ | ✔️ | ✔️ | ✔️ |
| 패키지.json "exports" | ❌ | ❌ | ✔️ | ✔️ |
| 패키지.json "type" | ❌ | ❌ | ✔️ | ✔️ |
| NodeJS는 esm을 사용합니다 | ❌ | ❌ | ✔️ | ✔️ |
| 획기적인 변화? | ❌ | ❌ | ❓ | ✔️ |
| 기본 내보내기가 사라졌습니까? | ❌ | ❌ | ❌ | ✔️ |
| 가져오기에 필요한 파일 확장자 | ❌ | ❌ | ❌ | ❌ |
| mjs 파일 확장명 | ❌ | ❌ | ❌ | ❌ |

1단계는 실제로 매니아만을 대상으로 하기 때문에 1단계와 2단계를 함께 결합하는 것에 대한 타당한 주장이 있다고 생각합니다. 그러나 단계를 분리하면 먼저 얼리 어답터에게 문제를 보고하고 수정 사항을 찾을 수 있는 기회를 주지 않고 CRA와 전체 생태계를 즉시 중단하지 않는 방식으로 ESM을 매우 천천히 롤아웃할 수 있는 기회가 있다고 생각하기 때문에 분할했습니다. .

@joeldenning 단계의 대략적인 타이밍은 무엇입니까? 시간 기반입니까 아니면 생태계의 일부 시간 체크포인트와 관련된 것입니까? require('react') 이 3단계에서 계속 작동합니까?

단계의 대략적인 타이밍은 무엇입니까? 시간 기반입니까 아니면 생태계의 일부 시간 체크포인트와 관련된 것입니까?

모든 단계의 타이밍은 수행해야 할 작업과 React의 릴리스 일정에 의해서만 제한됩니다. 내 이해는 제안된 모든 것이 번들러와 nodejs에서 지원되며, 지원하지 않는 이전 버전을 사용할 때 적절한 폴백과 함께 지원된다는 것입니다.

require('react')가 3단계에서 계속 작동할까요?

나는 그렇게 생각한다. https://nodejs.org/api/esm.html#esm_dual_commonjs_es_module_packages 및 https://nodejs.org/api/esm.html#esm_package_entry_points를 참조하십시오. 물론 내가 모든 경우에 대해 모든 상황을 알 수는 없지만 내가 제안한 전환 경로는 "어디서나 작동할 것"이라고 이해합니다. 아마도 그 유명한 마지막 말일 것입니다 😄

추가 설명은 다음과 같습니다. 게시된 tarball이 React에 대해 다음과 같이 표시됩니다.

node_modules/react/
  cjs/
    react.development.js
    react.production.min.js
    react.profiling.min.js
  umd/
    react.development.js
    react.production.min.js
    react.profiling.min.js
  esm/
    react.development.js
    react.production.min.js
    react.profiling.min.js
  index.js

그리고 마지막에 package.json이 어떻게 될 것인지에 대한 근사치는 다음과 같습니다.

{
  "type": "module",
  "main": "index.js",
  "module": "esm/react.development.js",
  "exports": {
    "import": "./esm/react.development.js",
    "require": "./cjs/react.development.js"
  }
}

^ 이것은 완전히 생각하고 완성한 것은 아니지만 제안에 대한 구체적인 컨텍스트를 제공하기 위해 공유하고 있습니다.

그래서 - React는 상태 저장(훅)이기 때문에 이중 패키지 위험을 겪습니다. 따라서 이 상태는 신중하게 격리되어야 합니다. CJS 및 ESM 항목 모두에서 가져올 수 있는 작은 CJS 파일에 있어야 하거나 .json 로드하고 두 항목에서 해당 상태로 변경하는 방법이 있을 수 있습니다. 두 번째 접근).

또한 이미 1단계에서 발생하는 명명된 내보내기를 추가하여 테이블에 나열하는 것이 중요하다고 생각합니다.

일부 코너 케이스를 놓친 적이 없는지 100% 확신할 수 없습니다. 이 주제는 매우 복잡합니다. 동시에 일정은 생태계 체크포인트와 연결되어야 합니다. 3단계는 exports 번들러에서 충분한 지원이 있어야만 배송될 수 있습니다. 그렇지 않으면 잠재적인 문제가 발생할 수 있다고 생각합니다.

React는 상태 저장(후크)이므로 이중 패키지 위험이 있으므로 이 상태를 신중하게 격리해야 합니다.

좋은 점, 나는 이것을 고려하지 않았습니다( 추가 정보 ). 이 경우 CJS/ESM 빌드 간에 공유 파일을 제안하는 것이 유용할 수 있습니다. 또는 ESM 버전이 react의 전체 복사본이 아니라 CJS 빌드를 호출하는 ESM 공개 인터페이스일 수도 있습니다.

또한 이미 1단계에서 발생하는 명명된 내보내기를 추가하여 테이블에 나열하는 것이 중요하다고 생각합니다.

그러나 이것은 소스 코드에서 이미 해당되는 것 같습니다. 내가 알 수 있는 바에 따르면 소스 코드는 이미 명명된 내보내기로 항목을 내보냅니다.

https://github.com/facebook/react/blob/ef22aecfc52cdf0d7cedc723c590719c009c2a64/packages/react/index.js#L39

https://github.com/facebook/react/blob/ef22aecfc52cdf0d7cedc723c590719c009c2a64/packages/react/index.js#L39

일부 코너 케이스를 놓친 적이 없는지 100% 확신할 수 없습니다. 이 주제는 매우 복잡합니다. 동시에 일정은 생태계 체크포인트와 연결되어야 합니다. 3단계는 수출이 번들러에서 충분한 지원을 받은 후에만 배송될 수 있습니다. 그렇지 않으면 이것이 잠재적인 문제로 이어질 수 있다고 생각합니다.

3단계에 대해 동의했습니다. 이것이 브레이킹 체인지 여부에 대해 물음표를 표시한 이유입니다. package.json 내보내기를 추가하는 것은 종종 생태계의 다른 패키지에 대한 주요 변경 사항이라는 것을 알고 있습니다. 그리고 주제는 확실히 복잡합니다. 한 가지 주목해야 할 점은 원하는 경우 3단계와 4단계의 순서를 바꿀 수 있다는 것입니다. 각 단계를 구현하는 사람들은 webpack, 롤업, nodejs 등의 여러 버전에 대해 매우 철저한 테스트를 수행해야 한다고 생각합니다. 수행해야 할 작업이 사소하다고 말하는 것이 아닙니다. 아마도 여기에서 전환 경로 일 것입니다 :)

그러나 이것은 소스 코드에서 이미 해당되는 것 같습니다. 내가 알 수 있는 바에 따르면 소스 코드는 이미 명명된 내보내기로 항목을 내보냅니다.

아 - 맞아요, 이 경우 export default 😂를 추가하기 위한 테이블 행이 있어야 합니다. 현재 대부분의 번들러에서 작동하고 널리 사용되지만 default 를 제공하지 않고 진정한 ESM 항목을 추가하면 그 사용법을 깨십시오.

이 경우 내보내기 기본값을 추가하기 위한 테이블 행이 있어야 합니다.

네, 좋은 지적입니다. 추가하겠습니다. 그렇게 하는 PR은 "나쁘게 보일 것"이라고 생각하지만 현재의 공개 인터페이스를 있는 그대로 받아들이고 앞으로 개선할 계획이라고 봅니다.

일부 버전이 게시되면 되돌릴 수 없으며 의미론적 변경 사항이 깨질 수 있다는 점에 유의해야 합니다. 메이저를 자주 릴리스하지 않는다는 점을 감안할 때 변동을 최소화하기 위해 변경 사항을 일괄 처리하는 방법을 고려해야 합니다.

개발/프로덕션 빌드 분할을 처리하는 방법에 대한 질문도 있습니다. 그리고 실제로 React 빌드의 상태 저장 특성은 보존하는 것이 매우 중요합니다.

일부 버전이 게시되면 되돌릴 수 없으며 의미론적 변경 사항이 깨질 수 있다는 점에 유의해야 합니다. 메이저를 자주 릴리스하지 않는다는 점을 감안할 때 변동을 최소화하기 위해 변경 사항을 일괄 처리하는 방법을 고려해야 합니다.

좋은 점. 내 아이디어는 React 16에 게시된 ESM 빌드에 명시적인 export default React 를 추가하는 것입니다. PR이 일부 눈썹을 일으키고 논란의 여지가 있을 수 있다고 생각합니다. 목적지가 결정되지 않았기 때문입니다. 그러나 제 생각에는 React 16에서 ESM 빌드를 갖고 다음 주요 버전에서 export default 를 제거할 수 있다는 것입니다. 나에게 import React from 'react'; 를 통해 반응을 사용하는 것은 매우 일반적이어서 ESM 빌드에서 기본값을 내보내는 것은 단순히 "우리가 있는 곳을 수락"하는 것입니다. 향후 주요 버전에서는 이를 제거할 것입니다.

또한 주요 변경 사항을 최소화하는 것과 관련이 있습니다. 3단계와 4단계는 동일한 주요 릴리스의 일부일 수 있습니다. 3단계가 완전히 이전 버전과 호환되는 방식으로 수행될 수 있으며, 이 경우 16 릴리스에 들어갈 수도 있습니다. 그러나 그것은 더 까다롭고 그것에 대해 확신할 만큼 충분히 알지 못합니다.

개발/프로덕션 빌드 분할을 처리하는 방법에 대한 질문도 있습니다.

이것은 내가 간과 한 것입니다. 번들러와 NodeJS 모두에서 ESM을 사용하여 이 작업을 수행하는 방법을 모르지만 가능한 것이 무엇인지 알아보기 위해 몇 가지 조사를 할 것입니다. 나는 이 죽은 제안을 찾았지만 살아있는

그리고 실제로 React 빌드의 상태 저장 특성은 보존하는 것이 매우 중요합니다.

동의. 한 가지 주의할 점은 React 빌드의 stateful 특성은 Phase 1과 2가 아니라 Phase 3에서만 해결하면 된다는 것입니다. @Andarist 와 제가 제안한 옵션이 문제를 해결하는 데 효과적입니다.

지금은 가장 쉬운, 가장 하위 호환성 접근라는 이름의 수입을 허용하는 간단한 ESM 래퍼를 추가하는 것입니다.

이것을 React에 추가하는 PR을 하고 싶습니다. "exports" 필드의 추가가 주요 변경 사항이 아님을 확인합니다(저는 이것을 쉽게 결정할 수 있도록 npx ls-exports 도구를 작성했습니다). 빌드 프로세스 없이 ESM을 사용하려는 사람들에게는 도움이 되지 않지만 개별 패키지가 어쨌든 해결할 수 없는 문제입니다.

@gaearon 유용할까요? 그것은 semver-minor로 React 16에 착륙할 수 있습니다.

CJS 빌드는 지금과 같이 환경 감지를 계속 사용하므로 ESM의 (어려운, 해결되지 않은) 문제를 아직 파악할 필요가 없습니다.

그러나 제 생각에는 React 16에서 ESM 빌드를 만든 다음 향후 주요 버전에서 내보내기 기본값을 제거할 수 있다는 것입니다.

또 다른 문제는 구성 수를 늘리면 생태계에 부담이 된다는 것입니다. 예를 들어 ESM 빌드를 출시하면 기본 내보내기와 같이 바로 다음 릴리스에서 확실히 제거할 항목이 포함되어서는 안 된다고 생각합니다. 다시 말해, 사라지는 것(기본 내보내기)을 새로 추가되는 것(ESM 빌드)에 도입하는 것은 의미가 없다고 생각합니다.

그러나 제 생각에는 React 16에서 ESM 빌드를 만든 다음 향후 주요 버전에서 내보내기 기본값을 제거할 수 있다는 것입니다.

또 다른 문제는 구성 수를 늘리면 생태계에 부담이 된다는 것입니다. 예를 들어 ESM 빌드를 출시하면 기본 내보내기와 같이 바로 다음 릴리스에서 확실히 제거할 항목이 포함되어서는 안 된다고 생각합니다. 다시 말해, 사라지는 것(기본 내보내기)을 새로 추가되는 것(ESM 빌드)에 도입하는 것은 의미가 없다고 생각합니다.

나는 그것이 다음 릴리스가 얼마나 오래 되는지에 달려 있다고 생각합니다. 우리가 일주일의 차이에 대해 이야기한다면 그것은 합리적으로 보입니다. 그러나 우리가 몇 개월 / 몇 년을 이야기한다면 그 시간 동안 그것을 꺼내는 것이 왜 나쁜지 알 수 없습니다.

이 경우의 우려는 그것이 더 오래 존재할수록 더 많은 사람들이 현재 형태로 그것에 의존한다는 것입니다. 그런 다음 거기에 주요 변경 사항을 도입하면 React를 업그레이드하기가 더 어려워집니다. 이제 하나의 ESM 마이그레이션이 아니라 여러 개 있으며 일부 사람들은 너무 일찍 뛰어들어 나중에 다른 마이그레이션을 위한 리소스가 없기 때문에 뒤처지게 될 것입니다. ESM의 경우 생태계 전반에 걸쳐 파급력이 발생합니다.

ESM 빌드를 출시하면 기본 내보내기와 같이 바로 다음 릴리스에서 확실히 제거할 항목이 포함되어서는 안 된다고 생각합니다. 다시 말해, 사라지는 것(기본 내보내기)을 새로 추가되는 것(ESM 빌드)에 도입하는 것은 의미가 없다고 생각합니다.

나는 import React from 'react' 를 새로 추가된 것으로 보지 않고 오히려 현재의 현실을 수용한다. 이것은 아마도 의도하지 않았고 지금은 사용되지 않는 ESM/CJS 상호 운용성의 부작용일 뿐이지만 여전히 이를 수행하는 수천(백만?) 줄의 코드가 있습니다. 대안(명명된 내보내기만 내보내기)은 사용자에게 "우리는 마이너 버전으로 ESM 빌드를 게시했지만 모든 코드를 변경하지 않고는 사용할 수 없습니다"라고 말합니다. 이는 "제거된 기본 내보내기"를 보는 것보다 사용자에게 더 혼란스럽습니다. 주요 버전의 릴리스 정보에서.

궁금합니다. 기본 내보내기가 있는 ESM을 이전 버전과 호환되는 방식으로 추가하려면 어떻게 해야 합니까? 이것은 이전에 나타났습니다(예: https://github.com/facebook/react/pull/18187 또한 관련 문제로 연결됨). 문제는와 웹팩 CJS <-> 당신이하고 CJS 코드가있는 경우 ESM의 상호 운용성 require('react') 웹팩은 ESM의 존재 반환 무슨 react 기본 내보내기와 객체입니다 default CJS react 관계없이 default 속성(이제 require('react').default 가 필요함을 의미). 하지만 명명된 내보내기도 하면 문제가 되지 않을까요? @TrySound 는 이전에 다른 패키지에서 이러한 문제를

하지만 명명된 내보내기도 하면 문제가 되지 않을까요?

예, 이것이 제가 생각하는 접근 방식입니다. https://unpkg.com/browse/@esm-bundle/react @16.13.1/esm/react.development.js의 마지막 40줄을

하지만 명명된 내보내기도 하면 문제가 되지 않을까요?

예, 이것이 제가 생각하는 접근 방식입니다. https://unpkg.com/browse/@esm-bundle/react @16.13.1/esm/react.development.js의 마지막 40줄을

그러나 CJS 코드 또는 ESM에서 사용하고 있습니까? CJS <-> ESM interop 문제가 매우 놀랍기 때문입니다.

@gaearon 맑음; 내가 제안하는 ESM 래퍼에 기본 내보내기가 없는 것이 합리적입니다. 기본 ESM을 수행하는 모든 사용자는 이를 해결하기 위해 import * as React from 'react' 를 수행합니다. 그러나 지금 그렇게 하는 사람이 갑자기 기본 내보내기가 없는 주요 변경 사항으로 볼 수 있으므로 지금 기본값을 추가하지 않으려면 v17까지 기다려야 합니다.

그러나 CJS 코드 또는 ESM에서 사용하고 있습니까? CJS <-> ESM interop 문제가 매우 놀랍기 때문입니다.

CJS 및 ESM 파일 모두에서 webpack으로 성공적으로 가져왔습니다.

네이티브 ESM을 수행하는 사람은 *를 'react'에서 React로 가져오기를 수행하여 이 문제를 해결합니다. 그러나 지금 그렇게 하는 사람이 갑자기 기본 내보내기가 없는 주요 변경 사항으로 볼 수 있으므로 지금 기본값을 추가하지 않으려면 v17까지 기다려야 합니다.

동의. 처음부터 시작하는 경우 기본 내보내기가 필요하지 않습니다. 그러나 기본 내보내기를 추가하지 않고는 주요 변경 사항 없이 2단계 를 구현할 수 없습니다. 저는 개인적으로 React 16에서 Phase 1을 수행하고 React 17+에서 Phase 2-4를 수행하는 것이 좋지만 Phase 1, 2, 심지어 3까지 수행하는 것을 선호합니다(@ljharb 의 내보내기 검사기 도구의 도움으로) 변경 사항을 깨뜨리지 않고 React 16에서. 그 이유는 2단계가 대부분의 사용자가 ESM 번들을 사용하기 시작하는 큰 단계인 반면, 1단계는 대부분 얼리 어답터/매니아를 위한 것이기 때문입니다.

이 제안 에서 계속됩니다. 이것은 상태를 다른 곳으로 격리하여 이중 패키지 위험을 처리하는 완전한 CJS 및 ESM 소스가 있는 이중 패키지로의 전환에 대한 제안인 것 같습니다( 접근법 2 ). 이전 RFC( 접근법 1 )와 같은 ESM 래퍼를 사용하는 것과는 대조적입니다.

가정하면 아직 언급되지 않은 몇 가지 메모가 있습니다.

• ESM 및 CommonJS 파일이 모두 .js 사용하는 Node.js 패키지를 가질 수 없습니다. "type": "module" 를 설정하면 모든 CommonJS 파일은 대신 .cjs 파일 확장자를 사용해야 합니다.
• 국가 및 평등 이중 패키지 위험은 CJS와 ESM이 모두 있는 유일한 문제가 아닙니다. 잠재적으로 동일한 패키지의 2개 버전을 로드하면 이러한 경우 React의 메모리 공간도 증가하며 React는 작은 라이브러리가 아닙니다. 이것은 거래 차단기가 아니지만 명심할 가치가 있습니다.
• React의 내부 상태 외에 이중 패키지 위험 가능성이 있다고 봅니다. 예를 들어 Component 클래스의 구현이 상태를 공유하는 CJS 코드의 일부가 아니고 대신 CJS/ESM 번들의 일부인 경우 다양한 라이브러리에서 instanceof Component 검사의 위험이 있습니다. 파괴.

ESM 및 CommonJS 파일이 모두 .js를 사용하는 Node.js 패키지를 가질 수 없습니다. "type": "module"을 설정하면 모든 CommonJS 파일은 대신 .cjs 파일 확장자를 사용해야 합니다.

에있는 파일 NodeJS에 대한 (하지만 bundlers 위해) 때문에,이 사실이다 cjs 디렉토리로 종료해야합니다 .cjs .

잠재적으로 동일한 패키지의 2개 버전을 로드하면 이러한 경우 React의 메모리 공간도 증가합니다.

이것이 어떻게 npm에 게시된 tarball 크기를 증가시켜 디스크의 전체 크기를 증가시키는지 알 수 있습니다. 그러나 이것이 메모리에 어떤 영향을 미치는지 모르겠습니다. 내가 아는 한, 번들러와 NodeJS는 import / require() 를 통해 로드되지 않은 코드를 메모리로 가져오지 않습니다. 메모리 풋프린트가 어떻게 변경되는지 명확히 해주실 수 있습니까?

예를 들어 Component 클래스의 구현이 상태를 공유하는 CJS 코드의 일부가 아니고 대신 CJS/ESM 번들의 일부인 경우 다양한 라이브러리에서 instanceof Component 검사가 중단될 위험이 있습니다.

제안된 솔루션( 1 , 2 ) 중 하나는 NodeJS esm 구현이 CJS 코드를 호출하는 ESM 인터페이스가 되도록 하는 것입니다. 그렇게 하면 Node.js에서 사용되는 Component 정의가 하나만 있습니다. 1단계와 2단계는 NodeJS에서 실행되는 항목을 변경하지 않으므로 이는 3단계에만 적용됩니다.

최근에 우리(webpack)가 webpack 5에 exports 필드 지원을 추가했기 때문에 이 주제에 2센트를 주고 싶습니다.

• 이 WIP(work-in-process) 문서에는 webpack에 관한 exports 필드뿐 아니라 Node.js 및 일반적으로 https://gist.github.com/sokra/e032a0f17c1721c71cfced6f14516c62에 대한 많은 정보가
• 다음은 Node.js와 비교한 핵심 사항입니다.
  
  
  
  • webpack 5에는 development 및 production 조건도 추가되어 반응에 매우 유용합니다. ( process.env.NODE_ENV 는 계속 지원되지만 일반적으로 Node.js에 따라 달라지는 프런트엔드 코드에서는 피해야 합니다.)
  
  
  • webpack(및 기타 번들러)은 require("esm") 지원하므로 항상 ESM을 사용하여 이중 상태 문제를 피할 수 있습니다( require() ). webpack은 이에 대한 특별한 조건을 도입했습니다: module . 이 CommonJs 및 ESM 버전의 경우 동일한 인터페이스를 내보내야 합니다. 현재 Node.js만큼 이중 상태 문제가 있는 것은 없습니다. 나는 이것이 대부분 이전 버전과의 호환성 문제이기 때문에 미래에 무언가를 보게 될 것이라고 기대하지 않습니다.
    
    최대한의 호환성을 위해 다음을 권장합니다.
  
  

패키지.json

{
    "type": "commonjs",
    "main": "index.js",
    "module": "esm/wrapper.js",
    "exports": {
        ".": {
            "node": {
                "development": {
                    "module": "./esm/index.development.js",
                    "import": "./esm/wrapper.development.js",
                    "require": "./cjs/index.development.js"
                },
                "production": {
                    "module": "./esm/index.production.min.js",
                    "import": "./esm/wrapper.production.min.js",
                    "require": "./cjs/index.production.min.js"
                },
                "import": "./esm/wrapper.js",
                "default": "./cjs/index.js"
            },
            "development": "./esm/index.development.js",
            "production": "./esm/index.production.min.js",
            "default": "./esm/index.production.min.js"
        },
        "./index": "./index.js",
        "./index.js": "./index.js",
        "./umd/react.development": "./umd/react.development.js",
        "./umd/react.development.js": "./umd/react.development.js",
        "./umd/react.production.min": "./umd/react.production.min.js",
        "./umd/react.production.min.js": "./umd/react.production.min.js",
        "./umd/react.profiling.min": "./umd/react.profiling.min.js",
        "./umd/react.profiling.min.js": "./umd/react.profiling.min.js",
        "./package.json": "./package.json"
    }
}

esm/패키지.json

이 디렉토리에서 .js 를 확장자로 사용할 수 있습니다. 또는 .mjs 사용할 수 있지만 도구에서 확장을 확인할 때 잠재적인 부작용이 있을 수 있습니다. 따라서 .js 는 안전합니다.

{
    "type": "module"
}

esm/wrapper.js

이 래퍼는 Node.js가 이중 상태 문제를 피하기 위해 필요합니다.

import React from "../cjs/index.js";
export const {
    Children,
    Component,
    ...,
    useState,
    version
} = React;
export { React as default };

cjs/index.js

development 및 production 조건이 지원되지 않을 때 Node.js에서 사용합니다.

'use strict';

if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

esm/wrapper.development.js (esm/wrapper.production.min.js 유사)

이러한 래퍼는 이중 상태 문제를 피하기 위해 Node.js에 필요합니다.
Node.js가 development 및 production 조건을 추가한 경우에만 사용됩니다.

import React from "../cjs/index.development.js";
export const {
    Children,
    Component,
    ...,
    useState,
    version
} = React;
export { React as default };

index.js

이전 버전과의 호환성을 위해.

module.exports = require('./cjs/index.js');

esm/index.development.js, esm/index.production.min.js

이것은 exports 필드, module 조건 및 production / development 조건을 지원하는 도구에서 사용됩니다.

/* React in ESM format */

// compat for the default exports with support for tree-shaking
import * as self from "./esm/index.development.js";
export { self as default }

결과

• 웹팩 5: ./esm/index.development.js 또는 ./esm/index.production.min.js
• 브라우저화: ./cjs/index.js
• .mjs의 웹팩 4: ./cjs/index.js
• 다른 번들러: ./esm/wrapper.js
• Node.js(ESM): ./cjs/index.js (필수) 또는 ./esm/wrapper.js (가져오기)
• Node.js(이전): ./cjs/index.js
• Node.js를 (ESM + DEV / 자극) : ./esm/wrapper.development.js 또는 ./esm/wrapper.production.min.js 수입, ./cjs/index.development.js 또는 ./cjs/index.production.min.js 에 필요한

노트

조건부로 버전을 선택하는 것은 주요 절충 없이 ESM에서 불가능하기 때문에 esm/index.js 는 없습니다.
도구는 exports 필드, module 조건(이중 상태 문제 때문에) 및 production / development 를 지원하는 경우에만 반응 ESM의 이점을 충분히 누릴 수 있습니다

도구는 module 필드 또는 exports 필드를 지원할 때 반응 ESM의 이점을 부분적으로 사용할 수 있습니다.

import { useState } from "react" 또는 import * as React from "react" 는 long react가 CommonJs 모듈인 한 기술적으로 불법입니다.
대부분의 도구는 여전히 이전 버전과의 호환성을 지원하지만 일부는 지원하지 않습니다(예: Node.js).
따라서 현재 모든 곳에서 유효한 react를 사용하는 유일한 방법은 import React from "react" 입니다.
이 방법은 계속 지원되어야 합니다. 그렇지 않으면 지금 반응하고 ESM 추가 후 반응에 유효한 구문이 없는 경우(예: Node.js 14)가 있습니다.

Node.js를가 첨가 거부 development / production 대한 조건 exports 지금있다.
그것은 슬프고, 나는 여전히 그들이 결국 그것을 추가하기를 바랍니다.
그렇기 때문에 위의 exports 필드에 이에 대한 지원이 준비되어 있습니다.

@sokra 훌륭한 분석, 매우 도움이 되었습니다. 감사합니다!

작은 질문 하나:

Node.js는 현재 내보내기를 위한 개발/생산 조건 추가를 거부했습니다.

내 이해는 그것이 아직 작업 중이라는 것입니까? https://github.com/nodejs/node/pull/33171 하지만 아마도 내가 그 PR을 오해하고 있는 것 같습니다

[편집] 내가 링크한 위의 PR은 https://github.com/nodejs/node/pull/34637 로 대체되었습니다.

[edit2] 이제 nodejs에 병합되었습니다.

@sokra 감사합니다. 매우 유용한 제안입니다.

내가 보는 옵션은 다음과 같습니다. 모두 기술적으로 가능하고 결정은 기술 구현보다 전략 중 하나인 것 같습니다.

옵션 1

export default React 를 React 17 ESM 빌드에 추가하고 import React from 'react' 대한 CJS 지원이 중단되면 제거합니다(아마도 React 18에서?).

옵션 2

export default React 추가하지 말고 명명된 내보내기만 있는 React 17 ESM 빌드를 생성하세요.

옵션 3

React 17 ESM 빌드를 게시하지 마십시오. (😢) ESM 빌드를 생성하기 전에 import React from 'react'; 지원이 중단될 때까지 기다리세요.

비교

| | 옵션 1 | 옵션 2 | 옵션 3 |
| - | -------- | -------- | -------- |
| 참조되지 않은 ESM 빌드 | v17 | v17 | v18+ |
| package.json "module"(기본적으로 트리 흔들기) | v17 | v18+ | v18+ |
| package.json "유형" / "내보내기"(NodeJS는 ESM 사용) | v18+ ¹ | v18+ | v18+ |

1. 완전히 이전 버전과 호환되는 방식으로 package.json 유형/내보내기를 구현하는 것이 가능할 수 있습니다. 이 경우 옵션 1이 선택되면 React 17의 일부가 될 수 있습니다.

위에서 설명한 것처럼 내 선호도는 옵션 1입니다. 그러나 옵션 2도 나에게 매우 흥미진진합니다. 옵션 3은 물론 덜 흥미롭습니다. 이 github 문제에서 수집한 것에서 우리는 이러한 일을 가능하게 하는 기술적 전문 지식을 갖추고 있습니다(아마도 노동력까지!).

이 문제에 대한 초기 반응은 "이 문제가 3년이 지난 후에도 공개되는 이유는 무엇입니까?"였습니다. 일부를 읽고 나면 왜 그렇게 오래 걸리는지 이해가 됩니다. React와 같은 라이브러리를 유지 관리하는 것은 엄청난 작업입니다. 그래서 🙇🏻

React 17에 대한 최근 뉴스를 고려하여 향후 계획에 대해 React 16 대신 React 17을 참조하도록 이전 의견을 업데이트했습니다.

위의 세 가지 옵션 중 어느 것이 선호되는지에 대한 의견을 보내주시면 감사하겠습니다.

React 17의 package.json 에 exports 필드를 추가할 수 있다고 생각합니다. 이전 버전으로도 백포트할 수 있습니다.

{
  "exports": {
    ".": {
      "development": "./esm/react.development.mjs",
      "production": "./esm/react.production.mjs",
      "node": {
        "import": "./esm/react.node.mjs",
        "require": "./index.js"
      },
      "default": "./index.js"
    },
    "./jsx-dev-runtime": {
      "development": "./esm/react-jsx-dev-runtime.development.mjs",
      "production": "./esm/react-jsx-dev-runtime.production.mjs",
      "node": {
        "import": "./esm/react-jsx-dev-runtime.node.mjs",
        "require": "./jsx-dev-runtime.js"
      },
      "default": "./jsx-dev-runtime.js"
    },
    "./jsx-runtime": {
      "development": "./esm/react-jsx-runtime.development.mjs",
      "production": "./esm/react-jsx-runtime.production.mjs",
      "node": {
        "import": "./esm/react-jsx-runtime.node.mjs",
        "require": "./jsx-runtime.js"
      },
      "default": "./jsx-runtime.js"
    },
    "./": "./"
  },
}

새로운 esm 번들이 필요하지만 롤업으로 추가하는 것이 그리 어렵지 않아야 합니다.

• ./esm/react.development.mjs 및 ./esm/react.production.mjs 번들은 process.env.NODE_ENV 수표가 없어야 합니다.
  
  
  
  • 조건은 exports 필드를 통해 가져오기/번들 시간에 해결됩니다.
  
  
  • process 는 노드 API이며 브라우저 환경에서 의미가 없으며 예를 들어 webpack 5에서 _default_에서 지원하지 않습니다.
  
  
• ./esm/react.node.mjs 는 process.env.NODE_ENV 수표를 유지합니다.
  
  
  
  • 노드 측에 큰 번들을 갖는 것이 중요한지 모르겠습니다.
  
  
  • 사용자는 --conditions CLI 플래그를 통해 dev/prod 번들에 계속 옵트인할 수 있습니다.
  
  
  • https://nodejs.org/dist/latest-v15.x/docs/api/packages.html#packages_resolving_user_conditions
  
  
• AFAIK 전용 webpack 5 및 노드는 현재 exports 필드를 지원합니다.
  
  
  
  • 롤업 측면에서도 이를 지원하는 데 관심이 있습니다: https://github.com/rollup/plugins/issues/362
  
  

나는 이것이 WDYT를 추가하는 것이 오히려 안전하다고 생각합니다.

https://webpack.js.org/guides/package-exports/
https://nodejs.org/dist/latest-v15.x/docs/api/packages.html

"./": "./" 는 안전하지만 캡슐화도 방지하므로 semver-major가 있는 즉시 제거하고 싶을 것입니다.

FWIW babel은 새로운 jsx 런타임 가져오기를 다음과 같이 출력합니다.

import { jsxs, jsx, Fragment } from 'react/jsx-runtime';

그러나 Node에서 이와 같은 모듈을 로드하면 파일 확장자가 없다고 불평할 것입니다.

> node .\node.mjs
node:internal/process/esm_loader:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'test\node_modules\react\jsx-runtime' imported from test\node_modules\react-data-grid\lib\bundle.js
Did you mean to import react/jsx-runtime.js?
    at new NodeError (node:internal/errors:259:15)
    at finalizeResolution (node:internal/modules/esm/resolve:307:11)
    at moduleResolve (node:internal/modules/esm/resolve:742:10)
    at Loader.defaultResolve [as _resolve] (node:internal/modules/esm/resolve:853:11)
    at Loader.resolve (node:internal/modules/esm/loader:85:40)
    at Loader.getModuleJob (node:internal/modules/esm/loader:229:28)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:51:40)
    at link (node:internal/modules/esm/module_job:50:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

exports 추가하면 해결됩니다 🤔

@nstepien이 이전 게시물에서 보여주듯이 전체 exports 지도를 제공하는 것은 제가 생각하는 옵션이 아닙니다. cjs interop과 관련하여 구현하는 노드는 기존 생태계와 잘 어울리지 않습니다. 이중 패키지 위험은 현실적입니다. 특히 단일 사본이 필요한 Reac과 같은 패키지의 경우 그렇습니다.

commonjs 전용 파일이 포함된 exports 맵은 잠재적으로 아무 것도 손상시키지 않고 추가할 수 있지만 이에 대한 적절한 e2e 테스트를 통해 각별히 주의해서 수행해야 합니다.

@Andarist 그것은 잘 작동하고 반응의 경우에도 다르지 않습니다. 항상 그 위험이 있었고 생태계는 반응을 모든 곳에서 피어 뎁으로 만들어 이를 해결합니다. ESM 파일과 CJS 파일이 동일한 상태를 공유하는 한 "내보내기" 맵은 여기에서 제대로 작동할 수 있습니다. 이는 간단한 ESM 래퍼를 작성하여 달성할 수 있습니다.

전이적이든 아니든 React의 모든 종속성이 React(이 경우에는 있음)의 제어 하에 있고 모든 ESM 진입점이 CJS 콘텐츠를 다시 내보내는 경우 이 특정 경우에 달성할 수 있습니다.

ESM 항목의 실제 모양이 어떠해야 하는지에 대한 전체 드라마가 여전히 있습니다(이름 지정, 기본값, 둘 다).

• Named-only: 많은 코드가 import React from 'react' 사용하고 있기 때문에 실제로는 이전 버전과 호환되지 않습니다. 이는 ESM을 사용할 때 노드에서 실제로 React를 가져올 수 있는 유일한 방법이기도 합니다.
• default-only: 많은 코드가 import * as React from 'react' 사용하기 때문에 실제로 이전 버전과 호환되지 않습니다. 이것은 종종 유형 검사기 및 기타 도구에 의해 승격되었습니다.
• 둘 다: 완전히 이전 버전과 호환되도록 하는 유일한 방법이므로 모든 현재 로드 스타일과 종속성 트리에서 ESM 및 CJS 모듈을 혼합할 때 작동할 수 있습니다.

나는 속임수처럼 느껴지기 때문에 ESM 래퍼의 가능성을 끊임없이 잊어 버립니다. 그러나 이 기술은 모든 종속성을 제어할 때만 작동하고 실제로 "그냥 작동하는" 보편적인 전략으로 사용할 수 없기 때문입니다 😢

두 가지 모두를 제공하는 유일한 보편적인 전략은 사실 모든 실제 코드를 CJS로 만들고 그 주위에 ESM 래퍼를 작성하여 명명된 내보내기를 제공하는 것뿐입니다. 상태 저장이 아니거나 ID에 의존하는 코드는 기본적으로 둘 다에 작성 될 수 있지만 이는 하위 집합에 불과합니다.

jsx-runtime 는 스테이트풀(Stateful)이 아닌가요? 래퍼 없이 esm/cjs를 모두 배송하는 것이 안전해야 합니다.

esm 노드에서 react/jsx-runtime 가져오기에 대해 별도의 문제를 기록해야 합니까?

프론트엔드 패키지의 경우 추가 문제가 이중 상태 위험에 합류합니다. 이를 이중 번들 위험이라고 부르겠습니다.

ESM 및 CJS 버전을 내보내고 require 및 import 를 통해 패키지를 사용하는 경우 두 버전이 모두 번들로 제공되고 패키지의 유효 번들 크기가 두 배가 됩니다.

@sokra 실제로 가능합니까? 예를 들어 롤업을 사용하면 cjs 모듈이 esm 모듈로 변환되므로 사용 가능할 때마다 esm 모듈을 가져오는 것을 선호한다고 가정합니다.

실제로는 webpack 5와 같은 노드 의미 체계를 따르는 번들러에 대해 가능합니다. 그렇지 않으면 노드에서 실행할 때와 번들 코드를 실행할 때 잠재적으로 다른 결과를 경험할 수 있기 때문에 의미 체계를 일치시키는 것이 중요합니다.

그러나 webpack 5는 esm/cjs(export 맵에서 오는 것)를 중복 제거하는 데 사용되는 특별한 "module" 조건을 처리합니다.

@ljharb의 제안을 고려하면 이것은 esm 파일이 cjs 파일을 다시 내보내는 몇 줄의 래퍼 코드일 수 있다고 제안했기 때문에 실제로 관련이 없습니다.

얇은 ESM 래퍼를 사용하면 번들러가 있든 없든 추가 위험이 없습니다. 그래프의 속임수에 대해 피어 dep가 피하는 일반적인 위험뿐입니다.