Storybook: Erreur : les exportations ne sont pas définies

Je reçois export 'MatrixEffect' was not found in '../dist/index' dans le terminal. Mais je peux importer le module dans une simple exécution de nœud (je ne peux pas l'utiliser ofc, mais au moins je sais qu'il peut être importé).

cela pourrait aider car nous n'avons pas encore de documentation officielle : https://github.com/storybooks/storybook/issues/3270

Cela ne fonctionne toujours pas...

Je viens de rencontrer un problème avec le même message d'erreur dans un livre de contes après avoir activé les espaces de travail de fil dans un projet lerna. Je soupçonne que cela est dû à des problèmes de chargement de packages. Enquêter plus loin.

On dirait que j'ai le même problème.

Si je comprends bien le problème, il y a un problème avec la résolution des fichiers .ts à partir du .js ? (Cependant, je ne comprends pas pourquoi vous importez votre composant à partir de dist )

Peut-être devriez-vous ajouter .ts / .tsx au resolve.extensions dans votre webpack.config de livre de contes étendu ?

@igor-dv Non, j'utilise JS. Quoi qu'il en soit, changer l'identifiant de variable ( variable en Variable ) fonctionne d'une manière ou d'une autre.

Je reçois cette erreur sans utiliser TypeScript, juste vanilla JS

J'ai supprimé le chargeur babel de webpack.config.js dans le dossier .storybook et cela fonctionne bien maintenant. Je n'utilise pas Typescript cependant.

