React: トップレベルのESエクスポートを形式化する

Imho import *は行く方法です、Imはデフォルトのエクスポートも反対していませんが、この例のように他のものを再エクスポートするために使用するべきではありません：

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

ただし、次の例のように、他のものを再エクスポートするために使用しないでください。

技術的な理由はありますか？ （同じことをする2つの方法があることを除いて。）

私の印象では、 *をインポートする（そしてデフォルトを使用しない）人は、デフォルトが未使用のままになるため、ツリーの揺れに問題はありません。 しかし、多分私はロールアップなどを過大評価しています。

その質問には、おそらく@lukastaegertが最もよく答えることができます。 https://github.com/facebook/react/issues/10021#issuecomment-335128611以降に何かが変更されたかどうかわからない

また、ロールアップだけがツリーシェーカーではありません。webpackのツリーシェーキングアルゴリズムはロールアップのアルゴリズムよりも劣りますが、その使用量はおそらくロールアップよりもはるかに高くなります（どちらのツールも優れた仕事をします。私は誰も怒らせたくありません） 、事実を述べるだけです）そして（コミュニティとして）両方のツールを一度に支援できるのであれば、できる限り支援する必要があります。

すべてが単一のフラットバンドルに前処理されているとすると、Reactの場合、ツリーシェイクは何かを_実行_しますか？ Reactの主なインポートスタイルは何ですか？個人的にはデフォルトのエクスポートのように扱う傾向があります（例： React.Component 、 React.Childrenが、時々 cloneElement名前付きのものを実行します

@gaearonがすでに他の場所で述べているように、reactの場合のサイズの改善は最小限であると予想されます。 それにもかかわらず、いくつかの利点があります。

• React.Childrenはおそらく場合によっては削除される可能性があります（だから私は聞いた😉）
• React自体は、これをサポートするモジュールバンドラーによってトップスコープに引き上げることができます。 これにより、かなりの数のバイトが削除される可能性があり、パフォーマンスがわずかに向上する可能性もあります。 主な改善点は、すべてのモジュールに対してReact.Componentを参照する別の変数は必要なく、どこでも共有される変数が1つだけであるという事実にあります（これは通常、ロールアップが行う方法です）。 また、これは私が推測していることですが、これにより、webpackのModuleConcatenationPluginがベイルアウトする可能性が低くなる可能性があります
• 反応の静的分析は、モジュールバンドラーだけでなく、IDEやその他のツールなどでも簡単です。 そのようなツールの多くは、CJSモジュールに対してすでにこれで妥当な仕事をしていますが、結局、それらの側には多くの推測が含まれています。 ES6モジュールを使用すると、分析は簡単です。

エクスポートの種類に関しては、もちろん、名前付きのエクスポートだけが、簡単なツリーシェイクの利点を実際に提供します（GCCを使用しない限り、GCCを使用すると、積極的な動きでもう少し実行できる可能性があり、運が良ければ最新のロールアップが可能になる可能性があります） 。 デフォルトのエクスポートも提供するかどうかの質問は、決定するのがより困難です。

• PRO：既存のES6コードベースの痛みのない移行（例： @jquenseの説明）
• CON：すべてが共通のオブジェクトにアタッチされているため、このオブジェクトが含まれると、そのすべてのキーが一度に含まれ、ツリーシェイクの試みが再び無効になります。 GCCでさえここで苦労するかもしれません。

2バージョンの移行戦略として、非推奨と宣言された互換性の目的で次のバージョンにデフォルトのエクスポートを追加し（ゲッターなどを介して警告を表示する場合もあります）、それ以降のバージョンで削除することができます。

これも興味深いケースです： https ：

このツイッターの会話でここに来ました。 私にとって、この質問に対する明確な正解があります。ReactとReactDOMは、名前付きのエクスポートComponent 、 createElementを「置く」場所としてです。

（それはまた、バンドラーの生活を楽にしますが、それはここにもそこにもありません。）

もちろん、これは現在デフォルトのインポートとトランスパイルを使用している人々に重大な変更をもたらします。 @lukastaegertはおそらくここで正しい考えを持っており、アクセサを使用して非推奨の警告を出力します。 これらはバージョン17で削除される可能性がありますか？

ただし、＃11526の既成の提案はありません。 おそらく、ESMの出荷はその理由でv17を待つ必要があります。その場合、非推奨の警告について心配する必要はありません。

人々は本当に好きになりました

import React, { Component } from 'react'

だから彼らにそれをあきらめるように説得するのは難しいかもしれません。

少し奇妙だとしても、これはそれほど悪くはないと思います。

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

明確にするために、我々は必要React JSXはにtranspilesので（この場合は、名前空間として）の範囲にあることがReact.createElement() 。 JSXを壊して、代わりにグローバルjsx()関数に依存していると言うことができます。 その場合、インポートは次のようになります。

import {jsx, Component} from 'react';

これはおそらく大丈夫ですが、大きな変化です。 これは、React UMDビルドでもwindow.jsxを設定する必要があることも意味します。

