Storybook: Erro: as exportações não estão definidas

Estou recebendo export 'MatrixEffect' was not found in '../dist/index' no terminal. Mas eu posso importar o módulo em apenas um tempo de execução de nó simples (não posso usá-lo ofc, mas pelo menos eu sei que pode ser importado).

isso pode ajudar, pois ainda não temos documentos oficiais: https://github.com/storybooks/storybook/issues/3270

Isso ainda não está funcionando...

Acabei de encontrar um problema com a mesma mensagem de erro em um livro de histórias depois de ativar os espaços de trabalho do yarn em um projeto lerna. Eu suspeito que isso seja causado por problemas de carregamento de pacotes. Investigando mais.

Parece que tenho o mesmo problema.

Se eu entendi bem o problema, há um problema com a resolução de arquivos .ts do arquivo .js? (Embora eu não entenda por que você está importando seu componente de dist )

Talvez você devesse adicionar .ts / .tsx ao resolve.extensions no seu livro de histórias estendido webpack.config?

@igor-dv Não, eu uso JS. De qualquer forma, alterar o identificador de variável ( variable para Variable ) funciona, de alguma forma.

Estou recebendo este erro sem usar TypeScript, apenas vanilla JS

Eu removi o carregador babel de webpack.config.js na pasta .storybook e funciona bem agora. Eu não uso Typescript embora.

Estou me deparando com isso, no navegador recebo exports is not defined mas no terminal recebo `"export 'default' (importado como '[ComponentName]') não foi encontrado em '@[namespace]/[ nome do pacote]'"

• Usando lerna
• Livro de histórias 3.4.7
• Está tudo bem para meus componentes sem dependências internas
• Se eu tentar importar um módulo com dependência de outro pacote em project/packages o erro aparece
• Estou executando meus scripts de compilação, então ele está tentando obter uma versão common-js do pacote.

Se eu alterar a configuração principal do package.json da dependência interna para a fonte não compilada, tudo funcionará

Portanto, há algo errado com a configuração do webpack do storybook e a importação de cjs para o código do módulo es, ou algo assim ...

Minha correção

Então percebi que apaguei acidentalmente meu campo "module" package.json que apontava para a versão do módulo ES das minhas compilações, adicionando isso de volta faz tudo funcionar novamente. Ainda parece que o storybook deve conseguir puxar a versão cjs, mas meu problema está resolvido 🤷🏽‍♂️

Isso ainda está acontecendo para mim na v4.0.0-alpha.20 com babel 7.0.0

O mesmo aqui @tony. Estou usando o Flow, no entanto.

@ryanflorence Eu tenho exatamente a mesma configuração de lerna e o problema de exportação para o livro de histórias.
Eu tenho um pacote que expõe a versão construída dos UI-Elements.
Desculpe, mas você poderia fornecer mais detalhes quando disser "module" field that pointed to the ES module version of my builds, adding that back in makes everything work again.

este problema pode ser corrigido adicionando o plugin correto no arquivo .babelrc , já que o arquivo tsconfig está configurado para gerar módulos compatíveis com commonjs , precisamos usar o plugin adequado

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

Isso é o que tenho no meu arquivo .babelrc e está tudo funcionando bem, tenho meu arquivo tsconfig com exatamente as mesmas opções e valores.

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

Nota: Esta solução funciona para outro tipo de módulos https://babeljs.io/docs/en/next/plugins#modules

Para mim, o problema é causado pelas mudanças recentes para incluir o babel-loader no 4.0.0.alpha. A configuração padrão do webpack do servidor pode incluir suas compilações commonjs (pacotes, espaços de trabalho): 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

Para mim, uma correção é substituir a declaração padrão do plug-in por um webpack.dev.js personalizado:

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

Omitir include também corrige o problema e não tem efeitos colaterais para mim.

Acho que entendo o que está acontecendo.

O que @psychobolt está dizendo é 100% correto.

Acho que poderíamos fazer melhor para os usuários do monorepo, fazer nossa configuração padrão do webpack para que o acima não aconteça.

Acho que remover include: includePaths, faria isso, mas a questão é qual o custo de desempenho.

Quem tem uma boa sugestão de como melhor resolver isso?

Também nos deparamos com esse problema e levou mais de meio dia lutando contra as configurações para descobrir o que poderia ser. 😢

@cilice Como você resolveu isso?

@0nn0 seguindo https://github.com/storybooks/storybook/issues/3346#issuecomment-425516669 este conselho :)

Estou tendo o mesmo problema com stotybook-4.1.4, projeto Lerna, React 16.7.0, JS simples. Funciona com storybook-4.0.12

Eu tive o mesmo erro no 4.1.4, voltei ao 4.0.10 e funciona bem (sem texto datilografado) babel-webapck

Usar uma configuração modificada para excluir a saída compilada do babel-loader evitará esse problema para projetos Lerna ou monorepo com o pacote de livro de histórias mais recente.

@psychobolt Você poderia fornecer uma configuração de exemplo? Obrigado.

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

Não tenho certeza se isso ajudará mais alguém, mas corrigimos esse problema executando o seguinte:

npm i react-scripts -D

@skeet Eu me perguntei por que o livro de histórias tinha a mensagem

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.

Então, depois de instalar os scripts de reação, agora diz

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

Nós também tivemos o problema exports is not defined algumas vezes e já resolvemos isso substituindo a configuração do Babel como sugerido por outros.

Mas, recentemente, comecei a analisar isso novamente e notei que a propriedade exclude para a regra JS padrão estava sendo resolvida para um caminho absoluto (abaixo está um console.log() da configuração do Webpack gerada):

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

Eu tinha assumido que a propriedade exclude deveria ser um RegExp, então achei estranho! Percebi que, devido à estrutura do nosso projeto, na verdade temos muitas pastas node_modules então tentei atualizar esta linha para um RegExp ( /node_modules/ ) - e corrigiu!

Isso evita transpilar módulos que já foram transpilados - e em particular evita a opção useBuiltins de preset-env de injetar polyfills core-js (removendo a opção useBuiltins ou configurando o ambiente para direcionar os tempos de execução que não exigem polyfills também pode ajudar a evitar esse problema.)

Portanto, existem alguns problemas diferentes em jogo que resultam nesse problema:

1. Dependências em pastas node_modules podem ser transpiladas involuntariamente pelo Babel
2. A opção useBuiltins pode injetar core-js polyfills em seu código no formato errado para o tipo de módulo (consulte https://github.com/babel/babel/issues/7463 e https:// github.com/babel/babel/issues/9187)
3. Se os pacotes estão sendo vinculados por links simbólicos (como em um monorepo), você deve ter muito cuidado para evitar o ponto 1!

Infelizmente não é muito fácil estender a opção de exclusão existente , mas é possível !

Criei um caso de teste reduzido para esse problema com informações sobre como evitá-lo. Vou registrar um problema com a Babel, se necessário.

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

Estamos usando livros de histórias + lerna + texto datilografado. O que resolveu para nós foi misturar @i-like-robots com @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;
};

Temos o mesmo problema, quando ru vai corrigi-lo?

Obtendo este erro em uma nova instalação. Nenhuma pista sobre o que está causando isso (possivelmente em um conflito com o .babelrc entre a configuração create-react-app e esta?).

Consegui corrigir o problema adicionando a seguinte linha ao arquivo .babelrc :

"sourceType": "unambiguous"

Mais informações sobre esta opção: https://babeljs.io/docs/en/options#sourcetype
Acredite, esta opção só está disponível com Babel 7 e superior.

Apenas para passar por este sem entender completamente quais são os problemas das pessoas (desculpas!) - aqui está um trecho da minha configuração do webpack que funciona em torno desse problema, talvez de uma maneira mais simples:

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

@tmeasday Você pode elaborar sua sugestão - ou seja, onde colocar esse código?

Storybook é incrível, mas esse erro tem sido intermitente e terrível. Não consigo encontrar uma rima ou razão para esse erro começar a acontecer. Vou mexer nos componentes e, em seguida, boom, tudo começa a funcionar sem que nenhuma mudança real seja feita. Mas estou preso há uma hora tentando fazer isso funcionar e simplesmente não tenho a menor ideia de por que isso está quebrado.

Por favor, olhe para este problema que parece estar afetando muitas pessoas e é um espetáculo.

Resolvi o problema criando um arquivo .storybook/weback.config.js contendo o seguinte:

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

Parece que se resume à questão sourceType babel. Tentei adicionar um arquivo .babelrc (como sugerido por @0nn0), mas isso pareceu substituir toda a configuração do babel em vez de modificá-la, causando mais problemas.

@JasonTheAdams o trecho de código que escrevi acima iria no .storybook/webpack.config.js . Acho que é parecido com o que você fez.

Aqui está o que eu acho que está acontecendo:

O problema é que os arquivos em node_modules dentro de subprojetos (por exemplo ./lib/components/node_modules ) estão sendo compilados pelo babel. São arquivos que já foram enviados ao NPM e não precisam ser compilados. Em alguns casos, isso causa problemas confusos, talvez sobre como o babel analisa os arquivos.

Minha abordagem é apenas dizer a babel-loader para não compilar nenhum arquivo dentro de qualquer pasta node_modules . Por padrão, ele ignorará ./node_modules para compilar as coisas dentro do node_modules do subprojeto. Então eu adiciono alguns caminhos à lista exclude .

Sua abordagem é configurar babel-loader para usar a detecção sourceType do babel para informar como analisar um arquivo. Isso basicamente funciona em torno de arquivos de análise incorreta do babel. No entanto o babel ainda está rodando em arquivos que não precisam ser compilados, então não sei se é o que você quer?

Eu não sou um especialista, então leve minhas palavras com um grão de sal, mas esse é o meu entendimento, tendo trabalhado com problemas semelhantes.

Depois de aplicar a sugestão do @skeet (https://github.com/storybooks/storybook/issues/3346#issuecomment-459308703) o problema retornou quando comecei a referenciar um pacote como uma dependência (não peer ou dev) de alguns outros .

Colocar o campo module no package.json da dependência como na correção do @ryanflorence (https://github.com/storybooks/storybook/issues/3346#issuecomment-415982589) fez o trabalho.

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

@tmeasday Entendi. Estou começando a envolver minha cabeça em torno deste assunto. O que é complicado é que, na minha situação, eu realmente quero que ele compile o filho node_modules , pois é onde estou desenvolvendo os próprios componentes, tratando-o como um pacote separado.

Acho que a sugestão de @skeet , como ecoada por @jcousins-ynap, é provavelmente a melhor solução aqui. Não queremos que o Storybook faça suposições sobre como os sub-pacotes são tratados (ou seja, ignorando seus node_modules). Se alguém não quisesse os submódulos node_modules compilados, eles provavelmente não teriam instalado as dependências do pacote para começar.

Parece que tudo se resume à capacidade do babel + webpack de reconhecer os módulos CommonJS vs ES6, o que não parece ser perfeito. Adicionar o campo "module": ao $#$2 package.json #$ do sub-pacote informa explicitamente ao babel que o pacote usa módulos ES6, que é a maneira mais segura de abordar isso.

Obrigado por sua atenção a isso!

Também quero entrar na conversa aqui. Usando Storybook 5, Babel 7.4 (com core-js 3), TypeScript 3.4 e um monorepo. A maioria dessas sugestões não funcionou 100%, mas algo que percebi funcionou. A própria natureza dos monorepos é que um pacote está importando os arquivos "construídos" de outro pacote, não os arquivos de origem, o que é verdade quando na camada do módulo de registro/nó do NPM, mas em desenvolvimento, é bastante irritante. Para contornar isso, defini aliases do Webpack que encaminhavam lib/ para src/ , e tudo funcionou, especialmente porque todo o código agora é ESNext/ESM!

Aqui está o 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`;
});