Je suis confronté à cela, dans le navigateur, j'obtiens exports is not defined mais dans le terminal, j'obtiens `"export 'default' (importé en tant que '[ComponentName]') n'a pas été trouvé dans '@[namespace]/[ nom du paquet]'"

• Utiliser lerna
• Livre d'histoires 3.4.7
• Tout va bien pour mes composants sans dépendances internes
• Si j'essaie d'importer un module avec une dépendance sur un autre package dans project/packages l'erreur s'affiche
• J'exécute mes scripts de construction, donc il essaie d'extraire une version common-js du package.

Si je change la configuration principale package.json de la dépendance interne en source non construite, tout fonctionne

Il y a donc quelque chose qui ne va pas avec la configuration du webpack de storybook et l'importation de cjs dans le code du module es, ou quelque chose ...

Ma solution

J'ai donc réalisé que j'avais accidentellement supprimé mon champ "module" package.json qui pointait vers la version du module ES de mes builds, en ajoutant que tout refonctionnait. Il semble toujours que le livre de contes devrait pouvoir extraire la version cjs, mais mon problème est résolu 🤷🏽‍♂️

Cela se produit toujours pour moi dans v4.0.0-alpha.20 avec babel 7.0.0

Pareil ici @tony. J'utilise Flow, cependant.

@ryanflorence J'ai exactement la même configuration de lerna et le problème des exportations pour le livre de contes.
J'ai un package qui expose la version construite des éléments d'interface utilisateur.
Toutes mes excuses, mais pourriez-vous fournir plus de détails lorsque vous dites : "module" field that pointed to the ES module version of my builds, adding that back in makes everything work again.

ce problème peut être résolu en ajoutant le bon plugin dans le fichier .babelrc , puisque le fichier tsconfig est configuré pour générer des modules compatibles commonjs , nous devons utiliser le bon plugin

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

C'est ce que j'ai dans mon fichier .babelrc et tout fonctionne bien, j'ai mon fichier tsconfig avec exactement les mêmes options et valeurs.

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

Remarque : Cette solution fonctionne pour un autre type de modules https://babeljs.io/docs/en/next/plugins#modules

Pour moi, le problème est causé par les changements récents pour inclure babel-loader dans 4.0.0.alpha. La configuration par défaut du serveur webpack peut inclure vos compilations commonjs (packages, espaces de travail): 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

Pour moi, un correctif consiste à remplacer la déclaration par défaut du plugin par un webpack.dev.js personnalisé :

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',
},

Omettre include résout également le problème et n'a aucun effet secondaire pour moi.

Je pense que je comprends ce qui se passe.

Ce que @psychobolt dit est 100% correct.

Je pense que nous pourrions faire mieux pour les utilisateurs monorepo, créer notre configuration Webpack par défaut afin que ce qui précède ne se produise pas.

Je pense que supprimer include: includePaths, le ferait, mais la question est de savoir à quel coût de performance...

Qui a une bonne suggestion sur la meilleure façon de résoudre ce problème ?

Nous sommes également tombés sur ce problème et il a fallu plus d'une demi-journée de configurations de combat pour comprendre ce que cela pouvait être. 😢

@cilice Comment avez-vous résolu cela?

@0nn0 en suivant https://github.com/storybooks/storybook/issues/3346#issuecomment-425516669 ce conseil :)

J'ai le même problème avec stotybook-4.1.4, projet Lerna, React 16.7.0, plain JS. Fonctionne avec storybook-4.0.12

J'ai eu la même erreur sur 4.1.4, je suis de retour sur 4.0.10 et fonctionne bien (pas de tapuscrit) babel-webapck

L'utilisation d'une configuration modifiée pour exclure la sortie compilée de babel-loader évitera ce problème pour les projets Lerna ou monorepo avec le dernier package de livre de contes.

@psychobolt Pourriez-vous fournir un exemple de configuration ? Merci.

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

Je ne sais pas si cela aidera quelqu'un d'autre, mais nous avons résolu ce problème en exécutant ce qui suit :

npm i react-scripts -D

@skeet je me demandais pourquoi le livre de contes avait le message

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.

Ainsi, après avoir installé les scripts de réaction, il est maintenant indiqué

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

Nous avons également eu le problème exports is not defined à quelques reprises et nous l'avons déjà contourné en remplaçant la configuration de Babel comme suggéré par d'autres.

Mais, j'ai récemment recommencé à examiner cela et j'ai remarqué que la propriété d' exclusion de la règle JS par défaut était résolue en un chemin absolu (ci-dessous, un console.log() de la configuration Webpack générée):

{
  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']
}

J'avais supposé que la propriété exclude devait être une RegExp, alors j'ai pensé que ça avait l'air bizarre ! J'ai réalisé qu'en raison de la structure de notre projet, nous avions en fait de nombreux dossiers node_modules , j'ai donc essayé de mettre à jour cette ligne vers une RegExp ( /node_modules/ ) - et cela a été résolu !

Cela évite de transpiler des modules qui ont déjà été transpilés - et évite en particulier l'option useBuiltins de preset-env d'injecter des polyfills core-js (en supprimant l'option ou en définissant useBuiltins l'environnement pour cibler les runtimes qui ne nécessitent aucun polyfill peut également aider à éviter ce problème.)

Il y a donc quelques problèmes différents en jeu qui entraînent ce problème:

1. Les dépendances dans les dossiers node_modules peuvent être involontairement transpilées par Babel
2. L'option useBuiltins peut injecter des polyfills core-js dans votre code dans le mauvais format pour le type de module (voir https://github.com/babel/babel/issues/7463 et https:// github.com/babel/babel/issues/9187)
3. Si les packages sont liés symboliquement (comme dans un monorepo), vous devez faire très attention pour éviter le point 1 !

Malheureusement, il n'est pas très facile d'étendre l' option d'exclusion existante , mais c'est possible !

J'ai créé un cas de test réduit pour ce problème avec des informations sur la façon de l'éviter. Je déposerai un problème avec Babel si nécessaire.

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

Nous utilisons des livres d'histoires + lerna + tapuscrit. Ce qui a résolu pour nous a été de mélanger @i-like-robots avec @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;
};

Nous avons le même problème, quand allez-vous le réparer ?

Obtenir cette erreur sur une nouvelle installation. Aucune idée de ce qui cause cela (peut-être un conflit avec le .babelrc entre la configuration de create-react-app et celle-ci ?).

J'ai réussi à résoudre le problème en ajoutant la ligne suivante au fichier .babelrc :

"sourceType": "unambiguous"

Plus d'infos sur cette option : https://babeljs.io/docs/en/options#sourcetype
Croyez que cette option n'est disponible qu'avec Babel 7 et plus.

Juste pour passer sur celui-ci sans bien comprendre quels sont les problèmes des gens (excuses !) - voici un extrait de ma configuration Webpack qui contourne ce problème, peut-être d'une manière plus simple :

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

@tmeasday Pouvez-vous s'il vous plaît développer votre suggestion - c'est-à-dire où placer ce code?

Storybook est génial, mais cette erreur a été intermittente et horrible. Je n'arrive pas à trouver une rime ou une raison pour laquelle cette erreur va commencer à se produire. Je vais m'occuper des composants, puis boum, tout commence à fonctionner sans qu'aucun changement réel ne soit apporté. Mais je suis bloqué depuis une heure à essayer de faire fonctionner cela et je n'ai tout simplement pas la moindre idée de la raison pour laquelle cela est cassé.

Veuillez vous pencher sur ce problème qui semble affecter de nombreuses personnes et qui est un obstacle.

J'ai résolu le problème en créant un fichier .storybook/weback.config.js contenant les éléments suivants :

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;
};

On dirait que cela se résume au problème de Babel sourceType . J'ai essayé d'ajouter un fichier .babelrc (comme suggéré par @0nn0), mais cela semblait remplacer toute la configuration de babel plutôt que de la modifier, causant d'autres problèmes.

@JasonTheAdams l'extrait de code que j'ai écrit ci-dessus irait dans le .storybook/webpack.config.js . Je pense que c'est similaire à ce que tu as fait.

Voici ce que je pense qu'il se passe :

Le problème est que les fichiers dans node_modules à l'intérieur des sous-projets (par exemple ./lib/components/node_modules ) sont compilés par babel. Ce sont des fichiers qui ont déjà été envoyés à NPM et qui n'ont pas besoin d'être compilés. Dans certains cas, cela provoque des problèmes déroutants, peut-être autour de la façon dont babel analyse les fichiers.

Mon approche consiste simplement à dire à babel-loader ne compiler aucun fichier dans un dossier node_modules . Par défaut, il ignorera ./node_modules donc il compilera les choses à l'intérieur de node_modules du sous-projet. J'ajoute donc quelques chemins à la liste exclude .

Votre approche consiste à configurer babel-loader pour utiliser la détection sourceType de babel pour indiquer comment analyser un fichier. Cela fonctionne essentiellement autour des fichiers d'analyse erronée de Babel. Cependant, babel fonctionne toujours sur des fichiers qui n'ont pas besoin d'être compilés, donc je ne sais pas si c'est ce que vous voulez ?

Je ne suis pas un expert, alors prenez mes mots avec un grain de sel, mais c'est ce que je comprends après avoir moi-même travaillé sur des problèmes similaires.

Après avoir appliqué la suggestion de @skeet (https://github.com/storybooks/storybook/issues/3346#issuecomment-459308703), le problème est revenu lorsque j'ai commencé à référencer un package en tant que dépendance (pas de pair ou de développement) de quelques autres .

Mettre le champ module dans le package.json de la dépendance comme dans le correctif de @ryanflorence (https://github.com/storybooks/storybook/issues/3346#issuecomment-415982589) a fait le travail.

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

@tmeasday J'ai compris. Je commence à comprendre ce problème. Ce qui est délicat, c'est que, dans ma situation, je veux vraiment qu'il compile l'enfant node_modules car c'est là que je développe les composants eux-mêmes, en le traitant comme un package séparé.

Je pense que la suggestion de @skeet , reprise par @jcousins-ynap, est probablement la meilleure solution ici. Nous ne voulons pas que Storybook fasse des suppositions sur la façon dont les sous-paquets sont gérés (c'est-à-dire en ignorant leurs node_modules). Si quelqu'un ne voulait pas que les sous-modules node_modules soient compilés, il n'aurait probablement pas installé les dépendances du package pour commencer.

Tout semble dépendre de la capacité de babel + webpack à reconnaître les modules CommonJS vs ES6, ce qui ne semble pas parfait. L'ajout du champ "module": au package.json du sous-package informe explicitement babel que le package utilise des modules ES6, ce qui est le moyen le plus sûr d'aborder cela.

Merci pour l'attention que vous portez à cela !

Je veux aussi intervenir ici. Utilisation de Storybook 5, Babel 7.4 (avec core-js 3), TypeScript 3.4 et un monorepo. La plupart de ces suggestions n'ont pas fonctionné à 100 %, mais j'ai réalisé que quelque chose fonctionnait. La nature même de monorepos est qu'un paquet importe les fichiers "construits" d'un autre paquet, pas les fichiers source, ce qui est vrai dans la couche de module de registre/nœud NPM, mais en développement, c'est assez ennuyeux. Pour contourner ce problème, j'ai défini des alias Webpack qui ont transmis lib/ à src/ , et tout a fonctionné, d'autant plus que tout le code est maintenant ESNext/ESM !

Voici le 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`;
});