jsx代わりにcreateElement jsxを提案するのはなぜですか？ ええと、 createElementはすでにオーバーロードされており（ document.createElement ）、 React.修飾子で問題ありませんが、グローバルでそれが多すぎると主張することはありません。 Tbh私はこれらのオプションのどちらにもあまり興奮しておらず、これがおそらく最良の中間点になると思います。

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

JSXはデフォルトでReact.createElementトランスパイルし続けます。

告白：JSXを使用するためにReactを明示的にインポートする必要があるのは、実際にはどこでもその識別子を使用していなくても、いつも少し奇妙だと思いました。 おそらく将来、トランスパイラーは、JSXがまだ存在しない場合、JSXに遭遇したときにimport * as React from 'react' （Preactなどのために構成可能）を挿入する可能性がありますか？ そうすれば、これを行うだけで済みます...

import { Component } from 'react';

...そして名前空間のインポートは自動的に処理されます。

遠い将来、多分。 今のところ、トランスパイラーが他のモジュールシステム（CommonJSまたはグローバル）で動作することを確認する必要があります。 これを構成可能にすることもハードルであり、コミュニティをさらに分割します。

@ Rich-Harrisが提案したこと（jsxが使用されているときに特定のインポートを挿入すること）は、transpilersプラグインによって簡単に実行できます。 コミュニティはbabel-plugin-transform-react-jsxをアップグレードする必要があり、それだけです。 そしてもちろん、ファイルにimport * as React from 'react';を追加するのが1つだけであれば、既存のセットアップでも機能します。

もちろん、他のモジュールシステムを検討する必要がありますが、解決するのは難しい問題ではないようです。 特定の落とし穴を念頭に置いていますか？

もちろん、他のモジュールシステムを検討する必要がありますが、解決するのは難しい問題ではないようです。 特定の落とし穴を念頭に置いていますか？

わかりませんが、それをどのように処理するかについてのあなたの具体的な提案は何ですか？ Babel JSXプラグインのデフォルトは何ですか？

人々は本当に好きになりました

import React, { Component } from 'react'

どのような人々？ 私があなたをあざけるために出て来なさい。

私はそれをたくさんしました🙂私は他の場所でもこれを見たことがあると確信しています。

デフォルトは現時点ではReact.createElement 、ほとんど同じです。 唯一の問題は、現在グローバルを想定している（またはスコープですでに使用可能になっている）ことです。

esモジュールは基本的に（まだすべてに採用されているわけではありませんが）モジュールを実行する標準的な方法であるため、大多数がそれを使用する（または使用する必要がある）と想定するのが妥当だと思います。 大多数はすでにさまざまなビルドステップツールを使用してバンドルを作成しています。当てはまります。 jsxプラグインのデフォルトの動作をスコープへのReact.createElement自動挿入に変更することは、合理的な方法です。 私たちはこの変更に最適な時期にあり、 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以外のツールを支援するために避ける必要があります。 また、私にとっては、これを回避する方が意味的に優れています。このような場合にlibsが実際に行うことは、名前空間を提供することであり、 import * as Namespace from 'namespace'を使用するとより適切に表現されます。

uglify-esは現在安定していると見なされていますか？

JSエコシステムの他の何よりも安定しています。 週に50万回以上のダウンロード。

ロールアップの世界ではこれですべてですが、Reactは主にアプリにバンドルされており、デフォルトではスコープの引き上げを行わないWebpackを主に使用していることを考えると

とにかく、それはオプションです。 とにかくWebpackのデフォルトは理想的ではありません-ご存知のようにModuleConcatenationPluginを使用する必要があります。

ここに数セントを追加します：

• 私は@ Rich-Harrisに完全に同意します。意味的には、名前付きエクスポートが正しい選択です。
• JSX構文を使用できるようにするためだけに、 import React from 'react'またはimport * as React from 'react'どちらも本当に好きではありません。 私の目には、この設計は、 createElement部分を使用できるようにするためだけに、ユーザーにReactのすべてをインポートするように強制するという点で、インターフェイス分離の原則に明らかに違反しています（ただし、名前空間のエクスポートでは、Rollupのようなバンドラーは不要なエクスポートを再度削除します）

したがって、重大な変更を決定する可能性がある場合は、JSXが単一の（グローバルまたはインポートされた）関数に依存するようにこれを変更することをお勧めします。 私はそれをcreateJSXElement()と呼んでいたでしょうが、これは私の意見ではcreateElement()よりもさらに優れており、意味をなすためにReactコンテキストを必要としなくなりました。 しかし、すべてのバイトが重要な世界では、 jsx()もおそらく問題ありません。

これはまた、他のライブラリが同じ変換を使用し、異なるjsx関数を提供することによって、JSXをサポートすることを選択できるように、最終的にJSXをReactから切り離します。 もちろん、ここではそのような変換を通じて無数の確立されたアプリケーションを導く多くの責任がありますが、アーキテクチャの観点から、これはReactとJSXが向かうべきところだと思います。 Babelを使用してこのような変換を大幅に強化することは、私にとって素晴らしいアイデアのように思えます。

