kirbydesign / designsystem

Kirby Design System
https://cookbook.kirby.design
MIT License
83 stars 22 forks source link

[Enhancement] Better Serving of Storybook Static Assets #1879

Open MadsBuchmann opened 2 years ago

MadsBuchmann commented 2 years ago

Describe the enhancement

I want to find a better way to bundle and serve storybook static assets.

A rather inelegant solution was found when working on #1858 that simply consists of running a bundle-storybook-assets npm script when starting storybook or building it. The npm script copies the files into a git ignored static folder located at: libs/desingsystem/.storybook/.static/assets/.

The nx configuration for storybook located in /angular.json then uses the staticDir option to tell storybook that libs/designsystem/.storybook/.static/ is the root for serving static files for storybook.

The designsystem library expects assets to be stored in an assets parent folder. As can be seen in the kirby-icon-settings.ts file. This is why assets are stored in [...]/.static/assets/ instead of [...]/.static/

I do not think this is very pretty and it might be possible to use the tools we have at our disposal in the repo better.

Describe the solution you'd like

I played around with it a bit when working on #1858 and could not get it to work; but I would like to examine if we can do something like this (see excerpt in context):

[...]
"assets": [
              "apps/cookbook/src/favicon.ico",
              "apps/cookbook/src/assets",
              {
                "glob": "**/*.js",
                "input": "libs/designsystem/src/lib/polyfills",
                "output": "./kirby/polyfills"
              },
              {
                "glob": "**/*.svg",
                "input": "libs/designsystem/src/lib/icons/svg",
                "output": "./assets/kirby/icons/svg"
              },
              {
                "glob": "**/*.svg",
                "input": "node_modules/ionicons/dist/ionicons/svg",
                "output": "./svg"
              }
            ],
[...]

Have you considered any alternatives?

Alternatively we should rethink how we store and depend on assets in the designsystem library. Could we for example create a new libs/designsystem/assets/ folder for storing static files such as icons (alternatively libs/core/assets/)? The paths in Kirby-icon-settings.ts could then exclude the assets part.

...But would this break anything?

Additional context

At the time of writing the storybook functionality is not merged due to the below comment. But the code can be found on the branch: https://github.com/kirbydesign/designsystem/tree/enhancement/1824-nx-storybook-setup also there's a related (and now closed) PR here #1858


Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Refinement

Implementation

The contributor who wants to implement this issue should:

Review

Once the issue has been implemented and is ready for review:

MadsBuchmann commented 2 years ago

With further testing it turns out the solution for serving static assets in the cookbook does not work properly. I will be parking the storybook issue for now due to other priorities.

When running npm run start:storybook the following error is thrown:

ModuleBuildError: Module build failed (from ./node_modules/css-loader/dist/cjs.js):
Error: Can't resolve '/assets/kirby/icons/svg/link.svg' in '/Users/Prochimp/Projects/designsystem/libs/core/src/scss'

This can be mitigated by commenting out the background-image property on .kirby-external-icon in libs/core/src/scss/_global-styles.scss:

.kirby-external-icon {
...
background-image: url('/assets/kirby/icons/svg/link.svg');
...
}

If this is done and the storybook is served, it can be seen that the attach.svgthat the badge component is showcasing at the moment, is served without problems.

To me it seems like something goes wrong during scss compilation where the web pack bundler is not able to find the static files... Or something like that... I'm no expert on the subject 😅

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because of no recent activity. It will be closed in 10 weeks if no further activity occurs. Thank you for your contributions.