Repository navigation
Improve declare module wildcards so that they can match parts of a path more like a glob #38638
Description
Search Terms
global module match glob path
Suggestion
Improve the declare module wildcards so that they can be used multiple times in a path and they can match multiple parts of it.
Use Cases
In the project I am currently working on we make a distinction between images and icons:
- icons are usually small in size and used multiple times so we store them as SVG and put them in a SVG sprite with the help of external-svg-sprite-loader.
- images are usually bigger in size and used only once so we store them as well as SVGs but do not put them in a sprite.
Since SVG imports are not recognized by TypeScript I want to create a global module declaration that targets all icon imports and another that targets all image imports. However, based on the feedback I got in this StackOverflow issue, it doesn't seem to be possible to do this since the support of wildcards in module paths seems to be very limited.
Examples
This is an example of what I would like to be able to do:
declare module '@my/**/icons/**/*.svg' {
type IconType = { viewBox: string, symbol: string };
const icon: IconType;
export = icon;
}
declare module '@my/**/images/**/*.svg' {
const url: string;
export = url;
}Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
Activity
lucsky commentedon Sep 3, 2021
+1
This is a problem that loaders for most of JS bundlers like Webpack or Vite have. I wrote a Vite plugin that loads SVG assets as React components and have the following module declaration:
What I would really want is simply...
...to allow the addition of asset specific parameters as part of the query, like this:
ninofiliu commentedon Dec 13, 2021
Related questions on stack overflow:
isaac-mcfadyen commentedon Feb 19, 2022
Any progress/update on this? Tools like
vite-imagetoolsmake heavy use of imports like*.jpeg?*.silasabbott commentedon Apr 5, 2022
I'm also using
vite-imagetoolsand came across this same problem. The best I could come up with is appending&imagetoolsto the end of my query for each image. Not ideal whatsoever since the query parameter serves no purpose, but it does work:Still, it would save some unnecessary code to have the ability to write complex wildcards.
Nantris commentedon Sep 23, 2022
It would be great if we could do like
ours-somemodule-platformand target it withours-*-platformQtax commentedon Dec 29, 2022
Another tool that needs this is
image-minimizer-webpack-plugin.Instead of
declare module '*.jpg?*' ...I'm forced to use an ugly hack likedeclare module '*&imgmin' ...to avoid these errors:sdegutis commentedon Oct 8, 2023
I just ran into the issue that
foo-bar.mddoesn't match*.mdbutfoobar.mddoes. There's no way to fix this as far as I can tell.wuhkuh commentedon Apr 27, 2026
I ran into this while trying to bundle audio assets (via rolldown) with my application.
Resolving this issue makes asset bundling highly more viable, for now we'll have to sprinkle
// @ts-expect-erroreverywhere.