個人的には、 jsxヘルパーに移行してもあまりメリットはありません。これは、babelプラグインのデフォルトのIMHOがreactパッケージからインポートする必要があるため、実際のヘルパーの名前は実際にはそうではないためです。問題-残りは、構成可能にすることだけです。

これはおそらくメインの議論に少し接していますが、ESモジュールがprocess.env.NODE_ENVをチェックしてdev / prodバンドルを条件付きでエクスポートするのにどれだけうまく機能するのか興味がありますか？ 例えば、

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

ここで明らかな何かが欠けているかもしれませんが、このパターンをESモジュールに変換する方法を見つけるのに苦労していますか？

@NMinhNguyenESモジュールでは条件付きエクスポートはできません。

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をバンドルする必要はありません-レンダリングパフォーマンス。

同様に、 package.jsonのmoduleフィールドを使用して、ESバンドルをフラットに保ち、Node.jsのパフォーマンスに影響を与えずに、ESMのdev / prodを区別する方法がわかりません。

同様に、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>
  }
}

ここで、transformは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="..."> ）を介してネイティブに使用するためにreactとさまざまなコンポーネントをインポートしたいという状況にあります。

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>タグを介して反応の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インポートを行うのは素晴らしいことです。 これにより、ファイルの分離を維持しながら、ブラウザーでのプロトタイピングが非常に迅速かつ簡単になります。 バンドラーなしで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がこのようなものをサポートしていれば、ツールは必要ありません。 私はブラウザを使用しています。 このようなコードは、最新のブラウザーを想定し、ページのプログレッシブエンハンスメントとしてreactを使用するいくつかの個人的なプロジェクトで出荷できます。 これを素晴らしいものにしているのは、12か月後にコードベースに戻ったときに、多数のツールAPIを変更したり、パッケージマネージャーとしてNPMを使用したりする必要がないことです。 私はブラウザからAPIを使用しているだけで、他には何も使用していません。

FWIW：Reactがこのようなサポートで出荷される場合、ドキュメントでこのようにReactを使用する方法を示し、Reactとそのコンポーネントモデルを、各コンポーネントロジックを分離することで活用<script type="module">使用し、CDN（または独自のローカルコピー）からReactをインポートして、オフにします。」

現在、モバイルバージョンを含む最新のブラウザはすべてESMをサポートしています。 ESMは、将来のモジュールシステムではなく、現在のデファクトスタンダードです。

標準化されたモジュールを提供しないことは、特にデファクトスタンダードのWebライブラリにとって重大な問題であることに注意してください。

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コミュニティで議論されていると思っていたので、決定が明確になることを提案したいと思いました。 ありがとう！

これに関するいくつかの更新を取得したい...

アプリケーションのバンドルにwebpackv4を使用していますが、IDEインテリセンス（WebStorm）は、コードレビューで同僚からimport React from 'react';を変更するように求められているときに、 import * as 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長期的にはそうです。 ただし、最初に、既存のコードを壊さないように、名前付きエクスポートとデフォルトエクスポートの両方があります。

私はここで問題を自分の手に取りました。プロジェクトでバンドラーを使用しておらず、react（Vue、Hyperappなどの他のライブラリで使用できるようにunpkg.comから直接）を使用したかったので、実験として使用しました。 。 これは私が思いついたものであり、派手なものではなく、手作業で編集されたものです。

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

ReactおよびReactDOMの最新バージョンを公開するES6モジュール

READMEで説明されているように、これはほとんどPOCですが、このビルドが着陸するのを待つことができない人にとっては、フック、サスペンス、レイジーなどを含む16.8.3ビルドであり、次のようにして期待どおりに機能します。

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

たぶん、このスレッドの何人かはそれが役に立つと思うでしょう..個人的に私はこのアプローチを使ってビルドステップのないreactスタータープロジェクトを作成してき

@lukejacksonn本番環境でもこのようなソリューションを使用していますが、現在のプロジェクトでは、UMDバージョンのReactおよびReactDOMのトランスフォーマースクリプトであるという意味で、アプローチが異なります。 そして、それはこれらのファイルを別々に出力するので、そこにあるほとんどのコードでは、置き換えがドロップするはずです。 https://github.com/wearespindle/react-ecmascriptに興味があり、unpkghttps ： //unpkg.com/react-ecmascript/からロードすることもでき

@ PM5544ああ、すごい..これは私のものよりもはるかに包括的なソリューションです！ 素晴らしい仕事💯

素晴らしいもの@ PM5544。 いつかそれについてもっと聞きたいです。 たぶん、Xebiaに戻ってゲスト出演？
最近、UNPKGをサポートするオープンソースパッケージをバンドルするためにパックを採用しました。
バンドラーを使用するのではなく、UNPKGから直接依存関係をロードすることに関する良い記事を知っている人はいますか？

私は現在1つ書いていますが、6月のReactNorwayでも講演する予定です。

