Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font family names on production build are invalid @next/font #42264

Closed
1 task done
zapaiamarce opened this issue Oct 31, 2022 · 1 comment · Fixed by #42286
Closed
1 task done

Font family names on production build are invalid @next/font #42264

zapaiamarce opened this issue Oct 31, 2022 · 1 comment · Fixed by #42286
Labels
bug Issue was opened via the bug report template.

Comments

@zapaiamarce
Copy link
Contributor

Verify canary release

  • I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64
Binaries:
Node: 16.13.2
npm: 8.1.4
Yarn: 1.22.10
pnpm: N/A
Relevant packages:
next: 13.0.1-canary.3
eslint-config-next: 13.0.0
react: 18.2.0
react-dom: 18.2.0

What browser are you using? (if relevant)

Chrome 106.0.5249.119

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

In dev mode font family names have single quotes (at least for local fonts):

image

Removing the quotes for production build generates invalid font family names:

image

image

Expected Behavior

Generate valid font family names for production build or keep the quotes.

Link to reproduction

https://github.com/zapaiamarce/next-font-issues

To Reproduce

  1. run dev mode
    yarn dev
    check the font-family name and the output

  2. run production build
    yarn build
    check the font-family name and the output

@zapaiamarce zapaiamarce added the bug Issue was opened via the bug report template. label Oct 31, 2022
@zapaiamarce zapaiamarce changed the title Font family name on production build is invalid Font family names on production build is invalid @next/font Oct 31, 2022
@zapaiamarce zapaiamarce changed the title Font family names on production build is invalid @next/font Font family names on production build are invalid @next/font Oct 31, 2022
@hanneslund hanneslund mentioned this issue Nov 1, 2022
11 tasks
ijjk added a commit that referenced this issue Nov 2, 2022
Use the name of the assigned const as the family name instead of trying
to get it from the font file. That way we know we won't get any invalid
characters in the font-family name.

fixes #42264

## Bug

- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have a helpful link attached, see `contributing.md`

## Feature

- [ ] Implements an existing feature request or RFC. Make sure the
feature request has been accepted for implementation before opening a
PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have a helpful link attached, see `contributing.md`

## Documentation / Examples

- [ ] Make sure the linting passes by running `pnpm build && pnpm lint`
- [ ] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)

Co-authored-by: JJ Kasper <[email protected]>
@github-actions
Copy link
Contributor

github-actions bot commented Dec 3, 2022

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue was opened via the bug report template.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants