Open eyedean opened 5 years ago
@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).
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
Hi. Do we have any movements?
@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?
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 usechangeProcessDirectory
in the ESLint settings of VS Code insettings.json
for my subfolder WorkingDirectroy. (As shown in https://github.com/Microsoft/vscode-eslint/issues/196#issuecomment-279362659)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 thisalias
resolver), 3) and finally a manualmodule-alias
becausetsc
doesn't resolve the mapping when it emits the JS codes. (Filed at https://github.com/microsoft/TypeScript/issues/26722#issuecomment-501912653)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
andpathPrefix
(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!