Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: non-ts module type resolver plugin #24522

Closed
4 tasks done
noe132 opened this issue May 31, 2018 · 2 comments
Closed
4 tasks done

Proposal: non-ts module type resolver plugin #24522

noe132 opened this issue May 31, 2018 · 2 comments
Labels
Duplicate An existing issue was already created

Comments

@noe132
Copy link

noe132 commented May 31, 2018

Search Terms

type, non-ts module, type resolver, type generator

Suggestion

a type generation plugin system for non-ts modules.

Use Cases

useful to get type and autocomplete intellisense when importing non-ts modules like css, html, vue, etc.
currently there is only a generic type for a single type of file using .d.ts

Examples

While using typescript with some packing system like webpack, it's common import thing other than ts in a ts file, like js, css, html. For js file, typescript compiler can infer some type in js, or if you write types in jsdoc format. But other than ts and js, normally you will get cannot find definition for xxx, and you need to write a module declaration file like css.d.ts probably like this

declare module '*.css' {
  const value: string;
  export default value
}

but if we are importing a css module, you may need some thing like

declare module '*.css' {
  const value: any;
  export default value
}

which is simple and rude for css module type define.

So, if the type definition of a file can be generated by a plugin, for instance define a typePlugin in compilerOptions

{
  "compilerOptions": {
    "typePlugin": [
      "typescript-css-module-type-resolver"
    ]
  }
}

and typescript-css-module-type-resolver in this format

interface typeDefinition {
  // a ts readable type definition tree
}

interface TSTypeResolverContext {
  options: any // possible options
  filePath: string // file path
  fileContent: string // file content in string
  fileBuffer: Buffer // file content in buffer
  ignore: function // ignore for this file
  resolve: (filePath: string) => typeDefinition // get definition for another file
  callback: (type: typeDefinition) => any // return the type generated by this plugin
}

const cssModuleTypeResolver = (context: TSTypeResolverContext) => {
  const {
    filePath,
    fileContent,
    fileBuffer,
    ignore,
    callback,
  } = context
  
  if (filePath.match(/\.css$/)) {
    // parse the file and generate the type
    // if (importInCss) {
    //   resolveSomeOtherFiles
    // }
    const generatedType = typeGeneratedByThisPlugin
    callback(generatedType)
  }
}

export default cssModuleTypeResolver

which given a type like

import { cssModuleUnit } from './cssTypes.d.ts'
interface cssModuleTypeDefinition_idxxxxx {
  red: cssModuleUnit
  big: cssModuleUnit
  'blue-and-underline': cssModuleUnit
}

to be use by ts compiler for any ts module import a css module file, and get type and auto complete intellisense like a normal ts file, and looks like this

and any other type of file could write a type plugin like this.

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. new expression-level syntax)
@noe132 noe132 changed the title Proposal: module type resolver plugin Proposal: non-ts module type resolver plugin May 31, 2018
@mhegazy
Copy link
Contributor

mhegazy commented May 31, 2018

Looks like another use case of a type provider. Already tracked by #3136

@mhegazy mhegazy added the Duplicate An existing issue was already created label May 31, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants