Storybook: Conserver le chemin du répertoire statique dans la construction

Créé le 7 mars 2017  ·  57Commentaires  ·  Source: storybookjs/storybook

Dans mon répertoire racine, j'ai un nom de dossier statique public qui est servi comme chemin /public/... depuis mon serveur de nœuds. Cela signifie que les images et les fichiers CSS sont servis avec ce préfixe /public/ .

Mais quand j'utilise StoryBook avec la commande: start-storybook -p 6006 -s ./public
Le chemin avec /public/ n'est plus disponible.
J'ai donc changé la commande en start-storybook -p 6006 -s ./ pour servir le répertoire racine, et tout va bien.

Mais quand je construis mon livre d'histoires avec la commande build-storybook -s ./ le script copiera tous les fichiers du répertoire racine vers le storybook-static .
Et si je change la commande en build-storybook -s ./public , le chemin avec le préfixe /public/ ne sera plus disponible.

Existe-t-il un moyen de spécifier le chemin du répertoire statique?

feature request has workaround help wanted

Commentaire le plus utile

Pensez-vous qu'une solution comme start-storybook -p 6006 -s "./public:/static" pour servir des fichiers statiques de ./public sur le chemin /static sera implémentée? Cela conduirait à des utilisations extrêmement flexibles et correspondrait aux conventions de mappage de chemins de Docker que beaucoup d'entre nous connaissent déjà.

Tous les 57 commentaires

Hmm donc ce problème concerne build-storybook c'est quelque chose que je devrais examiner comment cela fonctionne.

Vous pourriez essayer un middleware personnalisé? Je ne suis pas sûr que cela fonctionnera, mais cela pourrait.
https://github.com/storybooks/react-storybook/pull/435#issuecomment -264813688
https://github.com/storybooks/react-storybook/blob/master/src/server/middleware.js#L35

: +1: Ceci est un problème - pas pour la construction de livre d'histoires mais juste pour l'utilisation pour le développement.

Voici comment je l'ai fait fonctionner avec le middleware:

const express = require('express');
const path = require('path');
const paths = require("../config/paths");

const expressMiddleWare = (router) => {
    console.log(path.join(__dirname), paths.appPublic);
    router.use('/public', express.static(paths.appPublic))
};

module.exports = expressMiddleWare;

J'essaierai d'obtenir un PR pour cela mais je ne sais pas si j'ai le temps atm

Merci d'avoir partagé votre solution! ❤️

Salut à tous! On dirait qu'il n'y a pas eu grand-chose dans ce numéro ces derniers temps. S'il y a encore des questions, des commentaires ou des bugs, n'hésitez pas à poursuivre la discussion. Malheureusement, nous n'avons pas le temps d'aborder tous les problèmes. Nous sommes toujours ouverts aux contributions, veuillez donc nous envoyer une demande de tirage si vous souhaitez aider. Les problèmes inactifs seront résolus après 60 jours. Merci!

Hé là, c'est encore moi! Je vais fermer ce numéro pour aider nos responsables à se concentrer sur la feuille de route de développement actuelle. Si le problème mentionné est toujours un problème, veuillez ouvrir un nouveau ticket et mentionner l'ancien. Bravo et merci d'utiliser Storybook!

Salut! @ndelangen @hansthinhle @patrickgordon

Im face au même problème. Cela a-t-il déjà été résolu?

Merci!

salut @aviramga - ma solution que j'ai postée quelques-uns l'a résolue pour nous. Je n'ai jamais fait de relations publiques pour le résoudre.

Je pourrais encore faire ça maintenant que ma mémoire a été rafraîchie :)

Salut @patrickgordon. Malheureusement, mon problème ne concerne que build-storybook: /

Je l'utilise avec un outil appelé Percy pour trouver les problèmes d'interface utilisateur dans mon application.

Avez-vous réussi à trouver une solution pour la construction?

On dirait que vous pouvez contourner ce problème en utilisant des liens symboliques:

Ajoutez un répertoire avec un nom arbitraire (par exemple static-link , et mettez-y un fichier appelé public (sans aucune extension) avec le contenu suivant:

../public

Ensuite, vous devriez pouvoir réaliser ce dont vous avez besoin avec -s static-link

@Hypnosphi merci pour le tuyau! cela ne semble pas fonctionner cependant.
Pouvez-vous expliquer comment cela fonctionne?

Tous mes fichiers statiques sont dans un répertoire nommé "statique" (non public).
J'ai essayé des moyens qui n'ont pas fonctionné:

  1. Créez un répertoire arbitraire avec un fichier nommé "static" et ../static - erreur de construction casée lorsque j'ai exécuté build-storybook
  2. Identique à ci-dessus mais avec un fichier nommé "public" - toujours pas d'image

Aucun conseil?

Merci

Quel système d'exploitation utilisez-vous?
https://en.wikipedia.org/wiki/Symbolic_link#Overview

Quelle était l'erreur?

Mac haute sierra

@Hypnosphi mais juste pour m'assurer de bien comprendre, pour adapter votre exemple à mon cas d'utilisation, j'ai besoin de créer un nouveau répertoire, par exemple un lien statique dedans mettre un fichier nommé static et y écrire ../static

Correct?

OK, il semble que mes instructions pour créer un lien symbolique étaient incorrectes. La bonne façon est la suivante:

mkdir static-link
ln -s static static-link/static

Cela créera un "fichier" dans le répertoire de lien statique qui peut être partagé dans git (cela ne fonctionnera pas sous Windows cependant)

@Hypnosphi je vais

Non, ça devrait être persistant

@Hypnosphi non , ne fonctionne toujours pas. Pendant la construction, j'obtiens un journal qui dit:
cp: aucun fichier ou répertoire de ce type: lien-statique / statique

J'ai suivi vos instructions ci-dessus. J'ai donc un répertoire vide appelé static-link avec un lien symbolique de static à static-link / static

Qu'est-ce que je fais mal?

Je vous remercie vraiment d'avoir pris le temps d'aider :)

Et vous utilisez l'option -s static-link , non?

@Hypnosphi vous voulez dire build-storybook -c .storybook -s static-link ?

Oui

je fais

Désolé, j'ai mal tapé:

ln -s ../static static-link/static

@Hypnosphi
pourquoi ../statique?

Ai-je raison de dire que le répertoire de liens statiques est vide?
Vous souhaitez peut-être essayer de passer à une conversation privée et publier ici nos résultats finaux? J'ai l'impression que nous sommes très proches et que c'est juste une mauvaise communication :)

C'est le chemin relatif entre l'emplacement du lien et la cible du lien

@Hypnosphi J'ai pu le faire fonctionner en utilisant un chemin absolu ..... mais je dois le faire fonctionner avec un chemin relatif car je voudrais implémenter la même logique dans le sémaphore

@Hypnosphi a trouvé une solution de contournement. Merci beaucoup pour toute votre aide, vous sauvez la vie !!

une astuce pour résoudre ce problème?

Oui, exécutez simplement la solution suggérée ci-dessus. Travailler avec un lien symbolique
ln -s /<absolute-path-your-static-directory> storybook-static-symlink/static

@aviramga est-ce que cette méthode fonctionne toujours pour vous? Je n'ai aucune chance d'utiliser un lien symbolique.

Ma structure de dossiers

|- docs
  |- folders-with-images
|- sandbox (holds my storybook files)
|- src
  |- README.md with image paths `/docs/folder/image.png`

Je peux faire fonctionner cela lors de la diffusion du livre d'histoires start-storybook -c sandbox -s sandbox,docs -p 6006 aide d'un fichier middleware:

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

module.exports = router => {
  router.use('/docs', express.static(path.join(__dirname, '..', 'docs')));
}

Mais ajouter un lien symbolique en utilisant ln -s /docs sandbox/docs et en exécutant build-storybook -c sandbox -s sandbox,docs -o storybook ne fonctionne toujours pas.

Les dossiers dans docs sont copiés mais comme le chemin du fichier dont j'ai besoin est /docs/folder/image.png les images 404.

Également réussi à utiliser un lien statique pour résoudre ce problème:

package.json:

