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.

No implementation file, entry point, or test is named. Start by reviewing the linked wildcard module declarations documentation and the issue's CSS-module example, then determine how prefix stripping should interact with normal module resolution and whether configuration or declarations are appropriate. Done means a specified behavior with coverage for prefixed module imports and per-file exports.