Et pour faire fonctionner Babel + TS, j'ai choisi de muter le babel-loader existant au lieu d'en ajouter un nouveau, car ma configuration Babel locale n'est pas compatible à 100% avec celle de Storybook, mais leur propre configuration l'est.

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');

Avait le même problème, également en raison de la suppression du champ module .
L'ajout @babel/plugin-transform-modules-commonjs au plugin babel a aidé, comme décrit dans ce commentaire : https://github.com/storybooks/storybook/issues/3346#issuecomment -423719241

@elado travaille !

totalement bloqué par celui-ci aussi. J'ai passé les 2 derniers jours à essayer sans succès toutes les suggestions de ce fil ainsi que certaines des miennes. aucun n'a réussi 😢

au final il me reste :

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

...lors du démarrage du livre d'histoires et...

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)

... lors de la visualisation de l'interface utilisateur du livre d'histoires (http://localhost:9001). mes histoires ne chargent pas.

fwiw, voici ma configuration:

├── .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"
  }
}

tout ce qui se trouve dans le répertoire ./src des composants utilise des importations/exportations de style ESM. le @my-monorepo/one dépend de @my-monorepo/two . au moment de l'installation, lerna _links_ la dépendance (via lerna bootstrap ). tous les packages sont construits à l'aide de babel - la commande de niveau supérieur npm run build génère les répertoires individuels ./dist et leur contenu. npm start construit d'abord les composants, puis démarre storybook.