E para que o Babel + TS funcione, optei por alterar o babel-loader existente em vez de adicionar um novo, pois minha configuração local do Babel não é 100% compatível com a do Storybook, mas sua própria configuração é.

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

Tive o mesmo problema, também devido à remoção do campo module .
Adicionar @babel/plugin-transform-modules-commonjs ao plugin babel ajudou, conforme descrito neste comentário: https://github.com/storybooks/storybook/issues/3346#issuecomment -423719241

@elado work!

totalmente frustrado por este também. passei os últimos ~ 2 dias tentando sem sucesso todas as sugestões deste tópico, bem como algumas das minhas. nenhum teve sucesso 😢

enfim, fico com:

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

...ao iniciar o livro de histórias e...

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)

...ao visualizar a interface do usuário do livro de histórias (http://localhost:9001). minhas histórias não carregam.

fwiw, aqui está minha configuração:

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

tudo dentro do diretório ./src dos componentes usa importações/exportações no estilo ESM. o @my-monorepo/one depende de @my-monorepo/two . na hora da instalação, lerna _links_ a dependência (via lerna bootstrap ). todos os pacotes são construídos usando babel - o comando de nível superior npm run build gera os diretórios ./dist individuais e seus conteúdos. npm start primeiro constrói os componentes, então inicia o livro de histórias.

na v3 tudo isso funcionou bem - embora sempre tenha sido um pouco estranho ter que construir os componentes primeiro. eu recebo _por que_ embora - package.json inclui "main: "dist/index.js" então sem isso o livro de histórias informaria que @my-monorepo/two não pôde ser encontrado ao tentar construir (uma vez que @my-monorepon/one depende nele). mas por outro lado, eu estava feliz com a configuração.

uma coisa que notei: quando adicionei "module": "src/index.jsx" aos arquivos package.json dos componentes, ele se livrou do aviso do webpack, mas o ReferenceError: exports is not defined do lado do cliente permaneceu. encontrei alguém relatando o mesmo erro, mas sem resolução.

vou ficar com o storybook v3 por enquanto, mas vou ficar de olho neste tópico e felizmente tentar qualquer sugestão :pray::+1:

@busticated parece que você pode ter um repositório de reprodução que você poderia compartilhar, eu poderia dar uma olhada?

@ndelangen obrigado por dar uma olhada :pray: meu repositório não é público atm infelizmente. tentei compartilhar os detalhes relevantes acima, mas enquanto isso posso tentar criar um exemplo de trabalho, se isso for útil. pode demorar um pouco embora. caso contrário, feliz em tentar sugestões, etc.

@busticated eu ficaria feliz em dar uma olhada em um monorepo-repro-repo 🙈

É provável que:

• alguns arquivos são analisados ​​pelo babel duas vezes
• alguns arquivos são analisados ​​através de carregadores que não são compatíveis entre si
• alguns arquivos são compilados usando a configuração do babel/ts errada
• algumas outras travessuras monorepo

Infelizmente ReferenceError: exports is not defined não nos diz nada além disso, algo não é como deveria ser.

@ndelangen ok, aqui está o repo repo 😂

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

você deve ser capaz de simplesmente:

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

...e veja o livro de histórias tentar carregar no navegador. abra o console das ferramentas de desenvolvimento e você verá o erro exports .

par de notas:

• execute npm run build para testar a compilação de pré-publicação
• deve funcionar nas versões node / npm +/- algum ruído de arquivo de bloqueio (fwiw, usei node@8 e npm@5 para alinhar com o trabalho do dia)
• os dois últimos commits adicionam os campos "module": "src/index.jsx" packages/*/packge.json aos arquivos packages/*/packge.json. se você reverter isso, verá o aviso original do webpack export 'default' (imported as 'Two') was not found .

vou tentar dar uma olhada o quanto antes

Estou usando o Lerna, os pacotes internos são empacotados pelo Webpack com saída libraryTarget: 'commonjs2' . A abordagem baseada no comentário @JasonTheAdams funciona para mim. Eu também testei a solução @0nn0 com babelrc { "sourceType": "unambiguous" } e também funciona, mas é necessário ter .babelrc na raiz do pacote.

Alguma configuração básica - talvez ajude alguém 😉(Storybook: 5.1.10, Lerna: 3.16.4, Webpack: 4.39.1, Babel: 7.5.5)

arquivo: _lerna_repo/.storybook/webpack.config.js_ - não existe por padrão

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

  babelLoader.options.sourceType = 'unambiguous'

  return config;
};

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

