[Bug]: next/font/local fails to properly set paths in Storybook v7.6

[mririgoyen]

Describe the bug

After upgrading to Storybook v7.6, uses of next/font/local have all stopped working. The paths that are being generated include the full dev path, and it is impossible to work around in a way that allows it to work on all systems.

To Reproduce

1. Use Storybook v7.6 and the @storybook/nextjs package.

2. Define local fonts in the preview.tsx file.

import localFont from 'next/font/local';

const Gilroy = localFont({
  src: [
    {
      path: '../gilroy/Gilroy-SemiBold.woff2',
      style: 'normal',
      weight: '600',
    },
    {
      path: '../gilroy/Gilroy-Bold.woff2',
      style: 'normal',
      weight: '700',
    },
  ],
  variable: '--font-heading',
});

const preview = {
  decorators: [
    (Story) => (
      <div className={Gilroy.variable}>
        <Story />
      </div>
    ),
  ],
};

export default preview;

3. Observe the 404'ing font's paths in the browser:

http://localhost:6006/Users/mirigoye/Code/ignition-design-system/gilroy/Gilroy-Bold.woff2

---

According to the documentation, "[t]he path is relative to the directory where the font loader function is called." In this case, the preview.tsx file is in the .storybook folder in the root of the project. In previous versions of Storybook, the paths above translated properly to the root:

http://localhost:6006/gilroy/Gilroy-Bold.woff2

We expose the ./src/assets/fonts as a staticDir in main.ts.

Adding a bunch of ../../../ in front of each path can work, but it's system specific. In other words, if my dev directory structure is different from my coworkers, one of ours may not work depending on the depth. This is especially true in Chromatic, which is how this was initially discovered after trying the relative path approach.

NOTE: Next's local font path cannot be dynamic, so we can't use variables or imports to create paths here, they have to be strings.

System

Storybook Environment Info:

  System:
    OS: macOS 13.6.2
    CPU: (10) arm64 Apple M1 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.18.2 - ~/.nvm/versions/node/v18.18.2/bin/node
    npm: 10.2.1 - ~/.nvm/versions/node/v18.18.2/bin/npm <----- active
  Browsers:
    Chrome: 119.0.6045.159
    Edge: 119.0.2151.72
    Safari: 17.1
  npmPackages:
    @storybook/addon-a11y: ~7.6.1 => 7.6.1 
    @storybook/addon-coverage: ~1.0.0 => 1.0.0 
    @storybook/addon-designs: ~7.0.5 => 7.0.5 
    @storybook/addon-essentials: ~7.6.1 => 7.6.1 
    @storybook/addon-interactions: ~7.6.1 => 7.6.1 
    @storybook/addon-links: ~7.6.1 => 7.6.1 
    @storybook/addon-styling: ~1.3.7 => 1.3.7 
    @storybook/blocks: ~7.6.1 => 7.6.1 
    @storybook/jest: ~0.2.3 => 0.2.3 
    @storybook/manager-api: ~7.6.1 => 7.6.1 
    @storybook/nextjs: ~7.6.1 => 7.6.1 
    @storybook/react: ~7.6.1 => 7.6.1 
    @storybook/test-runner: ~0.16.0 => 0.16.0 
    @storybook/testing-library: ^0.2.2 => 0.2.2 
    @storybook/theming: ~7.6.1 => 7.6.1 
    eslint-plugin-storybook: ~0.6.15 => 0.6.15 
    storybook: ~7.6.1 => 7.6.1

Additional context

No response

[mririgoyen]

I'm guessing it might have to do with changes in this PR, specifically here.

Perhaps I can ping @valentinpalkovic about possible workarounds or fixes to this?

[valentinpalkovic]

Hi @mririgoyen
Could you provide a minimal reproduction? Especially the staticDir option is relevant as well

[mririgoyen]

Sure thing, here you go: https://github.com/mririgoyen/storybook-25044-reproduction

Start it up, and go to the Pages component to see the 404.

---

And if I pin to v7.5.3, it works:

[valentinpalkovic]

Thanks! Fix is on its way. I will prepare a hotfix release tomorrow!