Problem/Motivation
When using kern_ux with ddev and trying to run the storybook-frontend inside of the ddev container, it fails with the following error:
/var/www/html/web/themes/contrib/kern_ux/node_modules/storybook/bin/index.cjs:23
throw error;
^
Error: spawn xdg-open ENOENT
at ChildProcess._handle.onexit (node:internal/child_process:285:19)
at onErrorNT (node:internal/child_process:483:16)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21)
Emitted 'error' event on ChildProcess instance at:
at ChildProcess._handle.onexit (node:internal/child_process:291:12)
at onErrorNT (node:internal/child_process:483:16)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
errno: -2,
code: 'ENOENT',
syscall: 'spawn xdg-open',
path: 'xdg-open',
spawnargs: [ 'http://localhost:6006/' ]
}
It seems to come from the fact, that the docker container running ddev does not know, how to open a browser.
To prevent the error, we can add the flag "--no-open" to the package.json's "storybook" command.
When people run the command, it gives a colored message with instructions on how to access the storybook, so I guess users won't be lost.
Steps to reproduce
Use kern_ux in a ddev-project and try to run the frontend build from inside the ddev container.
Proposed resolution
package.json
"storybook": "storybook dev -p 6006 --no-open",
Remaining tasks
Review by team.
User interface changes
Browser doesn't open automatically when "storybook" command is run.
Error for ddev-users should be gone.
Issue fork kern_ux-3563477
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
fisherman90Comment #4
fisherman90Issue fork with change added and MR created - feedback welcome :)
Comment #5
fisherman90Comment #6
christian.wiedemann commentedDon't we need also --host 0.0.0.0 in ddev to make accessable with an url? Maybe a check if we are inside ddev?
Comment #7
christian.wiedemann commentedComment #8
fisherman90Regarding #6 - I guess this host flag is a separate issue with docker networking on mac for some people, maybe we can open another one for it :)
Comment #10
christian.wiedemann commentedThanks!