arquivo: _lerna_repo/packages/examplePackage/package.json_

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

arquivo: _lerna_repo/packages/examplePackage/dist/index.js_ - gerado pelo Webpack

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

@ndelangen Alguma atualização sobre o acima?

Recebi o erro "exports não está definido" ao tentar "importar" um módulo no estilo CommonJS. Definir a opção sourceType do Babel como "sem ambiguidade", como sugerido por outros, funcionou.

Este não é realmente um problema com o Storybook, mais ainda uma consequência de estar preso no meio de especificações de dois módulos.

Parece ser corrigido na versão 5.2

Olá pessoal, ele é fixo mesmo?

Estou usando 5.2.1 e tenho esse problema no recém-criado Lerna monorepo .

No meu caso isso está acontecendo: https://github.com/storybookjs/storybook/issues/3346#issuecomment -475437230

Modifiquei Storybook Webpack config para excluir node_modules em "Lerna" packages da compilação de Babel . Mas a questão ainda está lá, eu acho.

Fechei com base no comentário do @idbartosz . Você acha que ainda está quebrado @Lighttree ?

Desculpe por trazer confusão, baseei minha resposta na configuração do Lerna, onde os pacotes necessários são içados para a raiz e instalados lá como dependências de desenvolvimento. Portanto, não tive o problema de analisar seus node_modules .

