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

Support for reading mapping from tsconfig.json #11

Open
eyedean opened this issue Jun 14, 2019 · 4 comments
Open

Support for reading mapping from tsconfig.json #11

eyedean opened this issue Jun 14, 2019 · 4 comments

Comments

@eyedean
Copy link

eyedean commented Jun 14, 2019

Greetings,

I have a setup of ESLint + Node + TS and VS Code for a server-side project. In order to get my path aliases working in ESLint plugin of VS Code, I decided to use this package. I spent 4 hours today and finally got it to work after debugging this code!

The problem was that my project was in a subfolder of the WorkingDirectory, so the process.cwd() in https://github.com/johvin/eslint-import-resolver-alias/blob/master/index.js#L70-L71 was returning / and couldn't resolve the path to the referred module. I found that I needed to use changeProcessDirectory in the ESLint settings of VS Code in settings.json for my subfolder WorkingDirectroy. (As shown in microsoft/vscode-eslint#196 (comment))

With this history, the biggest problem I have right now is every time I want to define a new module path-mapping (alias), I need to change 3 different places individually! that is:

  1. tsconfig.json,
  2. .eslintrc.js (for this alias resolver),
  3. and finally a manual module-alias because tsc doesn't resolve the mapping when it emits the JS codes. (Filed at Offer option to resolve module path maps in emitted code microsoft/TypeScript#26722 (comment))

Suggestion

In order to reduce the number of places I need to change upon adding a new mapping, I was thinking that maybe this resolver can take a parameter to read the mapping from tsconfig.json.

To start, it can take a pathToTSConfig and pathPrefix (e.g. @ or ~ to make it easier to identify the custom paths) and extract the mapping from there. That way, the source of truth will live in one less place.

I don't know if you guys think it's a good addition to this NPM package. If so, I can start working on a PR. Otherwise, I think the best I should do is to fork this resolver and create a new one, simply to support reading from tsconfig.json.

Please advise.

Thanks!

@johvin
Copy link
Owner

johvin commented Jun 20, 2019

@eyedean sorry for being so late to see your issue. your suggestion is good, but i can't make a decision in a short time. I will think about it and get back to you in the next few days(no more than a week).

@disbelief
Copy link

If I could chime in on this, there's also jsconfig.json for non-TypeScript projects, which works similarly:

jsconfig.json

{
  "compilerOptions": {
    "baseUrl": "src"
  },
  "include": ["src"]
}

Will allow the following import statement to work from anywhere in the project directory:

import "MyComponent" from "Components/Component";

Assuming MyComponent lives in src/Components/MyComponent.js

@Yegorich555
Copy link

Hi. Do we have any movements?

@johvin
Copy link
Owner

johvin commented Feb 26, 2020

@eyedean @disbelief @Yegorich555 Given that different configuration files have their own syntax rules, the conversion logic is not the core function of this plug-in. Would it be better to write a converter?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants