Repository navigation
Open
Labels
bugAn error in the Docusaurus core causing instability or issues with its executionAn error in the Docusaurus core causing instability or issues with its execution
Description
Have you read the Contributing Guidelines on issues?
- I have read the Contributing Guidelines on issues.
Prerequisites
- I'm using the latest version of Docusaurus.
- I have tried the
npm run clearoryarn clearcommand. - I have tried
rm -rf node_modules yarn.lock package-lock.jsonand re-installing packages. - I have tried creating a repro with https://new.docusaurus.io.
- I have read the console error message carefully (if applicable).
Description
Hi, i create new project like this:
npx create-docusaurus@latest docusaurus-try classic --typescript
cd docusaurus-try
npm startAfter it i get next error:
> showcase@0.0.0 start
> docusaurus start
[INFO] Starting the development server...
[SUCCESS] Docusaurus website is running at: http://localhost:3000/
✖ Client
Compiled with some errors in 935.15ms
SyntaxError: unknown: Unexpected reserved word 'interface'. (3:0)
1 | import * as React from "react";
2 | import { SVGProps } from "react";
> 3 | interface SVGRProps {
| ^
4 | title?: string;
5 | titleId?: string;
6 | }
at parser.next (<anonymous>)
at normalizeFile.next (<anonymous>)
at run.next (<anonymous>)
at transform.next (<anonymous>)
SyntaxError: unknown: Unexpected reserved word 'interface'. (3:0)
1 | import * as React from "react";
2 | import { SVGProps } from "react";
> 3 | interface SVGRProps {
| ^
4 | title?: string;
5 | titleId?: string;
6 | }
at parser.next (<anonymous>)
at normalizeFile.next (<anonymous>)
at run.next (<anonymous>)
at transform.next (<anonymous>)
SyntaxError: unknown: Unexpected reserved word 'interface'. (3:0)
1 | import * as React from "react";
2 | import { SVGProps } from "react";
> 3 | interface SVGRProps {
| ^
4 | title?: string;
5 | titleId?: string;
6 | }
at parser.next (<anonymous>)
at normalizeFile.next (<anonymous>)
at run.next (<anonymous>)
at transform.next (<anonymous>)
client (webpack 5.75.0) compiled with 3 errors
It is because in parent directory of docusaurus-try there is a svgr.config.js file
Reproducible demo
No response
Steps to reproduce
- create and run project by:
npx create-docusaurus@latest docusaurus-try classic --typescript cd docusaurus-try npm start - see an error in terminal and in browser
Expected behavior
May be docusaurus should log messages to terminal when it uses configurations outside target directory
Actual behavior
There is an error:
> showcase@0.0.0 start
> docusaurus start
[INFO] Starting the development server...
[SUCCESS] Docusaurus website is running at: http://localhost:3000/
✖ Client
Compiled with some errors in 935.15ms
SyntaxError: unknown: Unexpected reserved word 'interface'. (3:0)
1 | import * as React from "react";
2 | import { SVGProps } from "react";
> 3 | interface SVGRProps {
| ^
4 | title?: string;
5 | titleId?: string;
6 | }
at parser.next (<anonymous>)
at normalizeFile.next (<anonymous>)
at run.next (<anonymous>)
at transform.next (<anonymous>)
SyntaxError: unknown: Unexpected reserved word 'interface'. (3:0)
1 | import * as React from "react";
2 | import { SVGProps } from "react";
> 3 | interface SVGRProps {
| ^
4 | title?: string;
5 | titleId?: string;
6 | }
at parser.next (<anonymous>)
at normalizeFile.next (<anonymous>)
at run.next (<anonymous>)
at transform.next (<anonymous>)
SyntaxError: unknown: Unexpected reserved word 'interface'. (3:0)
1 | import * as React from "react";
2 | import { SVGProps } from "react";
> 3 | interface SVGRProps {
| ^
4 | title?: string;
5 | titleId?: string;
6 | }
at parser.next (<anonymous>)
at normalizeFile.next (<anonymous>)
at run.next (<anonymous>)
at transform.next (<anonymous>)
client (webpack 5.75.0) compiled with 3 errors
Your environment
- Public source code: non needed
- Public site URL: non needed
- Docusaurus version used: latest 2.3.1
- Environment name and version (e.g. Chrome 89, Node.js 16.15.1): Node.js 16.15.1
- Operating system and version (e.g. Ubuntu 20.04.2 LTS): mac os
Self-service
- I'd be willing to fix this bug myself.
Metadata
Metadata
Assignees
Labels
bugAn error in the Docusaurus core causing instability or issues with its executionAn error in the Docusaurus core causing instability or issues with its execution
Activity
slorber commentedon Feb 16, 2023
npx create-docusaurus@latest docusaurus-try classic --typescript cd docusaurus-try npm startThere is no error in the terminal when I run that.
I tried creating an empty
svgr.config.jsfile in the parent folder, and it still works.If the problem is related to
svgr.config.jsin parent folder, Docusaurus can do nothing about it and you'll have to figure out yourself how to override your global SVGR config with settings that work fine with Docusaurus. If that config does not work for Docusaurus, then it probably shouldn't be placed inside the parent directory, but moved to a subfolder that uses SVGR in a different way than Docusaurus does. Using one SVGR config for all projects of a same monorepo does not always make sense.krutoo commentedon Feb 18, 2023
@slorber It is still not working
Here an example repo https://github.com/krutoo/docusaurus-breaking-example
My documentation is in the "docs" child folder of my project. How could I even know that the docusaurus uses svgr? How do I understand what config I need to put in the docs folder for this to work?
slorber commentedon Feb 18, 2023
Docusaurus uses SVGR as an implementation detail but you can guess it in our doc because we say it's possible to import svg files as React components
https://docusaurus.io/docs/next/markdown-features/assets#inline-svgs
If you use SVGR yourself, then you should know it looks for config in parent folders, and that putting one config file for all your child projects may it be a good idea.
We don't have a recommendation to provide. You choose to put a SVGR config in a place that probably doesn't make sense, it is your responsability to figure out how to fix it f you want to keep this config where it is.
Similarly there are other things you can break by putting a config file on parent folder. Don't do this unless you have a reason for that config to apply to your docusaurus site as well.
krutoo commentedon Feb 18, 2023
@slorber perhaps it is worth mentioning it explicitly in the documentation?
@slorber I do not need recommendations about the structure of the project.
Can you tell me where can I get SVGR config that is suitable for the docusaurus (perhaps there is some way to explicitly tell the docusaurus to use the default config for the SVGR) so that I can put it in the docusaurus folder?
slorber commentedon Feb 18, 2023
If you chose to not listen to my recommendations of not using an SVGR config in a parent folder, then you are on your own and you will have to figure out how to solve your problem. That's out of the Docusaurus scope.
The SVGR config Docusaurus is using is there:
https://github.com/facebook/docusaurus/blob/main/packages/docusaurus-utils/src/webpackUtils.ts#L106
Josh-Cena commentedon Feb 18, 2023
The more I think about it, the more it sounds like a bug to me. Using a shared config in a monorepo sounds like a reasonable thing to do—sharing a Babel config works; sharing an ESLint config works; sharing a TS config works. It's so confusing when sharing an SVGR config throws a bizarre error, particularly when users aren't supposed to know that Docusaurus uses SVGR at all. At the very least, throwing a better error would mean fewer developer hours wasted on debugging, but I'm going to investigate whether we can prevent this error. No guarantees that I will do anything (not unless I can reproduce it and understand what's going on), but I have interest in investigating.
krutoo commentedon Feb 19, 2023
@slorber you said earlier that you have no recommendations =)
@slorber thank you at least for that
krutoo commentedon Feb 19, 2023
@Josh-Cena Thank you a lot, if i can help i'm ready
Josh-Cena commentedon Feb 19, 2023
@krutoo Would you be okay if we simply disregard the root SVGR config via
runtimeConfig: false? I don't know if anyone would be intentionally trying to override SVGR config via a config file.Josh-Cena commentedon Feb 19, 2023
Alternatively I figured out that enabling
typescript: truein our own config works. But without some more idea of the tradeoffs I'm not sure what impact that has on other users. You can fix your own error by disablingtypescript: truein your config.krutoo commentedon Feb 20, 2023
@Josh-Cena Sounds great
mvanhorn commentedon Nov 7, 2026
SVGR walks upward from each SVG and applies the first configuration file it finds, including one outside the site. createDefaultSVGRConfig left that search enabled, so a parent file with typescript: true was honored and the transform emitted TypeScript into the JavaScript client compile.
The default SVGR options now set runtimeConfig to false, which skips svgr.config.js in the site directory and in ancestor directories.
#12926