@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() {}
...

これにより、デフォルトのエクスポートが名前空間オブジェクトであることが静的に分析可能になり、webpack5およびロールアップでこれらの構成のツリーシェイクが可能になります。

import React from "react";

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

ロールアップはそれをとても気に入ってくれるでしょう

私は1。5年間ロールアップギッターチャットに参加していますが、この種の問題は2週間ごとに発生します...

ところで、 @ lukejacksonnは非公式のes-reactフォークで素晴らしい仕事をしました、それを強くお勧めできます。

ところで、 @ lukejacksonnは非公式のes-reactフォークで素晴らしい仕事をしました、それを強くお勧めできます。

なぜ公式FBチームはこれに何もしないのだろうか。

私はまた、これが物事を前進させるためのプレッシャーを生み出すことを望んでいました、そして私は@lukejacksonn自身もそうだったと思います。 しかし、私が理解しているように、彼は実際にReactチームから元のソースからフォークを構築するためのサポートを受けていたので、これには少なくともある程度の関心があるようです。

私もこれを本当に望んでいました。 実際、私はパッケージの作成において反応チームからほとんどサポートを受けていませんでした（@threepointoneからのいくつかの親切な励ましの言葉を除いて）。 最近、ここFormidableの同僚が、プログラムでパッケージを作成するのを手伝ってくれました。これは、reactの新しいバージョンがリリースされるたびに手動で行うよりも改善されていますが、[ネットワーク]タブの出力が大幅に低下するため、それが行われるかどうかはわかりません。まだこのままです。 我々は見るであろう！

もう2020年になりますが、公式FBチームからのアップデートはありますか？ React v17でこれに関連する変更はありますか？

更新されたESモジュールReactNOWが必要な場合は、すでに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はまったくありません—または互換性のあるレガシーパッケージに分離されています。 これはReact17では発生せず、18では発生する可能性は低いですが、React19で試すのはもっともらしいことです。

@pika/reactのESMビルドに代わるものを探している人は、 https：//github.com/esm-bundle/reactとhttps://github.com/esm-bundle/react-domをチェックしてimport React from 'react';は、完全なCDNURLからReactをインポートするように変更されています。 もう1つの違いは、新しいReactバージョンが公開されるたびに、手動の手順なしで新しいバージョンが自動公開されることです。

コードサンドボックスのデモンストレーション： https ： index.html

エコシステムの準備ができていないという考えに異議を唱える人もいます。 私はこれについて完全な文脈を持っていませんが、これが変更を開始するのに良い時期だと思うなら、 https：//github.com/reactjs/rfcs/pull/38を見て、何かを表現していただければ幸いです。それについての懸念。 それは大まかに考えていましたか、それとも別のアプローチを好みますか？

しかし、ここにキッカーがあります。 Reactをインポートする理由は実際にはあまりありません。

TypeScriptを使用している場合があり、当面は継続します。 TSがbabelのこの新しい魔法の振る舞いについて知るまで、開発者はReactを明示的にインポートし続ける必要があり、正しいインポートステートメントが何であるかを知る必要があります。

JSXは内部で正しいインポートを自動的に挿入するため、スコープ内でReactを使用する必要はありません。

s / JSX /新しいbabelreactjsx変換プラグイン/。 JSXはJavaScriptの構文拡張であり、それ自体は何もしません。

TypeScriptを使用している場合があり、当面は継続します。 TSがbabelのこの新しい魔法の振る舞いについて知るまで、開発者はReactを明示的にインポートし続ける必要があり、正しいインポートステートメントが何であるかを知る必要があります。

TypeScriptチームはこの変更を認識しており、 https：//github.com/microsoft/TypeScript/issues/34547で追跡されてい

s / JSX /新しいbabelreactjsx変換プラグイン/

はい、これが私が意味したことです！

reactjs / rfcs＃38に目を通し、懸念を表明していただければ幸いです。 それは大まかに考えていましたか、それとも別のアプローチを好みますか？

RFCの元のテキストの一部は古くなっています。 ESMがで実行するためにNodeJSができます.jsの代わりに、ファイル.mjsあなたが指定したとき、今"type"であなたのpackage.jsonを。 （ドキュメント）。

具体的には、RFCの元のテキストには次のように書かれていますが、これは正しくありません。

ESMコードは.mjsファイル内にある必要があります

@frehnerと次に示します。 名前付き/デフォルトのエクスポートの問題を、ESMバージョンのReactの公開と結び付けていないことに注意してください。 @gaearonは、デフォルトのエクスポートが最終的に

| | フェーズ1 | フェーズ2 | フェーズ3 | フェーズ4 |
| -| -------- | -------- | -------- | ------- |
| ESMが公開されましたか？ | ✔️| ✔️| ✔️| ✔️|
| package.json "module" | ❌| ✔️| ✔️| ✔️|
| WebPACKの/ロールアップ使用ESM ^{1 、 2} | ❌| ✔️| ✔️| ✔️|
| package.json "exports" | ❌| ❌| ✔️| ✔️|
| package.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をロードして、両方のエントリからその状態で変更する方法があります（100％確信が持てません） 2番目のアプローチ）。

また、フェーズ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エクスポートを追加することは、エコシステム内の他のパッケージにとってしばしば重大な変更であったことを私は知っています。 そして、トピックは間違いなく複雑です。 注意すべき点の1つは、必要に応じて、フェーズ3とフェーズ4の順序を入れ替えることができるということです。 各フェーズを実装する人は、webpack、rollup、nodejsなどの多くのバージョンの非常に徹底的なテストを行う必要があると思います。実行する作業が簡単だと言っているのではありません。ここではおそらく移行経路です:)

ソースコードでは、これはすでに当てはまるようですが？ 私の知る限り、ソースコードはすでに名前付きエクスポートとして物事をエクスポートしています。

ああ-そうです、この場合、 export defaultを追加するためのテーブル行があるはずです😂現在ほとんどのバンドラーで機能し、一般的に人気がありますが、 defaultを提供せずに真のESMエントリを追加するとそれらの使用法を破る。

この場合、エクスポートのデフォルトを追加するためのテーブル行が必要です

はい、良い点です。 追加します。 それをやっているPRは「悪いように見える」と思いますが、現在のパブリックインターフェースをそのまま受け入れており、今後も改善していく予定です。

いくつかのバージョンが公開されるとすぐに戻ることはなく、

開発/本番ビルドの分割がどのように処理されるかという問題もあります。 実際、Reactビルドのステートフルな性質を維持することは非常に重要です。

いくつかのバージョンが公開されるとすぐに戻ることはなく、そのバージョンに対するセマンティックの変更は壊れることに注意する必要があります。 メジャーを頻繁にリリースしないことを考えると、チャーンを最小限に抑えるために、変更をバッチ処理する方法を検討する必要があります。

良い点。 私の考えは、React 16で公開されているESMビルドに明示的なexport default Reactを追加することです。PRは、決定された宛先ではないため、眉をひそめ、物議を醸す可能性があると思います。 ただし、私の見解では、React 16でESMをビルドし、将来のメジャーバージョンでexport defaultを削除することができます。 私にとって、 import React from 'react';を介してreactを使用することは非常に一般的であるため、ESMビルドでデフォルトをエクスポートすることは単に「私たちがいる場所を受け入れる」ことです。 将来のメジャーバージョンはそれを削除するでしょう。

また、重大な変更の最小化に関連しています-フェーズ3と4は、同じメジャーリリースの一部である可能性があります。 フェーズ3は、完全な下位互換性のある方法で実行できる可能性があります。その場合、16リリースに侵入する可能性もあります。 しかし、それはトリッキーであり、私はそれについて自信を持って十分に知りません。

開発/本番ビルドの分割がどのように処理されるかという問題もあります。

これは私が見落としていたものです。 バンドラーとNodeJSの両方でESMを使用してこれを行う方法はわかりませんが、何が可能かを調べるためにいくつかの調査を行います。 私はこの死んだ提案を見つけましたが、生きているものを調べます:)

実際、Reactビルドのステートフルな性質を維持することは非常に重要です。

同意しました。 注意すべき点の1つは、Reactビルドのステートフルな性質は、フェーズ1と2ではなく、フェーズ3でのみ解決する必要があるということです。 @ Andaristと私が提案したオプションはそれを解決するために機能します。

今最も簡単な、最も後方互換性のアプローチは、名前の輸入を可能にするための簡単なESMラッパーを追加することです。

これをReactに追加するためのPRを作成して、「exports」フィールドの追加が重大な変更にならないようにしたいと思います（これを簡単に決定できるツールnpx ls-exportsを作成しました）。 ビルドプロセスなしでESMを使おうとする人々には役立ちませんが、それは個々のパッケージがとにかく解決できないという問題です。

@gaearonそれは役に立ちますか？ React16にsemver-minorとして着陸する可能性があります。

CJSビルドは、現在と同様に環境検出を引き続き使用するため、ESMの（ハードで未解決の）問題をまだ把握する必要はありません。

ただし、私の見解では、React 16でESMをビルドし、将来のメジャーバージョンでエクスポートのデフォルトを削除することができます。

もう1つの懸念は、構成の数を増やすとエコシステムに負担がかかることです。 たとえば、ESMビルドをリリースする場合、デフォルトのエクスポートなど、次のリリースで確実に削除するものを含めるべきではないと思います。 言い換えれば、追加されたばかりの何か（ESMビルド）に、消えていくもの（デフォルトのエクスポート）を導入することはあまり意味がないと思います。

ただし、私の見解では、React 16でESMをビルドし、将来のメジャーバージョンでエクスポートのデフォルトを削除することができます。

もう1つの懸念は、構成の数を増やすとエコシステムに負担がかかることです。 たとえば、ESMビルドをリリースする場合、デフォルトのエクスポートなど、次のリリースで確実に削除するものを含めるべきではないと思います。 言い換えれば、追加されたばかりの何か（ESMビルド）に、消えていくもの（デフォルトのエクスポート）を導入することはあまり意味がないと思います。