"scripts": {
  "storybook": "(mkdir ./src/static-link || true) && (ln -s ../static ./src/static-link/static || true) && start-storybook -p 6006 -s ./src/static-link"
}

Je déconseille de créer le lien symbolique via le script package.json pour des raisons de compatibilité, au cas où tous les développeurs n'utilisent pas le même système d'exploitation.

Comme alternative, je suggère d'utiliser le plugin copy-webpack-plugin dans le fichier .storybook / webpack.config.js , comme ceci:

const path = require('path');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = config => {
  function resolve(dir) {
    return path.join(__dirname, '..', dir);
  }

  // Other configuration properties

  config.plugins.push(
    new CopyWebpackPlugin([
      {
        from: path.resolve(__dirname, 'static-foo'),
        to: '.'
      },
      {
        from: path.resolve(__dirname, '../static-bar'),
        to: './bar'
      }
    ])
  );

  return config;
}

Ceci par exemple monterait le contenu du répertoire .storybook/static-foo vers http://localhost:6006/ et le contenu de static-bar vers http://localhost:6006/bar/ .

Notez également l'utilisation de push pour ajouter au tableau plugins pour éviter d'écraser d'autres plugins, ce qui pourrait casser la configuration de votre Storybook Webpack.

Pour référence future, les liens symboliques sont parfaitement utilisables. Si vous voulez / devez les utiliser avec des chemins relatifs, alors vous utilisez simplement le commutateur -r comme ceci: ln -rs dir1 dir2

Je pense personnellement que si un livre de contes juge bon de copier un répertoire statique entier, cela devrait être clairement indiqué dans la documentation. Sinon, ce comportement doit être remplacé par celui qui crée les liens symboliques appropriés à la place. J'ai découvert le problème de la copie car il plantait mon serveur en raison d'une utilisation excessive de l'espace disque!

Donc, fondamentalement, il n'y a pas de solution officielle intégrée et toutes les «solutions» ne sont que des hacks merdiques aléatoires :)

Je déconseille de créer le lien symbolique via le script package.json pour des raisons de compatibilité, au cas où tous les développeurs n'utilisent pas le même système d'exploitation.

Comme alternative, je suggère d'utiliser le plugin copy-webpack-plugin dans le fichier .storybook / webpack.config.js , comme ceci:

const path = require('path');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = config => {
  function resolve(dir) {
    return path.join(__dirname, '..', dir);
  }

  // Other configuration properties

  config.plugins.push(
    new CopyWebpackPlugin([
      {
        from: path.resolve(__dirname, 'static-foo'),
        to: '.'
      },
      {
        from: path.resolve(__dirname, '../static-bar'),
        to: './bar'
      }
    ])
  );

  return config;
}

Ceci par exemple monterait le contenu du répertoire .storybook/static-foo vers http://localhost:6006/ et le contenu de static-bar vers http://localhost:6006/bar/ .

Notez également l'utilisation de push pour ajouter au tableau plugins pour éviter d'écraser d'autres plugins, ce qui pourrait casser la configuration de votre Storybook Webpack.

cela ne fonctionne pas;)

c'est une configuration de travail:

.storybook / webpack.config.js
(en supposant que le dossier statique se trouve sur le dossier racine du projet)

const path = require('path');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = async ({ config }) => {

  function resolve(dir) {
    return path.join(__dirname, '..', dir);
  }

  // Other configuration properties

  config.plugins.push(
    new CopyWebpackPlugin([
      {
        from: path.resolve(__dirname, '../../static'),
        to: './static'
      }
    ])
  );

  return config;
}

@mtrabelsi ne fonctionne pas pour moi pour certaines raisons ...

De plus, je suppose que vous avez un type puisque votre dossier .storybook se trouve au premier niveau à partir du root , pas au double. Donc, vous devez passer à:
from - from: path.resolve(__dirname, '../../static')
to - from: path.resolve(__dirname, '../static')

"copie-webpack-plugin": "^ 5.0.4"
Tous les chemins sont bons. Revérifié.

Mettre à jour
J'ai découvert avec @BradMcGonigle la réponse supérieure en créant le fichier middleware.js dans mon dossier .storybook/ :

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

