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?
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é:
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
vershttp://localhost:6006/
et le contenu destatic-bar
vershttp://localhost:6006/bar/
.Notez également l'utilisation de
push
pour ajouter au tableauplugins
pour éviter d'écraser d'autres plugins, ce qui pourrait casser la configuration de votre Storybook Webpack.
cela ne fonctionne pas;)
.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:
manager-head.html
dans votre répertoire .storybook. https://storybook.js.org/docs/configurations/add-custom-head-tags/<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é?
@nfroidure serait faisable:
Voici où le code irait:
https://github.com/storybookjs/storybook/blob/9182d9f5ddbe136e9cd5fc9f11fa962a3cfe08f1/lib/core/src/server/build-dev.js#L77 -L93
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é?
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à.