次のリリースの長さにもよると思います。 週の違いについて話している場合、それは合理的なようです。 しかし、私たちが数ヶ月/数年話しているのなら、なぜそれをその時間の間出すのが悪いのか分かりません

この場合の懸念は、それが長く存在するほど、現在の形でより多くの人々がそれに依存することです。 そして、そこに重大な変更を導入すると、Reactのアップグレードがより困難になります。 現在、ESMの移行は1つだけでなく、いくつかあります。ジャンプが早すぎて、後で別の移行のためのリソースがないために取り残される人もいます。 これは、ESMの場合、エコシステム全体に波及します。

ESMビルドをリリースする場合、デフォルトのエクスポートなど、次のリリースで確実に削除するものを含めるべきではないと思います。 言い換えれば、追加されたばかりの何か（ESMビルド）に、消えていくもの（デフォルトのエクスポート）を導入することはあまり意味がないと思います。

私はimport React from 'react'を新しく追加されたものとしてではなく、現在の現実を受け入れるものと見なしています。 これはおそらく意図的ではなく、現在は廃止されたESM / CJS相互運用機能の副作用にすぎませんが、それを実行するコードはまだ数千（数百万？）行あります。 別の方法（名前付きエクスポートのみをエクスポートする）は、ユーザーに「ESMビルドをマイナーバージョンで公開しましたが、すべてのコードを変更せずに使用することはできません」と言っています。メジャーバージョンのリリースノートにあります。

私は興味があります-デフォルトのエクスポートを使用したESMを下位互換性のある方法で追加するにはどうすればよいですか？ これは以前に発生したことがあります（たとえば、関連する問題にもリンクしているhttps://github.com/facebook/react/pull/18187）。 問題があるとWebPACKのCJS < - >あなたがやってCJSコードを持っている場合はESM相互運用require('react')のWebPACKは、ESMの存在に戻ります何reactデフォルトのエクスポートと、を持つオブジェクトですdefault CJS react関係なく、 defaultプロパティ（つまり、 require('react').defaultが必要になります）。 しかし、namedもエクスポートする場合は、問題はありませんか？ @TrySoundは、以前に他のパッケージでこのような問題に

しかし、namedもエクスポートする場合は、問題はありませんか？

はい、これは私が考えているアプローチです。 https://unpkg.com/browse/@esm-bundle/react @ 16.13.1 / esm / react.development.jsの最後の40行を参照してください-これはReactの非公式バージョンであり、これを正確に実行し、複数のユーザーが使用しています公式Reactのドロップイン代替としての組織。 重大な変更はありません。

しかし、namedもエクスポートする場合は、問題はありませんか？

はい、これは私が考えているアプローチです。 https://unpkg.com/browse/@esm-bundle/react @ 16.13.1 / esm / react.development.jsの最後の40行を参照してください-これはReactの非公式バージョンであり、これを正確に実行し、複数のユーザーが使用しています公式Reactのドロップイン代替としての組織。 重大な変更はありません。

しかし、CJSコードまたはESMからそれを消費していますか？ 非常に驚くべきことは、CJS <-> ESM相互運用の問題だからです。

@gaearon明確にする; 私が提案しているESMラッパーにデフォルトのエクスポートがないことは理にかなっています。 ネイティブESMを実行している人は誰でも、それを回避するためにimport * as React from 'react'を実行します。 誰もが今、それはあなたが今デフォルトを追加したくなかった場合はV17ゴマ待つ必要があるだろうので、突然、デフォルトのエクスポートを持たないために破壊変更としてそれを見るだろうとやっていることしかし、それの公正な。

しかし、CJSコードまたはESMからそれを消費していますか？ 非常に驚くべきことは、CJS <-> ESM相互運用の問題だからです。

CJSファイルとESMファイルの両方からwebpackに正常にインポートしました。

ネイティブESMを実行している人は誰でも、それを回避するために「react」からReactとして*をインポートします。 ただし、これを実行している人は、突然デフォルトのエクスポートがなくなるという重大な変更と見なすのは当然です。したがって、デフォルトを今すぐ追加したくない場合は、v17まで待つ必要があります。

同意しました。 ゼロから始める場合は、デフォルトのエクスポートを行う必要はありません。 ただし、デフォルトのエクスポートを追加しないと、重大な変更なしにフェーズ2を実装することはできません。 個人的には、React 16でフェーズ1を、React 17+でフェーズ2〜4を実行しても問題ありませんが、フェーズ1、2、場合によっては3を実行することをお勧めします（

この提案から継続します。 これは、状態を別の場所に分離することによってデュアルパッケージの危険に対処する完全な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に当てはまります（バンドラーには当てはまりません）。したがって、 cjsディレクトリ内のファイルは.cjs終わる必要があります。

同じパッケージの潜在的に2つのバージョンをロードすると、そのような場合にReactのメモリフットプリントも増加します