module.exports = router => {
  router.use('/docs', express.static(path.join(__dirname, '..', 'docs')));
}

@BiosBoy pour éviter toute confusion voici rapidement une idée sur la structure de mon projet (seulement ce que vous devez savoir):

My_sweet_projet_ROOT_DIR / components / .storybook / webpack.config.js
My_sweet_projet_ROOT_DIR / static

J'utilise également next.js comme application principale où il consomme des composants de réaction du dossier de composants.

Voici ma configuration (vous pourriez la reproduire de votre côté - je vous fais confiance: D)

My_sweet_projet_ROOT_DIR / package.json

{
  "name": "sweet_like_butter",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@zeit/next-css": "^1.0.1",
    "next": "^8.1.0",
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "styled-components": "^4.2.0"
  },
  "scripts": {
    "dev": "next",
    "build": "next build",
    "start": "next start"
  },
  "devDependencies": {
    "babel-plugin-styled-components": "^1.10.0"
  }
}

My_sweet_projet_ROOT_DIR / next.config.js

const withCSS = require('@zeit/next-css')
module.exports = withCSS()

J'ai pu contourner un problème similaire en utilisant une balise de base:

  1. créez un fichier manager-head.html dans votre répertoire .storybook. https://storybook.js.org/docs/configurations/add-custom-head-tags/
  2. ajouter
<head>
  <script>
    const hostname = window.location.hostname
    if (hostname !== "" && hostname !== "localhost") {
      const script = document.createElement('base')
      script.href = '/storybook-static/'
      document.getElementsByTagName('head')[0].appendChild(script)
    }
  </script>
</head>

(avec script.href = vers quel que soit le chemin souhaité)

les fichiers dans index.html sont maintenant récupérés avec le préfixe spécifié

Ce comportement ne devrait-il pas être intégré dans Storybook, où si vous marquez -s ./static alors vos chemins fonctionneront de la même manière dans Storybook qu'en production? Cela semble absurde que lorsque je dis à Storybook que mon répertoire statique est ./static , que mes chemins relatifs, par exemple ./static/image.png doivent à la place être ./image.png ou utiliser un lien symbolique loufoque 🤔

@eckmLJE Si vous utilisez l'extrait que j'ai posté ci-dessus, cela devrait fonctionner sans configuration Webpack supplémentaire ni lien symbolique. Nous pourrions cependant examiner la possibilité de générer cela automatiquement dans le cadre du processus de construction.

Je suis toujours confronté au problème en 2020 ...
Mon cas est très simple: mon package.json a ce script: "storybook": "start-storybook -s ./dist/img -p 8888"

Donc, quand j'exécute npm run storybook , il affiche info => Loading static files from: /home/vagrant/projects/MySuperProject/web/themes/ofb/ofb_ui/dist/img .

mais quand j'essaye d'accéder à un fichier dans le répertoire dist/img depuis le navigateur avec cette URL, cela ne fonctionne pas: http://localhost:8888/myImage.png ...

Alors les gars, est-ce un bug ou est-ce que je fais quelque chose de mal?

@ndelangen pensez -vous que nous pouvons intégrer cela dans les changements de rupture 6.0? Je pense que ce serait une bonne solution, mais une solution de rupture.

On dirait que l'api de CopyWepbackPlugin a changé et vous devez ajouter une clé pattern à la solution @mtrabelsi comme ça:

const path = require('path');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = async ({ config }) => {
  config.plugins.push(
    new CopyWebpackPlugin({
      pattern: [
        {
          from: path.resolve(__dirname, '../../static'),
          to: './static'
        }
      ]
    })
  );

  return config;
}

J'ajouterai mes deux cents liés à ce problème. Bien que je pense que cela soit étroitement lié, ma solution diffère de @mtrabelsi en ce sens que la simple copie de mes actifs dans le répertoire ./static résultant de la commande build-storybook n'était pas suffisante. Plus précisément, si je déploie l'application statique sur un serveur Tomcat qui sert l'application statique à partir de http://example.com/docs , où docs est un répertoire situé dans les applications Web Tomcat / sur le serveur.

En raison du sous-chemin, aucun des fichiers en dehors du répertoire / css dans le répertoire / static n'était chargé. J'utilise des chemins relatifs pour les images et les polices (ce sont les actifs statiques qui ne parvenaient pas à charger sur la version déployée). Ainsi, des requêtes comme https://example.com/img/path/to/my/image échoué, alors qu'elles auraient dû être ajoutées / static, ie. https://example.com/static/img/path/to/my/image Mes solutions, comme je l'ai dit, sont très proches de @mtrabelsi mais je

const path = require('path');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = async ({ config }) => {

  function resolve(dir) {
    return path.join(__dirname, '..', dir);
  }

  // Other configuration properties

  config.plugins.push(
    new CopyWebpackPlugin({
      pattern: [
        {
          from: path.resolve(__dirname, './_assets'), // My static font and images are located in the .storybook dir
          to: './' // Drop both the fonts/ and img/ directory into the root of the build output.
        }
      ]
    })
  );

  return config;
}

Après cela, les images et les polices ont été chargées de manière appropriée.

@tmeasday suggère: pourquoi ne pouvons-nous pas en faire une option main.js afin qu'elle apparaisse à la fois dans start-storybook et build-storybook

@ vcastro45 J'ai testé cela à la fois pour start-storybook et build-storybook, et cela semble fonctionner (testé sur la branche next ).

Pourriez-vous me créer un repo de reproduction?

@shilman C'est possible, mais nous devrons soulever la configuration prédéfinie de
https://github.com/storybookjs/storybook/blob/9ea455a1746c489b7364448212663f2445af8a8b/lib/core/src/server/manager/manager-config.js#L101 -L102

à avant ici:
https://github.com/storybookjs/storybook/blob/19c2420db80fcb3b89b34cdbbe03bf9010b0b3b2/lib/core/src/server/build-static.js#L190 -L191

Et puis transmettez-le à toutes les fonctions inférieures de la chaîne build / dev.
C'est tout un refactor, pas quelque chose que je peux faire en 1 jour.

Ce serait aussi un autre moment où nous voudrions vraiment tout migrer vers TS. Puisque nous toucherions de toute façon 50% des fichiers de lib / core.

@ndelangen OOF, ne faisons pas ça maintenant alors 🙈

Ouais nous le ferons un jour

@ndelangen J'ai documenté la solution de contournement par discussion avec @tmeasday dans # 11370. Proposez que nous déplacions cette configuration vers main.js et ajoutions une option pour prendre en charge ce cas d'utilisation dans 6.x comme une fonctionnalité et non un changement radical.

Pensez-vous qu'une solution comme start-storybook -p 6006 -s "./public:/static" pour servir des fichiers statiques de ./public sur le chemin /static sera implémentée? Cela conduirait à des utilisations extrêmement flexibles et correspondrait aux conventions de mappage de chemins de Docker que beaucoup d'entre nous connaissent déjà.

Salut à tous! On dirait qu'il n'y a pas eu grand-chose dans ce numéro ces derniers temps. S'il y a encore des questions, des commentaires ou des bugs, n'hésitez pas à poursuivre la discussion. Malheureusement, nous n'avons pas le temps d'aborder tous les problèmes. Nous sommes toujours ouverts aux contributions, veuillez donc nous envoyer une demande de tirage si vous souhaitez aider. Les problèmes inactifs seront fermés après 30 jours. Merci!

@nfroidure c'est une idée intéressante à coup sûr!

@ndelangen Je peux essayer avec un PR si vous le souhaitez. Y a-t-il une chance qu'il soit fusionné?

Eh bien, j'ai quelque chose ici: https://github.com/storybookjs/storybook/pull/12222

Certains tests échouent mais je ne vois aucun lien entre ces échecs et mes modifications.

LMKWYT;)

Merci pour ce PR @nfroidure !

Je vais le regarder cette semaine!

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

Vous pouvez trouver cette avant-première sur le tag @next NPM.

Clôture de ce numéro. Veuillez rouvrir si vous pensez qu'il reste encore beaucoup à faire.

Existe-t-il un exemple d'utilisation de cette nouvelle fonctionnalité?

Cette page vous a été utile?
0 / 5 - 0 notes