sous la v3, tout cela fonctionnait très bien - même s'il était toujours un peu gênant de devoir d'abord créer les composants. je comprends _pourquoi_ cependant - package.json inclut "main: "dist/index.js" donc sans cela en place, le livre de contes signalerait que @my-monorepo/two n'a pas pu être trouvé lors de la tentative de construction (puisque @my-monorepon/one dépend dessus). mais sinon, j'étais content de la configuration.

une chose que j'ai remarquée : lorsque j'ai ajouté "module": "src/index.jsx" aux fichiers package.json des composants, l'avertissement Webpack a été supprimé, mais le côté client ReferenceError: exports is not defined est resté. J'ai trouvé quelqu'un signalant la même erreur mais pas de résolution.

Je vais m'en tenir au livre de contes v3 pour l'instant, mais je vais garder un œil sur ce fil et j'essaierai volontiers toutes les suggestions :pray::+1:

@busticated semble avoir un dépôt de reproduction que vous pourriez partager, je pourrais y jeter un coup d'œil ?

@ndelangen merci d'avoir jeté un coup d'œil :priez: mon dépôt n'est malheureusement pas public. J'ai essayé de partager les détails pertinents ci-dessus, mais en attendant, je peux essayer de créer un exemple de travail si cela peut être utile. peut prendre un peu cependant. sinon, heureux d'essayer des suggestions, etc.

@busticated je serais ravie de jeter un oeil à un monorepo-repro-repo 🙈

Il est probable que :

• certains fichiers sont analysés par babel deux fois
• certains fichiers sont analysés par des chargeurs qui ne sont pas compatibles entre eux
• certains fichiers sont compilés avec la mauvaise configuration babel/ts
• quelques autres manigances monorepo

Malheureusement, ReferenceError: exports is not defined ne nous dit rien d'autre, quelque chose n'est pas ce qu'il est censé être.

@ndelangen ok, voici le repo repro 😂

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

vous devriez pouvoir simplement :

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

... et voir la tentative de chargement du livre d'histoires dans le navigateur. ouvrez la console des outils de développement et vous verrez l'erreur exports .

quelques remarques :

• exécutez npm run build pour tester la version de prépublication
• cela devrait fonctionner sur les versions node / npm +/- un peu de bruit de fichier de verrouillage (fwiw, j'ai utilisé node@8 et npm@5 pour aligner avec le travail du jour)
• les deux derniers commits ajoutent les champs packages/*/packge.json "module": "src/index.jsx" fichiers packages/*/packge.json. si vous les annulez, vous verrez l'avertissement Webpack d'origine export 'default' (imported as 'Two') was not found .

je vais essayer de jeter un oeil au plus vite

J'utilise Lerna, les packages internes sont regroupés par Webpack avec une sortie libraryTarget: 'commonjs2' . L'approche basée sur le commentaire de @JasonTheAdams fonctionne pour moi. J'ai également testé la solution @ 0nn0 avec babelrc { "sourceType": "unambiguous" } et cela fonctionne également, mais cela nécessite d'avoir .babelrc dans la racine du package.

Une configuration de base - peut-être que cela aidera quelqu'un 😉 (Storybook : 5.1.10, Lerna : 3.16.4, Webpack : 4.39.1, Babel : 7.5.5)

fichier : _lerna_repo/.storybook/webpack.config.js_ - n'existe pas par défaut

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

  babelLoader.options.sourceType = 'unambiguous'

  return config;
};

fichier : _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
...

fichier : _lerna_repo/packages/examplePackage/package.json_

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

fichier : _lerna_repo/packages/examplePackage/dist/index.js_ - généré par Webpack

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

@ndelangen Une mise à jour sur ce qui précède ?

J'ai eu l'erreur "les exportations ne sont pas définies" lorsque j'ai essayé "d'importer" un module de style CommonJS. Définir l'option Babel sourceType sur "sans ambiguïté" comme suggéré par d'autres a fait l'affaire.

Ce n'est pas vraiment un problème avec Storybook, plus une conséquence d'être coincé au milieu de deux spécifications de module.

Semble être corrigé dans la version 5.2

Salut les gars, est-ce que c'est réparé en fait ?

J'utilise 5.2.1 et j'ai ce problème dans Lerna monorepo nouvellement créé.

Dans mon cas, cela se produit : https://github.com/storybookjs/storybook/issues/3346#issuecomment -475437230

J'ai modifié Storybook Webpack config pour exclure node_modules dans "Lerna" packages de la compilation Babel . Mais le problème est toujours là je pense.

J'ai fermé sur la base du commentaire de @idbartosz . Pensez-vous qu'il est toujours cassé @Lighttree ?

Désolé pour la confusion, j'ai basé ma réponse sur la configuration de Lerna où les packages requis sont hissés à la racine et y sont installés en tant que dépendances de développement. Je n'ai donc pas rencontré le problème de l'analyse de leur node_modules .

Il semble que certains utilisateurs aient un cas d'utilisation où ils ont installé des packages plus profondément dans l'arborescence comme /lib/components/node_modules https://github.com/storybookjs/storybook/issues/3346#issuecomment -475437230 et babel-loader essaie de les analyser.

Par défaut, storybook exclut la racine node_modules mais peut-être vaut-il la peine de tous les exclure.

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 Je suis également confronté à cette erreur, avec react-motion dans le référentiel mono-repo lerna .
la solution @idbartosz a-t-elle résolu le problème ?

@sayjeyhi ouais, ça devrait. Ce n'est pas vraiment un problème Storybook . Cela se produit simplement parce que lorsque vous travaillez dans monorepo , vous avez non seulement node_modules dans la racine de votre projet, mais également dans */packages , qui n'est pas exclu par défaut. (En fait, je ne suis pas sûr que ce ne soit pas le cas, car c'est monorepo spécifique à l'organisation. Si vous créez votre Storybook en tant que package dans le dossier Lerna packages , vous avez gagné je n'ai pas ce problème)

Donc, pour mon cas, je viens de faire ceci dans .storybook/webpack.config.js :

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;
};

quelqu'un a-t-il réellement montré sa solution de contournement proposée pour l'exemple de reproduction que j'ai créé?

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

semble que cela répondrait définitivement à la question.

Je peux voir que presque tout le monde ici avec un monorepo utilise lerna , j'ai un monorepo qui utilise yarn workspaces plutôt que lerna et tout fonctionne correctement avec la dernière version de storybook + typescript , et sans configurations étranges webpack , cela devrait également fonctionner correctement avec babel.

Si vous montrez un certain intérêt, je peux créer un monorepo avec un storybook fonctionnel, je peux voir sur les fichiers de @busticated que certains scripts s'exécutent dans le mauvais ordre et que certaines dépendances sont en le package.json incorrect, je ne dis pas que cela cause des problèmes, mais cela pourrait être le cas.

@pixeleate

Je peux voir sur les fichiers de @busticated , certains scripts s'exécutent dans le mauvais ordre et certaines dépendances sont dans le mauvais package.json

Peux-tu être plus précis?

aussi, gardez à l'esprit que j'ai une version _working_ de mon exemple de dépôt exécutant un livre de contes v3 comme indiqué ici https://github.com/storybookjs/storybook/issues/3346#issuecomment -513397002

@pixeleate Cela vous dérangerait-il de partager votre dépôt de travail ?

Je peux voir que presque tout le monde ici avec un monorepo utilise lerna , j'ai un monorepo qui utilise yarn workspaces plutôt que lerna et tout fonctionne correctement avec la dernière version de storybook + typescript , et sans configurations étranges webpack , cela devrait également fonctionner correctement avec babel.

Si vous montrez un certain intérêt, je peux créer un monorepo avec un storybook fonctionnel, je peux voir sur les fichiers de @busticated , c'est que certains scripts s'exécutent dans le mauvais ordre et certaines @ dépendances sont dans le mauvais package.json , je ne dis pas que cela cause des problèmes, mais cela pourrait être le cas.

babelConfig.exclude.push(/node_modules/); résout le problème pour moi lors de l'exécution start-storybook , mais j'obtiens la même erreur exports is not defined lors de l'exécution de la sortie de build-storybook .

Edit : Résolu en supprimant storybook-addon-jsx .

@busticated j'ai ouvert un PR avec un correctif :
https://github.com/busticated/storybook-monorepo-repo/pull/1

Il y avait quelques importations incorrectes qui étaient le principal problème, je pense.

@jacobrask Je veux changer cela dans le noyau du livre de contes. Mais j'ai peur que cela fasse des ravages si nous changeons cela dans une version mineure.

@shilman Je pense que nous devrions le changer, mais ce devrait être une version majeure

@ndelangen

J'ai ouvert un PR avec un correctif

Merci!

Il y avait quelques importations incorrectes qui étaient le principal problème, je pense

hum. Ouais. me sert bien pour ne pas avoir mis en place eslint 😂🤦‍♂

Cela dit, il semble qu'une fois que vous avez pris en compte les mauvais noms de variables et mis à jour l'utilisation @storybook/addon-backgrounds - comme je l'ai fait sur master ( 1 , 2 , 3 , 4 ) - le seul changement en suspens est utiliser du fil.

Ai-je raison?

edit : voici une branche nettoyée avec juste les modifications requises pour yarn

les espaces de travail de fil hisseront toutes les dépendances à la racine, cela résoudra des tonnes de problèmes.

Dans mon PR : https://github.com/storybookjs/storybook/pull/8822 , j'apporte une modification au livre de contes pour prendre en charge l'exclusion des dossiers MULTIPLE node_modules par défaut.

Comme détaillé ici, je suis assez terrifié à l'idée de déployer ce changement dans une version mineure, tout comme @shilman. Nous avons décidé qu'il valait mieux garder cela jusqu'à la version 6.0.

les espaces de travail de fil hisseront toutes les dépendances à la racine, cela résoudra des tonnes de problèmes.

en supposant que vous utilisez du fil 😉

apporter une modification au livre d'histoires pour prendre en charge l'exclusion des dossiers MULTIPLE node_modules par défaut

est-ce la cause première? appliquer le changement localement ne semble pas résoudre mon problème.

j'obtiens ce qui suit dans la console de mon navigateur :

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

... ce qui est un peu différent je suppose ..? encore une autre erreur que vous voyez tout le temps mais qui a toujours une solution différente 🤦‍♂ _/moi fronce les sourcils dans la direction générale de babel et webpack_ 😬

