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

Code completion: suggest tokens from "paths" in tsconfig.json #32215

Open
shrinktofit opened this issue Jul 2, 2019 · 1 comment
Open

Code completion: suggest tokens from "paths" in tsconfig.json #32215

shrinktofit opened this issue Jul 2, 2019 · 1 comment
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript

Comments

@shrinktofit
Copy link

shrinktofit commented Jul 2, 2019

Search Terms

Code completion; module

Suggestion

Use Cases

For those paths which contains no wildcard character, can we suggest tokens from module it points?

For example:

{
  "baseUrl": '.',
  "paths": {
    "my-base-module": [
        "../../dest/base"
    ],
}

in the example, we can say that bare module specifier "my-base-module" is mapped to path "../../dest/base", which is actually a .d.ts.

However, my IDE(Visual Studio Code) do not list available symbols in "my-base-module",
such as, When I type:

const v: Ve // I 'm going to type Vec3, which is defined in "../../dest/base".

I hopo IDE can suggest Vec3 and auto-complete the importing statement as:

import { Vec3 } from "my-base-module";

You may ask: Why don't you put "../../dest/base" in "types" option in tsconfig.json.

Well, the "../../dest/base" is just a library of me. It is indeed another Typescript project's output bundle file(bundling use rollup). It is bundled as a single module, which, in later, maybe registered as a SystemJS module with name "my-base-module" because I hope users of the library treat the library as a single JS module so they can write:

import /* xx */ from "my-base-module";

Examples

As stated above, I would upload my example if it's needed.

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.
@sandersn sandersn added In Discussion Not yet reached consensus Suggestion An idea for TypeScript labels Jul 2, 2019
@klemenoslaj
Copy link

I have exactly the same situation as OP and it came to me as a surprise this is not working :)
Right now the only way around this is manual code review which is not ideal, obviously.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In Discussion Not yet reached consensus Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants