A way to ignore prefix/suffix in module ID, then resolve the remaining ID as usual

Search Terms

wildcard module declarations ignore prefix suffix relative path

Suggestion

import url, { other, exported, values } from 'css:./whatever.css';

TL;DR: I'm looking for a way to say "for all modules starting css:, ignore the css: bit, and resolve the remaining identifier as normal.

As identified by wildcard module declarations, some build tools use prefixes/suffixes to influence how a file is imported.

You can provide types for these:

declare module "css:*" {
  const value: string;
  export default value;
  export const other: string;
  export const exported: string;
  export const values: string;
}

The above allows developers to say "all modules starting css: look like this…".

However, what if the exports from each CSS files differs? This is true for CSS modules, where the class names in a CSS file are 'exported'.

In these cases it's typical to generate a .css.d.ts file alongside your CSS that defines the types. However, if you're using a prefix like css:, TypeScript can't find the location of the .css.d.ts file.

I'm looking for a way to say "for all modules starting css:, ignore the css: bit, and resolve the remaining identifier as normal.

Use Cases

• Build tools that use prefixes/suffixes to indicate how to process files.
• Files that may export different things per file (like CSS modules)

Examples

It isn't clear to me if this should be done in tsconfig or in a type definition file.

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.

Non viene indicato alcun file di implementazione, punto di ingresso o test. Inizia esaminando la documentazione collegata sulle dichiarazioni di moduli wildcard e l'esempio CSS-module dell'issue, quindi determina come la rimozione del prefisso dovrebbe interagire con la normale risoluzione dei moduli e se siano appropriate configurazioni o dichiarazioni. Il lavoro è completo quando è definito un comportamento specifico con copertura per gli import di moduli con prefisso e gli export per file.