Next.js has recently made a modification (in v11.0.x) which has the following type definitions:
In next-env.d.ts (non-modifiable, regenerated at every build):
/// <reference types="next" />
/// <reference types="next/types/global" />
/// <reference types="next/image-types/global" />
In node_modules/next/image-types/global.d.ts (non-modifiable, don't wanna use patch-package):
declare module '*.svg' {
const content: any
export default content
}
Now the issue is that I am using @svgr/webpack, and as a result I need to do the following:
declare module '*.svg' {
const content: React.FC<React.SVGAttributes<SVGElement>>
export default content
}
Earlier placing this code in index.d.ts in the assets folder used to work. But now it doesn't and as result I am forced to cast every import separately. Any way to do this directly?
An alternative to replacing next-env.d.ts is to add an additional declarations file, e.g. additional.d.ts, as described in https://nextjs.org/docs/basic-features/typescript.
As noted in the docs, this file must be included in the include array of your tsconfig.json file, but I've found the order is important as well - the additional file must be included before next-env.d.ts.
This seems to be because when there are multiple declarations for the same module containing default exports, the first declaration wins.
// additional.d.ts
declare module "*.svg" {
import React from "react";
const content: React.FunctionComponent<React.SVGProps<SVGSVGElement>>;
export default content;
}
// tsconfig.json
{
"include": ["additional.d.ts", "next-env.d.ts"] // The order matters!
}
This gives our preferred type for SVGs, whilst preserving the other desirable behaviour from next-env.d.ts.
This seems preferable to simply replacing the built-in types file as the Next team have reserved the right to adjust the types in future, meaning the copied types would be need to manually be kept up-to-date, and this approach doesn't seem to be a documented approach.