Parece que alguns usuários têm um caso de uso em que instalaram pacotes mais profundos na árvore, como /lib/components/node_modules https://github.com/storybookjs/storybook/issues/3346#issuecomment -475437230 e babel-loader tenta analisá-los.

Por padrão, o storybook exclui o root node_modules mas talvez valha a pena excluir todos eles.

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 Estou enfrentando esse erro também, com react-motion em lerna repositório mono-repo.
A solução @idbartosz corrigiu o problema?

@sayjeyhi sim, deveria. Este não é realmente um problema Storybook . Isso acontece apenas porque quando você trabalha em monorepo , você tem node_modules não apenas na raiz do seu projeto, mas também em */packages , que não é excluído por padrão. (Na verdade, não tenho certeza se não deveria, porque é monorepo específico da organização. Se você criar seu Storybook como package na pasta Lerna packages você ganhou não tem esse problema)

Então, para o meu caso, acabei de fazer isso em .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;
};

alguém realmente mostrou sua solução alternativa proposta corrige o exemplo de reprodução que eu criei?

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

parece que isso responderia definitivamente à pergunta.

Eu posso ver que principalmente todos aqui com um projeto monorepo estão usando lerna , eu tenho um projeto monorepo que usa yarn workspaces em vez de lerna e tudo está funcionando bem com a versão mais recente de storybook + typescript , e sem configurações estranhas webpack , deve funcionar bem com babel.

Se você mostrar algum interesse eu posso criar um monorepo com um storybook funcionando, posso ver nos arquivos do @busticated , é que alguns scripts rodam na ordem errada e algumas dependências estão em o package.json incorreto, não estou dizendo que está causando problemas, mas pode ser.

@pixeleate

Eu posso ver nos arquivos do @busticated , alguns scripts são executados na ordem errada e algumas dependências estão no package.json incorreto

você pode ser mais específico?

Além disso, lembre-se de que tenho uma versão _working_ do meu repositório de exemplo executando o storybook v3 conforme observado aqui https://github.com/storybookjs/storybook/issues/3346#issuecomment -513397002

@pixeleate Você se importaria de compartilhar seu repositório de trabalho?

Eu posso ver que principalmente todos aqui com um projeto monorepo estão usando lerna , eu tenho um projeto monorepo que usa yarn workspaces em vez de lerna e tudo está funcionando bem com a versão mais recente de storybook + typescript , e sem configurações estranhas webpack , deve funcionar bem com babel.

Se você mostrar algum interesse eu posso criar um monorepo com um storybook funcionando , eu posso ver nos arquivos do @busticated , é que alguns scripts rodam na ordem errada e algumas @ dependências são no package.json incorreto, não estou dizendo que isso está causando problemas, mas pode ser.

babelConfig.exclude.push(/node_modules/); corrige o problema para mim ao executar start-storybook , mas recebo o mesmo erro exports is not defined ao executar a saída de build-storybook .

Editar: Resolvido removendo storybook-addon-jsx .

@busticated eu abri um PR com uma correção:
https://github.com/busticated/storybook-monorepo-repo/pull/1

Houve algumas importações incorretas que foram o principal problema, eu acho.

@jacobrask Eu quero mudar isso no núcleo do livro de histórias. Mas estou com medo de causar estragos se mudarmos isso em uma versão menor.

@shilman Acho que devemos mudar isso, mas deve ser um grande aumento de versão

@ndelangen

Eu abri um PR com uma correção

obrigado!

Houve algumas importações incorretas que foram o principal problema, eu acho

hum. sim. me serve bem por não configurar eslint 😂🤦‍♂

Dito tudo isso, parece que uma vez que você considera os nomes de variáveis ​​ruins e atualizou o uso @storybook/addon-backgrounds - como eu fiz em master ( 1 , 2 , 3 , 4 ) - a única alteração pendente é para usar o fio.

estou correcto?

edit: aqui está um branch limpo com apenas as alterações necessárias para yarn 👉 https://github.com/busticated/storybook-monorepo-repo/commit/4fb2cac0f05b65a5983f121b92a7c2d7438d8857

Os espaços de trabalho do yarn irão içar todas as dependências para a raiz, isso resolverá vários problemas.

No meu PR: https://github.com/storybookjs/storybook/pull/8822 eu faço uma alteração no storybook para suportar a exclusão de pastas node_modules MÚLTIPLAS por padrão.

Conforme detalhado lá, estou com muito medo de lançar essa mudança em uma versão menor, assim como @shilman. Decidimos que é melhor segurar isso até 6.0.

Os espaços de trabalho do yarn irão içar todas as dependências para a raiz, isso resolverá vários problemas.

supondo que você use fios 😉

faça uma alteração no livro de histórias para suportar a exclusão de várias pastas node_modules por padrão

essa é a causa raiz? aplicar a alteração localmente não parece resolver meu problema.

estou recebendo o seguinte no console do meu navegador:

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

...que é um pouco diferente, eu acho..? mais um erro que você vê o tempo todo, mas sempre tem uma solução diferente 🤦‍♂ _/me franze a testa na direção geral do babel e do webpack_ 😬

Estou com muito medo de lançar essa mudança em uma versão menor, assim como @shilman. Decidimos que é melhor segurar isso até 6.0.

oh sim eu ouço você - nada disso é fácil. muito obrigado por todo o trabalho que você faz aqui e em outros lugares - o livro de histórias (mesmo v3) é uma ferramenta incrivelmente útil :pray::clap::clap::clap::+1:

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

Isso é provavelmente causado pelo Webpack envolvendo um módulo CommonJS com seu wrapper ESM. O Webpack usará um wrapper ESM se houver algum uso de import no módulo. Geralmente é causado por:

1. Misturando e combinando ESM e CJS em seu código-fonte
2. Babel injetando ajudantes ESM em um módulo CJS

Para evitar o segundo caso, você precisará definir sourceType do Babel para "unambiguous" para forçá-lo a verificar primeiro o tipo de módulo.

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

Atualização: meu comentário original está oculto acima, mas esta é a configuração básica que usamos para resolver esses problemas em vários projetos 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 qual é a desvantagem de usar sourceType = 'unambiguous' ?

Obrigado por postar a solução!

Vou usar isso para melhorar o suporte ao monorepo: https://github.com/storybookjs/storybook/pull/8822

(recurso 6.0.0)

Talvez não relacionado, mas eu estava tendo esse problema exports is not defined por causa do meu babel.config.js personalizado, lendo https://storybook.js.org/docs/configurations/custom-babel-config/ resolveu meu particular problema.

@qrosmeli Obrigado pela dica. Você salvou meu dia! 🚀

Huzá!! Acabei de lançar https://github.com/storybookjs/storybook/releases/tag/v6.0.0-alpha.0 contendo o PR nº 8822 que faz referência a esse problema. Atualize hoje para experimentá-lo!

Você pode encontrar este pré-lançamento na tag @next NPM.

Fechando este assunto. Por favor, reabra se você acha que ainda há mais a fazer.

[ATUALIZADO] - Temos que excluir node_modules desta regra, caso contrário, quebrará a compilação

Eu resolvi isso adicionando esta regra no arquivo main.js do livro de histórias

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

Junto com isso, você também pode precisar desabilitar as validações eslint para sua pasta dist, então, para isso, você pode usar o script abaixo

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

Obrigado @ashvin777 , funciona como um encanto :wink:

Ei @aperkaz , atualizei a regra para excluir node_modules , descobri que o livro de histórias estava sendo iniciado corretamente no modo de desenvolvimento, mas interrompendo o modo de produção por causa dessa alteração. Então eu tive que excluir node_modules para corrigir. Você pode tirar as últimas notícias do meu comentário atualizado acima.

Eu tive exatamente o mesmo problema e, para mim, a solução foi mudar de transform-es2015-modules-commonjs para @babel/plugin-transform-modules-commonjs em babel.config.js .

antes de

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

depois de

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

Passei o dia nessa questão, já tinha o sourceType: 'unambigous' .

De minha parte, não foi vinculado a uma pasta node_modules para ser ignorada, pois é um arquivo relativo ao lado.

Uma solução alternativa que funciona para mim é forçar a opção modules: 'cjs' para o @babel/preset-env .

Eu também tenho esse problema com @storybook/react@next , a solução final para mim foi adicionar manualmente o plugin babel @babel/plugin-transform-modules-commonjs , enquanto com a opção debug: true no @babel/preset-env Vejo que já é usado... Não entendi, mas funciona.

EDIT: Esta não é uma solução porque perde os benefícios dos módulos ESM com webpack. Eu preciso forçar a transformação para cjs apenas para as compilações do livro de histórias.

:tada: Meu .storybook/.babelrc : :tada:

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