-
Notifications
You must be signed in to change notification settings - Fork 72
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 tsconfig.json paths and baseUrl automatically #31
Comments
You can also take a look to import/order that can differentiate external and internal modules.
|
I had terrible experience (in terms of performance/caching) so far with plugins/rules that relies on external "effects" (config files, files other than the file being linted etc.). I've never implemented a plugin myself, so my knowledge on why that's happening is very limited. I can only imagine cache invalidation being hard and once users report that as a bug, maintainers are more prone to not using a cache and to doing file I/O during linting. I'd feel very sorry if the same happened to this awesome tool. |
@anilanar Thanks for sharing your experience! That’ll be kept in mind if this is implemented. I think the added custom grouping option works well enough and is easy enough to use that this might not even be needed. |
any progress with |
No, I’m not so interested in this anymore because (1) I don’t need this myself and (2) the custom grouping option seems easy enough to set up (and is possibly more performant). Would you like to tell us more about your use case that you’d want this for and how much configuration you’d avoid not having to set up custom grouping? |
I have a create-react-app typescript project, and I've set the project to use non-relative modules.
so now I can use import CommonService from 'services/commonService'; insted of import CommonService from '../../../services/commonService'; and now when I'm using the auto-fix import import { Col, Row } from 'antd'; // third party
import Dictionary from 'dictionary/dictionary'; // my module
import React, { useState } from 'react'; // third party
import { RouteComponentProps } from 'react-router-dom'; // third party
import CommonService from 'services/commonService'; // my module
import TreatmentService from 'services/treatmentService';// my module which makes no sense |
@israelKusayev Thanks! Have you tried the custom grouping option? How did it go? |
I don't know that custom grouping is the right solution here–won't it require you to write a regex pattern that explicitly matches every file/directory in your |
Yes it does! By showing me how complex that would be, that would motivate adding the automatic tsconfig.json thing. |
Sorry for the late response I tried to use groups and I ended up with: "overrides": [
{
"files": ["*.tsx", "*.ts"],
"rules": {
"simple-import-sort/sort": [
"error",
{
"groups": [
// Packages. `react` related packages come first.
// Things that start with a letter (or digit or underscore), or `@` followed by a letter.
["^react", "^@?\\w"],
// Absolute imports and Relative imports.
["^(utils|services|hooks|hoc|types|contexts|dictionary|components)(/.*|$)", "^\\."],
// for scss imports.
["^[^.]"]
]
}
]
}
}
] I think it is great for me, except for one thing, If I'll add more folders to my project under But I'm not adding a new folder (under |
@israelKusayev Thanks! If you use .eslintrc.js, maybe you can use |
Yesss great idea, works perfect const fs = require('fs');
const foldersUnderSrc = fs
.readdirSync('src', { withFileTypes: true })
.filter(dirent => dirent.isDirectory())
.map(dirent => dirent.name); and then // Absolute imports and Relative imports.
[`^(${foldersUnderSrc.join('|')})(/.*|$)`, '^\\.'], You can see here the config file https://github.com/reflexology/client-V2/blob/master/.eslintrc.js |
Cool! If you’re paranoid you could regex-escape the directory names as well :) |
The import plugin solves this using custom resolvers, which works well with |
@iwan933 Can you show what your double configuration looks like? |
@lydell double configuration is maybe the wrong wording here. But actually if i would use the simple-import-sort and import plugin, it would be nice to have a single solution for handling tsconfigs baseUrl. Personally i prefer the resolver over the groups solution. But i might miss some points here as i have not developed a plugin yet. |
Ok! It still helps to see some real config, though. Having examples to look at always help me. |
Can we reuse |
@JounQin Last time I looked at the resolvers of eslint-plugin-import I came to the conslusion that we can’t reuse them. Things might have changed though and I might have overlooked something, so feel free to look into it! But do keep in mind that:
|
AFAI, the Take eslint-import-resolver-typescript for example.
The resolvers are installed by users manually, so this is not a problem? |
We clearly have different opinions here. I don’t think anything good will come out of a discussion about it. |
Hmm … I realized something. Thank you for pushing me to think about this! I think that the only solution I will find acceptable is:
|
I was thinking to reuse |
Ok. |
I’ve made up my mind. This is complexity I don’t want. I’m updating the readme: #93 |
It would be cool if the plugin could automatically detect tsconfig.json to see which first party imports you have, such as
web/components/foo
. Then those could be moved into the “absolute imports” group, instead of ending up in the (third party) “packages” group.One idea is to use https://github.com/dividab/tsconfig-paths. Need to check that it actually supports baseUrl, though.
Another idea is to try to
require("typescript")
. If it’s there, use it to resolve the config.The initial idea comes from: #18 (comment)
Edit: This is a light-weight package that can do the hard work for us: https://github.com/privatenumber/get-tsconfig
The text was updated successfully, but these errors were encountered: