Storybook: Fehler: Exporte sind nicht definiert

Ich erhalte export 'MatrixEffect' was not found in '../dist/index' im Terminal. Aber ich kann das Modul nur in einer einfachen Node-Laufzeit importieren (kann es nicht ofc verwenden, aber zumindest weiß ich, dass es importiert werden kann).

dies könnte helfen, da wir noch keine offiziellen Dokumente haben: https://github.com/storybooks/storybook/issues/3270

Das funktioniert immer noch nicht...

Ich bin gerade auf ein Problem mit der gleichen Fehlermeldung in einem Storybook gestoßen, nachdem ich Garn-Arbeitsbereiche in einem Lerna-Projekt aktiviert hatte. Ich vermute, dass dies durch Probleme beim Laden von Paketen verursacht wird. Untersuche weiter.

Klingt so, als hätte ich das gleiche Problem.

Wenn ich das Problem richtig verstehe, gibt es ein Problem mit der Auflösung von .ts-Dateien aus .js? (Obwohl ich nicht verstehe, warum Sie Ihre Komponente von dist importieren)

Vielleicht sollten Sie .ts / .tsx zu resolve.extensions in Ihrem erweiterten Storybook webpack.config hinzufügen?

@igor-dv Nein, ich verwende JS. Wie auch immer, das Ändern der Variablenkennung ( variable in Variable ) funktioniert irgendwie.

Ich erhalte diesen Fehler, ohne TypeScript zu verwenden, nur Vanilla JS

Ich habe den babel-Loader aus webpack.config.js im Ordner .storybook entfernt und er funktioniert jetzt einwandfrei. Typescript verwende ich allerdings nicht.