これにより、npmに公開されるtarballのサイズが大きくなり、ディスク上の全体のサイズが大きくなることがわかります。 しかし、これがメモリにどのように影響するかはわかりません。 私の知る限り、バンドラーとNodeJSは、 import / require()介してロードされていないコードをメモリに取り込みません。 メモリーフットプリントがどのように変化するかを明確にできますか？

たとえば、Componentクラスの実装が状態を共有するCJSコードの一部ではなく、代わりにCJS / ESMバンドルの一部である場合、さまざまなライブラリのinstanceofComponentチェックが破損するリスクがあります。

一つの提案された解決策は、（ 1 、 2 ）NodeJS ESM実装はCJSコードにコールすることを単にESMインターフェースであることです。 このように、Nodeで使用されるComponent定義は1つだけです。 ただし、フェーズ1とフェーズ2は、NodeJSで実行されるものを変更しないため、これはフェーズ3にのみ適用されます。

私たち（webpack）も最近webpack 5にexportsフィールドサポートを追加したので、このトピックに2セントを与えたいと思います。

• この仕掛品ドキュメントには、webpackだけでなくNode.jsおよび一般的なexportsフィールドに関する多くの情報が含まれています：
• Node.jsと比較したキーポイントは次のとおりです。
  
  
  
  • webpack 5は、 developmentとproduction条件も追加します。これらは、反応に非常に役立ちます。 （ process.env.NODE_ENVは引き続きサポートされていますが、フロントエンドコードでは一般的に避ける必要があります。これはNode.js固有です）
  
  
  • webpack（およびその他のバンドラー）はrequire("esm")サポートしており、常にESMを使用することでデュアルステートの問題を回避できます（ require() ）。 webpackはそのための特別な条件を導入しました： module 。 このCommonJsとESMバージョンでは、同じインターフェースをエクスポートする必要があります。 現在、Node.js以外にデュアルステートの問題があるものはありません。 これは主に後方互換性の問題であるため、将来的に何かが発生することはないと思います。
    
    最大限の互換性を得るには、次のことをお勧めします。
  
  

package.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 / package.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 }

結果

• webpack 5： ./esm/index.development.jsまたは./esm/index.production.min.js
• browserify： ./cjs/index.js
• .mjsのwebpack4： ./cjs/index.js
• 他のバンドラー： ./esm/wrapper.js
• Node.js（ESM）： ./cjs/index.js （必須）または./esm/wrapper.js （インポート）
• Node.js（旧）： ./cjs/index.js
• Node.js（ESM + dev / prod）：インポートの場合./cjs/index.development.js ./esm/wrapper.development.jsまたは./esm/wrapper.production.min.js ./cjs/index.production.min.js 、必須の場合は./cjs/index.development.jsまたは./cjs/index.production.min.js

ノート

ESMでは、大きなトレードオフがなければ、条件付きでバージョンを選択することはできないため、 esm/index.jsはありません。
ツールは、 exportsフィールド、 module条件（デュアルステートの問題のため）、およびproduction / developmentをサポートしている場合にのみ、reactESMから完全に恩恵を受けることができます。

ツールがmoduleフィールドまたはexportsフィールドをサポートしている場合、ツールはReactESMから部分的に恩恵を受けることができます。

import { useState } from "react"またはimport * as React from "react"は、reactがCommonJsモジュールである限り、技術的に違法です。
ほとんどのツールは引き続き後方互換性をサポートしていますが、Node.jsなどの一部のツールはサポートしていません。
したがって、現在、どこでも有効なreactを使用する唯一の方法は、 import React from "react"です。
この方法はサポートされたままである必要があります。そうしないと、現在の反応とESMの追加後に反応するのに有効な構文がない場合（Node.js 14など）が発生します。

Node.jsは、今のところexports development / production条件の追加を拒否しました。
それは悲しいことです、そして私はまだ彼らが最終的にそれを追加することを願っています。
そのため、上記のexportsフィールドでサポートが用意されています。

@sokra素晴らしい内訳、非常に役に立ちました、ありがとう！

1つの小さな質問：

Node.jsは、現時点では、エクスポートの開発/本番条件の追加を拒否しました。

私の理解では、それはまだ取り組んでいるということですか？ https://github.com/nodejs/node/pull/33171しかし、おそらく私はそのPRを誤解しています

[編集]私がリンクした上記のPRは、 https：//github.com/nodejs/node/pull/34637に置き換えられました

[edit2]そしてnodejsにマージされました

@sokraに感謝し

これが私が見るオプションです。 それらはすべて技術的に可能であり、決定は技術的な実装よりも戦略の1つであるように思われます。

オプション1

追加export default Reactには、17 ESMビルドを反応し、ためにCJSサポート一度それを削除import React from 'react' （おそらく18を反応させるの？）ドロップされます。

オプション2

export default React追加しないでください。また、名前付きエクスポートのみを使用してReact 17ESMビルドを作成してください。

オプション3

React 17ESMビルドを公開しないでください。 （😢）ESMビルドを作成する前に、 import React from 'react';サポートが削除されるまで待ちます。

比較

| | オプション1 | オプション2 | オプション3 |
| -| -------- | -------- | -------- |
| 参照されていないESMビルド| v17 | v17 | v18 + |
| package.json "module"（デフォルトではツリーシェイク）| v17 | v18 + | v18 + |
| package.json "type" / "exports"（NodeJSはESMを使用します）| v18 + ¹ | v18 + | v18 + |

1. package.json type / exportsを完全な下位互換性のある方法で実装できる可能性があります。その場合、オプション1を選択すると、React17の一部になる可能性があります。

上で説明したように、私の好みはオプション1です。 ただし、オプション2も非常にエキサイティングです。 もちろん、オプション3はそれほど刺激的ではありません。 このgithubの問題で私が集めたものから、私たちはこれらのいずれかを実現するための技術的な専門知識を持っています（そしておそらく労力さえも！）。

この問題に対する最初の反応は、なぜこの問題は3年経っても開かれているのかということでした。 その一部を読んだ後、なぜそれがそんなに時間がかかるのか理解できます。 Reactのようなライブラリを維持することは大きな仕事です。 だから🙇🏻

React 17に関する最近のニュースを踏まえて、以前のコメントを更新して、将来の計画で16ではなくReact17を参照するようにしました。

上記の3つのオプションのどれが好ましいかについてのフィードバックをいただければ幸いです。

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であり、ブラウザ環境では意味がなく、たとえばwebpack5の_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 ：
  
  

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の相互運用性などに関してノードが実装するものは、既存のエコシステムでは実際にはうまく機能しません。 デュアルパッケージの危険性は現実的です-特に、それらの単一のコピーを必要とするReacのようなパッケージの場合。

commonjsのみのファイルを含むexportsマップは、何も壊さずに追加できる可能性がありますが、これを適切に行うために、さらに慎重に、適切なe2eテストを実行する必要があります（適切に処理するのがどれほど複雑かを考えると）

@Andaristそれはうまく機能し、reactの場合も違いはありません。これは常にその危険性があり、エコシステムは、reactをどこでも

Reactのすべての依存関係（推移的かどうかに関係なく）がReactの制御下にあり（この場合はそうです）、それらすべてのESMエントリポイントがCJSコンテンツを再エクスポートしている場合は、そうです-おそらくこの特定のケースでは達成可能です。

ESMエントリの実際の形状がどうあるべきかについてのドラマ全体がまだあります（名前付き、デフォルト、両方）：

• 名前付きのみ：多くのコードがimport React from 'react'を使用しているため、実際には下位互換性がありません。これは、ESMを使用しているときにノードにReactを実際にインポートする唯一の方法でもあります。
• デフォルトのみ： import * as React from 'react'を使用しているコードの多くが、タイプチェッカーや他のツールによって促進されているため、実際には下位互換性はありません。
• 両方：完全な下位互換性を確保する唯一の方法であるため、現在のすべての読み込みスタイルで機能し、依存関係ツリー全体でESMモジュールとCJSモジュールを混在させることができます。

チートのように感じるESMラッパーの可能性を常に忘れていますが、この手法はすべての依存関係を制御する場合に

両方を提供する唯一の普遍的な戦略は、実際には、すべての実際のコードをCJSに入れ、その周りにESMラッパーを記述して名前付きエクスポートを提供することです。 ステートフルではなく、IDに依存しないコードは、両方でネイティブに記述できますが、これはサブセットであり、注意が必要です。

jsx-runtimeはステートフルではありませんか？ ラッパーなしで両方のesm / cjsを安全に出荷できるはずです。

esmノードにreact/jsx-runtimeをインポートするための別の問題をログに記録する必要がありますか？

フロントエンドパッケージの場合、追加の課題がデュアルステートハザードに加わります。それをダブルバンドルハザードと呼びましょう。

ESMおよびCJSバージョンをエクスポートし、パッケージがrequireおよびimportを介して使用される場合、両方のバージョンがバンドルされ、パッケージの有効バンドルサイズが2倍になります。

@sokraは実際にそれが可能ですか？ たとえば、ロールアップでは、cjsモジュールがesmモジュールに変換されるため、使用可能な場合はいつでもesmモジュールをインポートすることをお勧めします。

実際には、ノードセマンティクス（webpack 5など）に従うバンドラーで可能です。セマンティクスを一致させることが重要です。そうしないと、ノードで実行する場合とバンドルコードを実行する場合に異なる結果が発生する可能性があるためです。

ただし、webpack 5は、esm / cjs（エクスポートマップからの重複排除）に使用される特別な"module"条件を処理します。

@ljharbの提案を検討すると、これは実際には関係ありません。なぜなら、esmファイルはcjsファイルを再エクスポートするラッパーコードのほんの数行である可能性があるからです。

薄いESMラッパーを使用すると、バンドラーの有無にかかわらず、追加の危険性はありません。グラフ内の重複についてピアの担当者が回避する通常の危険性のみです。