Je suis assez terrifié à l'idée de déployer ce changement dans une version mineure, tout comme @shilman. Nous avons décidé qu'il valait mieux garder cela jusqu'à la version 6.0.

oh ouais je vous entends - rien de tout cela n'est jamais facile. merci beaucoup pour tout le travail que vous faites ici et ailleurs - le livre de contes (même v3) est un outil incroyablement utile :pray::clap::clap::clap::+1:

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

Cela est probablement dû au fait que Webpack encapsule un module CommonJS avec son wrapper ESM. Webpack utilisera un wrapper ESM s'il détecte une utilisation de import dans le module. Il est généralement causé soit par :

1. Mélanger et faire correspondre ESM et CJS dans votre code source
2. Babel injecte des assistants ESM dans un module CJS

Pour éviter le deuxième cas, vous devrez définir sourceType de Babel sur "unambiguous" pour le forcer à vérifier le type de module en premier.

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

Mise à jour : mon commentaire d'origine est masqué ci-dessus, mais il s'agit de la configuration de base que nous avons utilisée pour résoudre ces problèmes sur plusieurs projets monorepo :

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 quel est l'inconvénient d'utiliser sourceType = 'unambiguous' ?

Merci d'avoir posté la solution de contournement !

Je vais l'utiliser pour améliorer le support monorepo : https://github.com/storybookjs/storybook/pull/8822

(fonctionnalité 6.0.0)

Peut-être sans rapport, mais j'avais ce problème exports is not defined cause de mon babel.config.js personnalisé, la lecture de https://storybook.js.org/docs/configurations/custom-babel-config/ a résolu mon problème particulier problème.

@qrosmeli Merci pour le conseil. Vous avez sauvé ma journée ! 🚀

Huzah !! Je viens de publier https://github.com/storybookjs/storybook/releases/tag/v6.0.0-alpha.0 contenant PR # 8822 qui fait référence à ce problème. Mettez à niveau aujourd'hui pour l'essayer !

Vous pouvez trouver cette préversion sur la balise NPM @next .

Fermeture de ce sujet. Merci de rouvrir si vous pensez qu'il reste encore beaucoup à faire.

[MISE À JOUR] - Nous devons exclure node_modules de cette règle sinon cela cassera la construction

Je l'ai résolu en ajoutant cette règle dans le fichier storybook main.js

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"
      }]
    ]
  }
}]

Parallèlement à cela, vous devrez peut-être également désactiver les validations eslint pour votre dossier dist, donc pour cela, vous pouvez utiliser le script ci-dessous

  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
        ]
      }
    }
  }

Merci @ashvin777 , fonctionne comme un charme :wink:

Hey @aperkaz , j'ai mis à jour la règle pour exclure node_modules , j'ai trouvé que le livre de contes se lançait correctement en mode développement mais se cassait en mode production à cause de ce changement. J'ai donc dû exclure node_modules afin de corriger. Vous pouvez prendre la dernière de mon commentaire mis à jour ci-dessus.

J'ai eu exactement le même problème, et pour moi, la solution consistait à passer de transform-es2015-modules-commonjs à @babel/plugin-transform-modules-commonjs sur babel.config.js .

avant de

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

après

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>'

J'ai passé la journée sur ce problème, j'avais déjà le sourceType: 'unambigous' .

Pour ma part, il n'était pas lié à un dossier node_modules à ignorer puisqu'il s'agit d'un fichier relatif juste à côté.

Une solution de contournement qui fonctionne pour moi consiste à forcer l'option modules: 'cjs' pour le @babel/preset-env .

J'ai aussi ce problème avec @storybook/react@next , la solution finale pour moi était d'ajouter manuellement le plugin babel @babel/plugin-transform-modules-commonjs , tandis qu'avec l'option debug: true sur le @babel/preset-env Je vois que c'est déjà utilisé... Je ne comprends pas mais ça marche.

EDIT : Ce n'est pas une solution car on perd les avantages des modules ESM avec webpack. Je dois forcer la transformation en cjs uniquement pour les versions du livre de contes.

:tada: Mon .storybook/.babelrc : :tada:

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