Ich stoße darauf, im Browser bekomme ich exports is not defined aber im Terminal bekomme ich `"export 'default' (imported as '[ComponentName]') was not found in '@[namespace]/[ Paketnamen]'"

• Mit lerna
• Märchenbuch 3.4.7
• Für meine Komponenten ist alles in Ordnung, ohne interne Abhängigkeiten
• Wenn ich versuche, ein Modul mit einer Abhängigkeit von einem anderen Paket in project/packages zu importieren, wird der Fehler angezeigt
• Ich führe meine Build-Skripts aus, also versucht es, eine Common-js-Version des Pakets einzufügen.

Wenn ich die Hauptkonfiguration von package.json der internen Abhängigkeit in die nicht erstellte Quelle ändere, funktioniert alles

Es stimmt also etwas nicht mit der Webpack-Konfiguration von Storybook und dem Importieren von cjs in den es-Modulcode oder so ...

Meine Lösung

Also wurde mir klar, dass ich versehentlich mein "Modul"-Feld "package.json" gelöscht hatte, das auf die ES-Modulversion meiner Builds verwies, und das Hinzufügen, dass alles wieder funktioniert. Scheint immer noch so, als ob Storybook in der Lage sein sollte, die cjs-Version zu ziehen, aber mein Problem ist gelöst 🤷🏽‍♂️

Dies passiert mir immer noch in v4.0.0-alpha.20 mit babel 7.0.0

Dasselbe hier @tony. Ich benutze aber Flow.

@ryanflorence Ich habe genau das gleiche Lerna-Setup und das Exportproblem für Storybook.
Ich habe ein Paket, das die gebaute Version der UI-Elemente verfügbar macht.
Entschuldigung, aber könnten Sie mehr Details angeben, wenn Sie "module" field that pointed to the ES module version of my builds, adding that back in makes everything work again. sagen

Dieses Problem kann behoben werden, indem das richtige Plug-in in der Datei .babelrc hinzugefügt wird. Da die Datei tsconfig so konfiguriert ist, dass sie mit commonjs kompatible Module generiert, müssen wir das richtige Plug-in verwenden

{
    "env": {
        "test": {
            "plugins": ["instanbul"]
        }
    },
    "plugins": ["@babel/plugin-syntax-dynamic-import", "@babel/plugin-transform-modules-commonjs"]
}

Dies ist, was ich in meiner .babelrc -Datei habe und alles funktioniert gut, ich habe meine tsconfig -Datei mit genau den gleichen Optionen und Werten.

"@babel/core" "^7.1.0"
"@storybook/react" ^4.0.0-alpha.2"
"react" "^16.4.0"

Hinweis: Diese Lösung funktioniert für eine andere Art von Modulen https://babeljs.io/docs/en/next/plugins#modules

Für mich wird das Problem durch die jüngsten Änderungen verursacht, die den babel-loader in 4.0.0.alpha enthalten. Die standardmäßige Server-Webpack-Konfiguration könnte Ihre Commonjs-Kompilierungen (Pakete, Arbeitsbereiche) enthalten: https://github.com/storybooks/storybook/blob/b2b73596f9dd97b4ba8c03340bd36f868e836772/lib/core/src/server/config/webpack.config.dev.js# L78
https://github.com/storybooks/storybook/blob/b2b73596f9dd97b4ba8c03340bd36f868e836772/lib/core/src/server/config/utils.js#L3

Für mich besteht eine Lösung darin, die Standard-Plugin-Deklaration mit einem benutzerdefinierten webpack.dev.js zu überschreiben:

https://github.com/psychobolt/react-rollup-boilerplate/blob/d9cb9179cb7c00baab486646c504110bf7e2f50a/.storybook/webpack.config.js#L7

// exclude 'babel-loader' so we can override it later
...defaultConfig.module.rules.filter(rule => !(
    (rule.use && rule.use.length && rule.use.find(({ loader }) => loader === 'babel-loader'))
)),

https://github.com/psychobolt/react-rollup-boilerplate/blob/d9cb9179cb7c00baab486646c504110bf7e2f50a/.storybook/webpack.config.js#L11

{
  test: /\.jsx?$/,
  include: require('path').resolve('./'),
  exclude: /(node_modules|dist)/, // exclude any commonjs files
  loader: 'babel-loader',
},

Das Weglassen include behebt das Problem ebenfalls und hat für mich keine Nebenwirkungen.

Ich glaube, ich verstehe, was los ist.

Was @psychobolt sagt, ist 100% richtig.

Ich denke, wir könnten es für Monorepo-Benutzer besser machen, indem wir unsere Standard-Webpack-Konfiguration erstellen, damit das oben Genannte nicht passiert.

Ich denke, das Entfernen include: includePaths, würde es tun, aber die Frage ist, zu welchen Leistungskosten.

Wer hat einen guten Vorschlag, wie man das am besten löst?

Wir sind auch über dieses Problem gestolpert und es dauerte mehr als einen halben Tag, um Konfigurationen zu bekämpfen, um herauszufinden, was es sein könnte. 😢

@cilice Wie hast du das gelöst?

@0nn0 indem Sie https://github.com/storybooks/storybook/issues/3346#issuecomment-425516669 diesem Rat folgen :)

Ich habe das gleiche Problem mit stotybook-4.1.4, Lerna-Projekt, React 16.7.0, Plain JS. Funktioniert mit Storybook-4.0.12

Ich hatte den gleichen Fehler auf 4.1.4, ich bin zurück auf 4.0.10 und funktioniert gut (kein Typoskript) babel-webapck

Die Verwendung einer modifizierten Konfiguration zum Ausschließen der kompilierten Ausgabe von babel-loader wird dieses Problem für Lerna- oder Monorepo-Projekte mit dem neuesten Storybook-Paket vermeiden.

@psychobolt Könnten Sie eine Beispielkonfiguration bereitstellen? Danke.

Siehe https://github.com/storybooks/storybook/issues/3346#issuecomment -425516669

Ich bin mir nicht sicher, ob dies jemand anderem hilft, aber wir haben dieses Problem behoben, indem wir Folgendes ausgeführt haben:

npm i react-scripts -D

@skeet Ich habe mich gefragt, warum Storybook die Nachricht hatte

info => Using base config because react-scripts is not installed.
info => Using default webpack setup based on "create-react-app".
info => Using base config because react-scripts is not installed.

Also, nach der Installation von React-Scripts heißt es jetzt

info => Loading create-react-app config.
info => Using default webpack setup based on "create-react-app".
info => Loading create-react-app config.

Wir hatten auch ein paar Mal das exports is not defined -Problem und wir haben es zuvor umgangen, indem wir die Babel-Konfiguration überschrieben haben, wie von anderen vorgeschlagen.

Aber ich habe vor kurzem begonnen, mich erneut damit zu befassen, und mir ist aufgefallen, dass die Exclude -Eigenschaft für die Standard-JS-Regel in einen absoluten Pfad aufgelöst wurde (unten ist ein console.log() der generierten Webpack-Konfiguration):

{
  test: /\.(mjs|jsx?)$/,
  use: [
    {
      loader: 'babel-loader',
      options: {
        cacheDirectory: '.cache/storybook',
        presets: [
          [
            '@babel/preset-env',
            { shippedProposals: true, useBuiltIns: 'usage' }
          ],
          '@babel/preset-react',
          '@babel/preset-flow'
        ],
        plugins: [
          'babel-plugin-macros',
          '@babel/plugin-proposal-class-properties',
          [
            'babel-plugin-react-docgen',
            { DOC_GEN_COLLECTION_NAME: 'STORYBOOK_REACT_CLASSES' }
          ]
        ]
      }
    }
  ],
  include: ['/Users/matt.hinchliffe/Project/'],
  exclude: ['/Users/matt.hinchliffe/Project/node_modules']
}

Ich hatte angenommen, dass die exclude -Eigenschaft ein RegExp sein sollte, also fand ich, dass es seltsam aussah! Mir wurde klar, dass wir aufgrund der Struktur unseres Projekts tatsächlich viele node_modules -Ordner haben, also habe ich versucht, diese Zeile in einen RegExp ( /node_modules/ ) zu aktualisieren - und es wurde behoben!

Dies vermeidet das Transpilieren von Modulen, die bereits transpiliert wurden - und verhindert insbesondere, dass die useBuiltins -Option von preset-env core-js -Polyfills einfügt (durch Entfernen der useBuiltins -Option oder -Einstellung Die Umgebung für Laufzeiten, die keine Polyfills erfordern, kann ebenfalls dazu beitragen, dieses Problem zu vermeiden.)

Es gibt also ein paar verschiedene Probleme, die zu diesem Problem führen:

1. Abhängigkeiten in node_modules -Ordnern können von Babel unbeabsichtigt transpiliert werden
2. Die Option useBuiltins kann core-js Polyfills im falschen Format für den Modultyp in Ihren Code einfügen (siehe https://github.com/babel/babel/issues/7463 und https:// github.com/babel/babel/issues/9187)
3. Wenn Pakete symbolisch verknüpft werden (z. B. in einem Monorepo), müssen Sie besonders vorsichtig vorgehen, um Punkt 1 zu vermeiden!

Leider ist es nicht ganz einfach, die bestehende Exclude-Option zu erweitern, aber es ist möglich !

Ich habe für dieses Problem einen reduzierten Testfall mit Hinweisen zur Vermeidung erstellt. Ich werde bei Bedarf ein Problem mit Babel einreichen.

https://github.com/i-like-robots/broken-webpack-bundle-test-case

Wir verwenden Bilderbücher + Lerna + Typoskript. Was für uns gelöst wurde, war das Mischen von @i-like-robots mit @psychobolt :

module.exports = (baseConfig, env, config) => {
    config.module.rules = config.module.rules.filter(rule => !(
        (rule.use && rule.use.length && rule.use.find(({ loader }) => loader === 'babel-loader'))
    ));
    config.module.rules.push({
        test: /\.(ts|tsx)$/,
        loader: require.resolve('babel-loader'),
        options: {
            sourceType: 'unambiguous',
            presets: [['react-app', { flow: false, typescript: true }]],
        },

    });
    config.resolve.extensions.push('.ts', '.tsx');
    return config;
};

Wir haben dasselbe Problem, wann werden Sie es beheben?

Dieser Fehler wird bei einer Neuinstallation angezeigt. Keine Ahnung, was dies verursacht (möglicherweise in einem Konflikt mit dem .babelrc zwischen dem Setup von create-react-app und diesem?).

Ich konnte das Problem beheben, indem ich der Datei .babelrc die folgende Zeile hinzufügte:

"sourceType": "unambiguous"

Weitere Informationen zu dieser Option: https://babeljs.io/docs/en/options#sourcetype
Glauben Sie, dass diese Option nur mit Babel 7 und höher verfügbar ist.

Nur um an diesem vorbeizufahren, ohne vollständig zu verstehen, was die Probleme der Leute sind (Entschuldigung!) - hier ist ein Ausschnitt aus meiner Webpack-Konfiguration, der dieses Problem umgeht, vielleicht auf einfachere Weise:

  const babelLoader = storybookBaseConfig.module.rules[0];
  babelLoader.exclude.push(
    path.resolve('./lib/components/node_modules'),
    /* etc */
  );

@tmeasday Können Sie Ihren Vorschlag bitte näher erläutern – dh wo soll dieser Code platziert werden?

Storybook ist großartig, aber dieser Fehler war zeitweise und schrecklich. Ich kann anscheinend keinen Reim oder Grund dafür finden, warum dieser Fehler auftreten wird. Ich hantiere mit Komponenten herum und dann boom, alles funktioniert einfach, ohne dass wirkliche Änderungen vorgenommen werden. Aber ich stecke jetzt seit einer Stunde fest und versuche, das zum Laufen zu bringen, und ich habe einfach nicht die leiseste Ahnung, warum das kaputt ist.

Bitte schauen Sie sich dieses Problem an, das viele Menschen zu betreffen scheint und ein Showstopper ist.

Ich habe das Problem gelöst, indem ich eine .storybook/weback.config.js -Datei erstellt habe, die Folgendes enthält:

const path = require('path');

// Export a function. Accept the base config as the only param.
module.exports = async ({ config, mode }) => {
    // `mode` has a value of 'DEVELOPMENT' or 'PRODUCTION'
    // You can change the configuration based on that.
    // 'PRODUCTION' is used when building the static version of storybook.

    config.module.rules[0].use[0].options.sourceType = "unambiguous";

    return config;
};

Scheint, als würde es auf das sourceType -Babel-Problem hinauslaufen. Ich habe versucht, eine .babelrc -Datei hinzuzufügen (wie von @0nn0 vorgeschlagen), aber das schien die gesamte babel-Konfiguration zu ersetzen, anstatt sie zu ändern, was weitere Probleme verursachte.

@JasonTheAdams das Code-Snippet, das ich oben geschrieben habe, würde in .storybook/webpack.config.js gehen. Ich denke, es ist ähnlich wie das, was Sie getan haben.

Hier ist, was meiner Meinung nach los ist:

Das Problem ist, dass Dateien in node_modules innerhalb von Unterprojekten (z. B. ./lib/components/node_modules ) von babel kompiliert werden. Es handelt sich um Dateien, die bereits an NPM gesendet wurden und nicht kompiliert werden müssen. In manchen Fällen führt dies zu verwirrenden Problemen, vielleicht in Bezug darauf, wie babel Dateien parst.

Mein Ansatz besteht darin, babel-loader anzuweisen, keine Datei in einem beliebigen node_modules -Ordner zu kompilieren. Standardmäßig wird ./node_modules ignoriert, also werden Dinge innerhalb von node_modules des Unterprojekts kompiliert. Also füge ich der Liste exclude einige Pfade hinzu.

Ihr Ansatz besteht darin, babel-loader so zu konfigurieren, dass die sourceType -Erkennung von babel verwendet wird, um zu sagen, wie eine Datei zu parsen ist. Dies funktioniert im Grunde genommen um das Fehlparsen von babel-Dateien herum. Allerdings läuft babel immer noch mit Dateien, die nicht kompiliert werden müssen, also weiß ich nicht, ob es das ist, was Sie wollen?

Ich bin kein Experte, also nehmen Sie meine Worte mit einem Körnchen Salz, aber das ist mein Verständnis, das ich selbst durch ähnliche Probleme gearbeitet habe.

Nachdem ich den Vorschlag von @skeet (https://github.com/storybooks/storybook/issues/3346#issuecomment-459308703) angewendet hatte, kehrte das Problem zurück, als ich anfing, ein Paket als Abhängigkeit (nicht Peer oder Entwickler) einiger anderer zu referenzieren .

Das Einfügen des module -Felds in das package.json #$-Feld der Abhängigkeit wie in @ryanflorence 's fix (https://github.com/storybooks/storybook/issues/3346#issuecomment-415982589) hat den Job gemacht.

   main: "dist/index.js",
+  module: "dist/index.js",

@tmeasday Verstanden . Ich fange an, mich mit diesem Thema zu beschäftigen. Was schwierig ist, ist, dass ich in meiner Situation tatsächlich _will_, dass es das Kind node_modules kompiliert, da ich dort die Komponenten selbst entwickle und es als separates Paket behandle.

Ich denke, der Vorschlag von @skeet , wie er von @jcousins-ynap wiederholt wird, ist hier wahrscheinlich die beste Lösung. Wir wollen nicht, dass Storybook Annahmen darüber macht, wie Unterpakete gehandhabt werden (dh ihre node_modules ignorieren). Wenn jemand nicht wollte, dass die Untermodule node_modules kompiliert werden, hätte er die Paketabhängigkeiten wahrscheinlich nicht installiert, um damit anzufangen.

Es scheint alles auf die Fähigkeit von babel + webpack zurückzuführen zu sein, CommonJS vs. ES6-Module zu erkennen, was nicht perfekt zu sein scheint. Das Hinzufügen des "module": -Felds zu package.json des Unterpakets informiert babel explizit darüber, dass das Paket ES6-Module verwendet, was der sicherste Weg ist, dies anzugehen.

Vielen Dank für Ihre Aufmerksamkeit!

Möchte mich auch hier einklinken. Mit Storybook 5, Babel 7.4 (mit Core-js 3), TypeScript 3.4 und einem Monorepo. Die meisten dieser Vorschläge funktionierten nicht zu 100%, aber etwas, das ich erkannte, tat es. Die Natur von Monorepos besteht darin, dass ein Paket die "erstellten" Dateien aus einem anderen Paket importiert, nicht die Quelldateien, was in der NPM-Registrierungs-/Knotenmodulebene zutrifft, aber in der Entwicklung ziemlich ärgerlich ist. Um dies zu umgehen, habe ich Webpack-Aliase definiert, die lib/ an src/ weiterleiteten, und alles funktionierte einfach, zumal der gesamte Code jetzt ESNext/ESM ist!

Hier ist der Hack:

glob.sync(path.join(__dirname, '../packages/*/package.json')).forEach(filePath => {
  const { name } = require(filePath);

  config.resolve.alias[`${name}$`] = `${name}/src`;
  config.resolve.alias[`${name}/lib`] = `${name}/src`;
});

Und um Babel + TS zum Laufen zu bringen, habe ich mich dafür entschieden, den vorhandenen babel-loader zu mutieren, anstatt einen neuen hinzuzufügen, da meine lokale Babel-Konfiguration nicht zu 100 % mit der von Storybook kompatibel ist, ihre eigene Konfiguration jedoch schon.

const babelConfig = config.module.rules[0];

// Replace Flow with TypeScript
babelConfig.test = /\.(j|t)sx?$/;
babelConfig.exclude.push(/node_modules/);
babelConfig.use[0].options.sourceType = 'unambiguous';
babelConfig.use[0].options.presets[2] = require.resolve('@babel/preset-typescript');
babelConfig.use.unshift({ loader: require.resolve('react-docgen-typescript-loader') });

config.resolve.extensions.push('.ts', '.tsx');

Hatte das gleiche Problem, auch weil das Feld module entfernt wurde.
Das Hinzufügen @babel/plugin-transform-modules-commonjs zum Babel-Plugin hat geholfen, wie in diesem Kommentar beschrieben: https://github.com/storybooks/storybook/issues/3346#issuecomment -423719241

@elado Arbeit!

total behindert von diesem auch. verbrachte die letzten ~2 Tage damit, alle Vorschläge aus diesem Thread sowie einige meiner eigenen erfolglos auszuprobieren. keiner war erfolgreich 😢

schlussendlich bleibt mir:

WARNING in ./packages/one/src/index.jsx 2:289-293
"export 'default' (imported as 'Two') was not found in '@my-monorepo/two'
 @ ./packages/one/src/index.stories.jsx
 @ ./packages sync \.stories\.jsx$
 @ ./.storybook/config.js
 @ multi ./node_modules/@storybook/core/dist/server/common/polyfills.js ./node_modules/@storybook/core/dist/server/preview/globals.js ./.storybook/config.js

...beim Starten von Bilderbuch und...

index.js:49 ReferenceError: exports is not defined
    at react-is.development.js:18
    at Module../packages/one/node_modules/react-is/cjs/react-is.development.js (react-is.development.js:226)
    at __webpack_require__ (bootstrap:785)
    at fn (bootstrap:150)
    at Object../packages/one/node_modules/react-is/index.js (index.js:6)
    at __webpack_require__ (bootstrap:785)
    at fn (bootstrap:150)
    at Object../packages/one/node_modules/prop-types/index.js (index.js:9)
    at __webpack_require__ (bootstrap:785)
    at fn (bootstrap:150)

...beim Betrachten der Benutzeroberfläche des Storybooks (http://localhost:9001). Meine Stories werden nicht geladen.

fwiw, hier ist mein Setup:

├── .storybook/
│   ├── addons.js
│   ├── config.js
│   └── webpack.config.js
│
├── packages/
│   ├── one
│   │   ├── src/
│   │   │   ├── index.jsx
│   │   │   ├── index.stories.jsx
│   │   │   └── index.test.jsx
│   │   ├── dist/
│   │   │   ├── index.js
│   │   │   ├── index.stories.js
│   │   │   └── index.test.js
│   │   └── package.json
│   │
│   └── two
│       ├── src/
│       │   ├── index.jsx
│       │   ├── index.stories.jsx
│       │   └── index.test.jsx
│       ├── dist/
│       │   ├── index.js
│       │   ├── index.stories.js
│       │   └── index.test.js
│       └── package.json
│
├── .babelrc
├── .eslintrc.js
├── jest.config.js
├── lerna.json
├── npm-shrinkwrap.json
└── package.json

import '@storybook/addon-knobs/register';
import '@storybook/addon-backgrounds/register';
import '@storybook/addon-storysource/register';

import { configure } from '@storybook/react';

const req = require.context('../packages', true, /.stories.jsx$/);

function loadStories(){
    req.keys().forEach(filename => req(filename));
}

configure(loadStories, module);

module.exports = {
    module: {
        rules: [
            {
                test: /\.stories\.jsx?$/,
                loaders: [require.resolve('@storybook/addon-storysource/loader')],
                enforce: 'pre'
            }
        ]
    }
};

{
    "presets": ["@babel/preset-env", "@babel/preset-react"],
    "plugins": [
        "@babel/plugin-transform-modules-commonjs"
    ]
}

{
  "name": "my-monorepo",
  "description": "monorepo containing POC react ui component library",
  "version": "1.0.0",
  "author": "me",
  "scripts": {
    "postinstall": "npm run bootstrap",
    "bootstrap": "lerna bootstrap",
    "storybook": "npm run build && start-storybook --port 9001 --config-dir .storybook --ci",
    "test": "npm run lint && npm run test:unit",
    "test:unit": "npm run build && NODE_ENV=development BABEL_ENV=test jest --no-watchman",
    "test:unit:watch": "npm run test:unit -- --watch",
    "test:unit:snapshot": "npm run test:unit -- --updateSnapshot",
    "lint": "eslint . --ext .js,.jsx --ignore-path .gitignore",
    "lint:fix": "npm run lint -- --fix",
    "build": "npm run clean && lerna run build",
    "clean": "lerna run clean",
    "clean:modules": "lerna clean --yes",
    "release": "npm run build && lerna publish",
    "start": "npm run storybook"
  },
  "dependencies": {},
  "devDependencies": {
    "@babel/cli": "^7.5.5",
    "@babel/core": "^7.5.5",
    "@babel/plugin-transform-modules-commonjs": "^7.5.0",
    "@babel/preset-env": "^7.5.5",
    "@babel/preset-react": "^7.0.0",
    "@storybook/addon-backgrounds": "^5.1.9",
    "@storybook/addon-knobs": "^5.1.9",
    "@storybook/addon-storysource": "^5.1.9",
    "@storybook/react": "^5.1.9",
    "babel-jest": "^22.4.1",
    "babel-loader": "^8.0.6",
    "enzyme": "^3.10.0",
    "enzyme-adapter-react-16": "^1.14.0",
    "enzyme-to-json": "^3.3.5",
    "eslint": "^4.18.2",
    "eslint-config-particle": "^2.2.1",
    "eslint-plugin-react": "^7.14.2",
    "jest": "^22.4.2",
    "jest-styled-components": "^6.3.3",
    "lerna": "^3.15.0",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "styled-components": "^4.3.2"
  }
}

{
  "name": "@my-monorepo/one",
  "description": "react component one",
  "version": "1.1.0",
  "author": "me",
  "main": "dist/index.js",
  "scripts": {
    "test": "cd ../../ && npm test",
    "build": "babel ./src --out-dir ./dist --ignore test.jsx,stories.jsx --config-file ../../.babelrc",
    "clean": "rm -rf ./dist"
  },
  "peerDependencies": {
    "react": ">=15",
    "styled-components": ">=3"
  },
  "dependencies": {
    "@my-monorepo/two": "^1.1.0",
    "create-react-class": "^15.6.3",
    "prop-types": "^15.7.2"
  }
}

{
  "name": "@my-monorepo/two",
  "description": "react component two",
  "version": "1.1.0",
  "author": "me",
  "main": "dist/index.js",
  "scripts": {
    "test": "cd ../../ && npm test",
    "build": "babel ./src --out-dir ./dist --ignore test.jsx,stories.jsx --config-file ../../.babelrc",
    "clean": "rm -rf ./dist"
  },
  "peerDependencies": {
    "react": ">=15"
  },
  "dependencies": {
    "create-react-class": "^15.6.3",
    "prop-types": "^15.7.2"
  }
}

alles innerhalb des ./src -Verzeichnisses der Komponenten verwendet Importe/Exporte im ESM-Stil. die @my-monorepo/one hängt von @my-monorepo/two ab. Lernen Sie während der Installation die Abhängigkeit _links_ (über lerna bootstrap ). alle Pakete werden mit babel erstellt - der npm run build -Befehl der obersten Ebene generiert die einzelnen ./dist -Verzeichnisse und deren Inhalt. npm start erstellt zuerst die Komponenten und startet dann Storybook.

unter v3 funktionierte das alles einwandfrei - obwohl es sich immer etwas umständlich anfühlte, die Komponenten zuerst bauen zu müssen. Ich verstehe jedoch _warum_ - package.json enthält "main: "dist/index.js" , also würde Storybook ohne dieses vorhandene Storybook melden, dass @my-monorepo/two beim Versuch, zu bauen, nicht gefunden werden konnte (da @my-monorepon/one davon abhängt darauf). aber ansonsten war ich mit der einstellung zufrieden.

Eine Sache, die mir aufgefallen ist: Als ich "module": "src/index.jsx" zu den package.json -Dateien der Komponenten hinzufügte, wurde die Webpack-Warnung entfernt, aber das clientseitige ReferenceError: exports is not defined blieb. Ich habe jemanden gefunden, der den gleichen Fehler gemeldet hat, aber keine Lösung.

Ich werde vorerst bei Storybook v3 bleiben, aber ich werde diesen Thread im Auge behalten und alle Vorschläge gerne ausprobieren :bet::+1:

@busticated hört sich so an, als hätten Sie vielleicht ein Reproduktions-Repo, das Sie teilen könnten, das ich mir ansehen könnte?

@ndelangen danke fürs reinschauen :bet: mein repo ist leider nicht öffentlich atm. Ich habe versucht, die relevanten Details oben zu teilen, aber in der Zwischenzeit kann ich versuchen, ein funktionierendes Beispiel aufzubauen, wenn das hilfreich wäre. könnte aber etwas dauern. ansonsten probiere ich gerne vorschläge etc.

@busticated Gerne schaue ich mir ein Monorepo-Repro-Repo an 🙈

Es ist wahrscheinlich, dass:

• Einige Dateien werden zweimal durch babel geparst
• Einige Dateien werden durch Ladeprogramme geparst, die nicht miteinander kompatibel sind
• Einige Dateien werden mit der falschen babel/ts-Konfiguration kompiliert
• einige andere Monorepo-Spielereien

Leider sagt uns ReferenceError: exports is not defined nichts anderes, irgendetwas ist nicht so, wie es sein soll.

@ndelangen ok, hier ist das repro repo 😂

https://github.com/busticated/storybook-monorepo-repo

Sie sollten in der Lage sein, einfach:

1. git clone
2. npm i && npm start

... und sehen Sie, wie das Storybook versucht, im Browser zu laden. Öffnen Sie die Konsole der Entwicklertools und Sie sehen den Fehler exports .

paar Anmerkungen:

• Führen Sie npm run build aus, um den Prepublish-Build zu testen
• Es sollte über Knoten-/npm-Versionen hinweg funktionieren +/- einige Sperrdateigeräusche (fwiw, ich habe node@8 und npm@5 verwendet, um mich mit dem Tagesjob auszurichten)
• die letzten beiden Commits fügen die "module": "src/index.jsx" -Felder zu packages/*/packge.json -Dateien hinzu. Wenn Sie diese zurücksetzen, sehen Sie die ursprüngliche export 'default' (imported as 'Two') was not found Webpack-Warnung.

Ich werde versuchen, so schnell wie möglich nachzusehen

Ich verwende Lerna, interne Pakete werden von Webpack mit der Ausgabe libraryTarget: 'commonjs2' gebündelt. Ansatz basierend auf @JasonTheAdams Kommentar funktioniert für mich. Ich habe auch die @0nn0- Lösung mit babelrc { "sourceType": "unambiguous" } getestet und es funktioniert auch, aber es erfordert, dass .babelrc im Paketstamm vorhanden ist.

Einige Grundeinstellungen - vielleicht hilft es jemandem 😉(Storybook: 5.1.10, Lerna: 3.16.4, Webpack: 4.39.1, Babel: 7.5.5)

Datei: _lerna_repo/.storybook/webpack.config.js_ - existiert standardmäßig nicht

module.exports = async ({ config }) => {
  const [ mjsjsx ] = config.module.rules;
  const [ babelLoader ] = mjsjsx.use;

  babelLoader.options.sourceType = 'unambiguous'

  return config;
};

Datei: _lerna_repo/stories/index.stories.js_

import defaultExport, { namedExport } from '../packages/examplePackage' // works locally
// import defaultExport, { namedExport } from '<strong i="17">@examplePackage</strong>' // works installed
...

Datei: _lerna_repo/packages/examplePackage/package.json_

"name": "@examplePackage",
"version": "0.0.1",
"main": "./dist/index.js"
...

Datei: _lerna_repo/packages/examplePackage/dist/index.js_ - generiert von Webpack

module.exports=function(e){var n={};function...

@ndelangen Irgendwelche Updates zu dem oben Gesagten?

Ich habe den Fehler „Exporte sind nicht definiert“ erhalten, als ich versuchte, ein Modul im CommonJS-Stil zu „importieren“. Das Setzen der Option Babel sourceType auf "unambiguous", wie von anderen vorgeschlagen, hat den Zweck erfüllt.

Dies ist bei Storybook nicht wirklich ein Problem, eher eine Folge davon, dass man zwischen zwei Modulspezifikationen feststeckt.

Scheint in Version 5.2 behoben zu sein

Hallo Leute, ist es eigentlich behoben?

Ich verwende 5.2.1 und habe dieses Problem im neu erstellten Lerna monorepo .

In meinem Fall passiert das: https://github.com/storybookjs/storybook/issues/3346#issuecomment -475437230

Ich habe Storybook Webpack config geändert, um node_modules in "Lerna" packages von der Kompilierung von Babel auszuschließen. Aber das Problem ist immer noch da, denke ich.

Ich habe aufgrund des Kommentars von @idbartosz geschlossen. Glaubst du, es ist immer noch kaputt @Lighttree ?

Entschuldigung für die Verwirrung, ich habe meine Antwort auf die Lerna-Konfiguration gestützt, bei der erforderliche Pakete in das Stammverzeichnis gehisst und dort als Dev-Abhängigkeiten installiert werden. Ich hatte also nicht das Problem, ihre node_modules zu analysieren.

Es scheint, dass einige Benutzer einen Anwendungsfall haben, bei dem sie Pakete tiefer im Baum installiert haben, wie /lib/components/node_modules https://github.com/storybookjs/storybook/issues/3346#issuecomment -475437230 und babel-loader versucht es analysieren sie.

Standardmäßig schließt Storybook root node_modules aus, aber vielleicht lohnt es sich, alle auszuschließen.

https://github.com/storybookjs/storybook/blob/f7367b18ec7d6e077fba5b99da89233b63c4f280/lib/core/src/server/config/utils.js#L5 -L6

https://github.com/storybookjs/storybook/blob/f7367b18ec7d6e077fba5b99da89233b63c4f280/lib/core/src/server/common/babel-loader.js#L1 -L13

@shilman Ich bin auch mit diesem Fehler konfrontiert, mit react-motion in lerna Mono-Repo-Repository.
hat die @idbartosz- Lösung das Problem behoben?

@sayjeyhi ja, sollte es. Das ist eigentlich kein Storybook Problem. Dies geschieht nur, weil Sie node_modules nicht nur in Ihrem Projektstamm haben, sondern auch in */packages , wenn Sie in monorepo arbeiten, was standardmäßig nicht ausgeschlossen ist. (Ich bin mir eigentlich nicht sicher, ob es das nicht sollte, weil es monorepo organisationsspezifisch ist. Wenn Sie Ihre Storybook als package im Ordner Lerna packages erstellen, haben Sie gewonnen habe dieses Problem nicht)

Also für meinen Fall habe ich das gerade in .storybook/webpack.config.js gemacht:

const path = require('path');
const glob = require('glob');

// Export a function. Accept the base config as the only param.
module.exports = async ({ config, mode }) => {
    // `mode` has a value of 'DEVELOPMENT' or 'PRODUCTION'
    // You can change the configuration based on that.
    // 'PRODUCTION' is used when building the static version of storybook.
    // Make whatever fine-grained changes you need
    const babelLoader = config.module.rules[0];

    /**
     * Exclude pacakge's `node_modules` from Storybook babel processing.
     */
    glob.sync('./packages/*/node_modules').forEach(match => {
        babelLoader.exclude.push(path.resolve(match));
    });

    // Return the altered config
    return config;
};

Hat jemand tatsächlich seine vorgeschlagenen Workaround-Korrekturen in dem von mir erstellten Beispiel-Repro gezeigt?

https://github.com/storybookjs/storybook/issues/3346#issuecomment -514324312

scheint, als würde das die Frage definitiv beantworten.

Ich kann sehen, dass fast jeder hier mit einem monorepo -Projekt lerna verwendet, ich habe ein monorepo -Projekt, das yarn workspaces anstelle von lerna verwendet. storybook + typescript , und ohne seltsame webpack Konfigurationen sollte es auch mit babel funktionieren.

Wenn Sie etwas Interesse zeigen, kann ich ein monorepo mit einem funktionierenden storybook erstellen. Ich kann in den Dateien von @busticated sehen, dass einige Skripte in der falschen Reihenfolge ausgeführt werden und einige Abhängigkeiten vorhanden sind das falsche package.json , ich sage nicht, dass das Probleme verursacht, aber es könnte sein.

@pixeleate

Ich kann in den Dateien von @busticated sehen, dass einige Skripts in der falschen Reihenfolge ausgeführt werden und einige Abhängigkeiten in der falschen package.json enthalten sind

kannst du genauer sein?

Denken Sie auch daran, dass ich eine _funktionierende_ Version meines Beispiel-Repos habe, auf dem Storybook v3 ausgeführt wird, wie hier angegeben https://github.com/storybookjs/storybook/issues/3346#issuecomment -513397002

@pixeleate Würde es Ihnen etwas ausmachen, Ihr funktionierendes Repo zu teilen?

Ich kann sehen, dass fast jeder hier mit einem monorepo -Projekt lerna verwendet, ich habe ein monorepo -Projekt, das yarn workspaces anstelle von lerna verwendet. storybook + typescript , und ohne seltsame webpack Konfigurationen sollte es auch mit babel funktionieren.

Wenn Sie etwas Interesse zeigen, kann ich ein monorepo mit einem funktionierenden storybook erstellen. Ich kann in den Dateien von @busticated sehen, dass einige Skripte in der falschen Reihenfolge ausgeführt werden und einige @ Abhängigkeiten bestehen im falschen package.json sage ich nicht, dass das Probleme verursacht, aber es könnte sein.

babelConfig.exclude.push(/node_modules/); behebt das Problem für mich, wenn ich start-storybook , aber ich erhalte den gleichen exports is not defined Fehler, wenn ich die Ausgabe von build-storybook .

Bearbeiten: Gelöst durch Entfernen von storybook-addon-jsx .

@busticated Ich habe eine PR mit einem Fix geöffnet:
https://github.com/busticated/storybook-monorepo-repo/pull/1

Es gab ein paar fehlerhafte Importe, die meiner Meinung nach das Hauptproblem waren.

@jacobrask Ich möchte das im Kern des Storybooks ändern. Aber ich habe Angst, dass es Chaos anrichten wird, wenn wir das in einer kleineren Version ändern.

@shilman Ich denke, wir sollten es ändern, aber es sollte eine größere Versionserhöhung sein

@ndelangen

Ich habe eine PR mit einem Fix geöffnet

Danke!

Es gab ein paar fehlerhafte Importe, die meiner Meinung nach das Hauptproblem waren

Hm. ja. Geschieht mir recht, dass ich eslint 😂🤦‍♂ nicht eingerichtet habe

Alles in allem scheint es, sobald Sie die schlechten Variablennamen und die aktualisierte Verwendung @storybook/addon-backgrounds berücksichtigt haben - wie ich es bei master ( 1 , 2 , 3 , 4 ) getan habe - die einzige ausstehende Änderung ist Garn zu verwenden.

hab ich recht?

Bearbeiten: Hier ist ein aufgeräumter Zweig mit nur den erforderlichen Änderungen für yarn 👉 https://github.com/busticated/storybook-monorepo-repo/commit/4fb2cac0f05b65a5983f121b92a7c2d7438d8857

Garn-Arbeitsbereiche werden alle Abhängigkeiten an die Wurzel heben, dies wird Tonnen von Problemen lösen.

In meinem PR: https://github.com/storybookjs/storybook/pull/8822 nehme ich eine Änderung am Storybook vor, um standardmäßig das Ausschließen von MEHREREN node_modules-Ordnern zu unterstützen.

Wie dort beschrieben, habe ich ziemliche Angst davor, diese Änderung in einer Nebenversion herauszubringen, und @shilman auch. Wir haben entschieden, dass es besser ist, das bis 6.0 zu halten.

Garn-Arbeitsbereiche werden alle Abhängigkeiten an die Wurzel heben, dies wird Tonnen von Problemen lösen.

Vorausgesetzt, du verwendest Garn 😉

Nehmen Sie eine Änderung am Storybook vor, um standardmäßig das Ausschließen MEHRERER node_modules-Ordner zu unterstützen

ist das die eigentliche ursache? Das lokale Anwenden der Änderung scheint mein Problem nicht zu beheben.

Ich erhalte in der Konsole meines Browsers Folgendes:

TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

... was ein bisschen anders ist, denke ich ...? noch ein weiterer fehler, den du ständig siehst, aber immer eine andere lösung hat 🤦‍♂ _/me runzelt die stirn in der allgemeinen richtung von babel und webpack_ 😬

Ich habe ziemliche Angst davor, diese Änderung in einer Nebenversion herauszubringen, und @shilman auch. Wir haben entschieden, dass es besser ist, das bis 6.0 zu halten.

Oh ja, ich höre dich – nichts von diesem Zeug ist jemals einfach. vielen Dank für all die Arbeit, die Sie hier und anderswo leisten - Storybook (sogar v3) ist ein unglaublich hilfreiches Tool :pray::clap::clap::clap::+1:

TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

Dies wird höchstwahrscheinlich dadurch verursacht, dass Webpack ein CommonJS-Modul mit seinem ESM-Wrapper umschließt. Webpack verwendet einen ESM-Wrapper, wenn es eine Verwendung von import im Modul sieht. Es wird normalerweise verursacht durch:

1. Mischen und Abgleichen von ESM und CJS in Ihrem Quellcode
2. Babel injiziert ESM-Helfer in ein CJS-Modul

Um den zweiten Fall zu vermeiden, müssen Sie sourceType von Babel auf "unambiguous" setzen, um es zu zwingen, zuerst den Modultyp zu prüfen.

https://github.com/i-like-robots/broken-webpack-bundle-test-case

Update: Mein ursprünglicher Kommentar ist oben ausgeblendet, aber dies ist die Basiskonfiguration, die wir verwendet haben, um diese Probleme in mehreren Monorepo-Projekten zu lösen:

const excludePaths = [/node_modules/, /dist/]

module.exports = ({ config }) => {
  // Use real file paths for symlinked dependencies do avoid including them multiple times
  config.resolve.symlinks = true

  // HACK: extend existing JS rule to ensure all dependencies are correctly ignored
  // https://github.com/storybooks/storybook/issues/3346#issuecomment-459439438
  const jsRule = config.module.rules.find((rule) => rule.test.test('.jsx'))
  jsRule.exclude = excludePaths

  // HACK: Instruct Babel to check module type before injecting Core JS polyfills
  // https://github.com/i-like-robots/broken-webpack-bundle-test-case
  const babelConfig = jsRule.use.find(({ loader }) => loader === 'babel-loader')
  babelConfig.options.sourceType = 'unambiguous'

  // HACK: Ensure we only bundle one instance of React
  config.resolve.alias.react = require.resolve('react')

  return config
}

@i-like-robots Was ist der Nachteil bei der Verwendung von sourceType = 'unambiguous' ?

Danke für das Posten des Workarounds!

Ich werde dies verwenden, um die Monorepo-Unterstützung zu verbessern: https://github.com/storybookjs/storybook/pull/8822

(6.0.0-Funktion)

Vielleicht nicht verwandt, aber ich hatte dieses exports is not defined Problem wegen meiner benutzerdefinierten babel.config.js , das Lesen von https://storybook.js.org/docs/configurations/custom-babel-config/ hat mein Problem gelöst Problem.

@qrosmeli Danke für den Tipp. Du hast meinen Tag gerettet! 🚀

Hurra!! Ich habe gerade https://github.com/storybookjs/storybook/releases/tag/v6.0.0-alpha.0 mit PR #8822 veröffentlicht, das auf dieses Problem verweist. Aktualisieren Sie noch heute, um es auszuprobieren!

Sie finden diese Vorabversion unter dem NPM-Tag @next .

Schließe dieses Problem. Bitte öffnen Sie wieder, wenn Sie glauben, dass noch mehr zu tun ist.

[AKTUALISIERT] - Wir müssen node_modules von dieser Regel ausschließen, da sonst der Build unterbrochen wird

Ich habe es gelöst, indem ich diese Regel in die main.js-Datei des Storybooks eingefügt habe

let rules = [{
  test: /\.(js|mjs|jsx|ts|tsx)$/,
  include: /dist/, //Include dist folder as well to parse using babel loader in order to resolve exports not defined error
  exclude: /node_modules/,
  loader: 'babel-loader',
  options: {
    presets: [
      ["@babel/preset-env", {
        modules: "commonjs"
      }]
    ]
  }
}]

Darüber hinaus müssen Sie möglicherweise auch die Eslint-Validierungen für Ihren dist-Ordner deaktivieren, sodass Sie dafür das folgende Skript verwenden können

  webpackFinal: config => {

    //Find eslint loader rule from webpack config
    let eslintRule = config.module.rules.find(rule => {
      if (rule && rule.use) {
        return rule.use.some(use => use.loader.match('eslint-loader'))
      }
    });

    //Exclude validations of dist folder contents
    eslintRule.exclude = /dist/;

    return {
      ...config,
      module: {
        rules: [
          ...rules,
          eslintRule,
          ...config.module.rules
        ]
      }
    }
  }

Danke @ashvin777 , funktioniert wie ein Zauber :wink:

Hey @aperkaz , ich habe die Regel aktualisiert, um node_modules auszuschließen. Ich habe festgestellt, dass Storybook im Entwicklungsmodus ordnungsgemäß gestartet wurde, jedoch aufgrund dieser Änderung im Produktionsmodus unterbrochen wurde. Also musste ich node_modules ausschließen, um das Problem zu beheben. Sie können das Neueste aus meinem aktualisierten Kommentar oben entnehmen.

Ich hatte genau das gleiche Problem, und für mich bestand die Lösung darin, von transform-es2015-modules-commonjs zu @babel/plugin-transform-modules-commonjs auf babel.config.js zu wechseln.

Vor

module.exports = {
    presets: [['@babel/preset-env', { modules: false }], '@babel/preset-react'],
    plugins: [
        'transform-es2015-modules-commonjs',
        '@babel/plugin-proposal-class-properties'
    ]
};

nach dem

module.exports = {
    presets: [['@babel/preset-env', { modules: false }], '@babel/preset-react'],
    plugins: [
        '@babel/plugin-transform-modules-commonjs',
        '@babel/plugin-proposal-class-properties'
    ]
};

TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

Ich habe den Tag mit diesem Thema verbracht, ich hatte bereits die sourceType: 'unambigous' .

Für meinen Teil war es nicht mit einem zu ignorierenden node_modules -Ordner verknüpft, da es sich um eine relative Datei direkt daneben handelt.

Eine Problemumgehung, die für mich funktioniert, besteht darin, die Option modules: 'cjs' für @babel/preset-env zu erzwingen.

Ich habe dieses Problem auch mit @storybook/react@next , die endgültige Lösung für mich bestand darin, das Babel-Plugin @babel/plugin-transform-modules-commonjs manuell hinzuzufügen, während mit der Option debug: true die Option @babel/preset-env Ich sehe, dass es bereits verwendet wird ... Ich verstehe nicht, aber es funktioniert.

BEARBEITEN: Dies ist keine Lösung, da die Vorteile von ESM-Modulen mit Webpack verloren gehen. Ich muss die Umwandlung in cjs nur für die Storybook-Builds erzwingen.

:tada: Meine .storybook/.babelrc : :tada:

{
  "extends": "../.babelrc",
  "plugins": [
    "@babel/plugin-transform-modules-commonjs"
  ]
}