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 alias import #448
Comments
I have thought of this too. I would like to have a setting to list "idiomatic imports", like:
Then we could check that all imports of the matching modules use the "idiomatic" format, to maintain consistency and prevent conflicts like you say. What do you think? |
Totally agree that we should have this settings. Do you have plan to work on it in near future ? If not, I may make contribution. |
To simplify things, shouldn't we allow something like this ?
|
This is just an idea I’ve been thinking of, no intention to work on it immediately. If you’d like to start on a PR that would be great. I agree with your proposal to support comma-separated imports. The idea of supporting all import syntax es here would allow us to parse them with the AST module, and we could support comments too. |
I'm working on it. It's almost done. Writing docs is in progress then I think Btw, could you elaborate on this
I may work on it if have time. |
Sounds good.
Use
We'd want to check that all the contents of |
Hi Adam, sorry but I still didn't get your point
as far as I perceive, So why do we need to
? |
Yes exactly - I mean we would support them by using
We should check all the parsed ast nodes are as expected, and not other ast nodes, to catch misconfiguration. For example if a user wrote:
That would be parsed as an ast string constant node, so we'd want to raise an error for that. |
Description
Hi Adam,
Can we support alias import something like this ?
In my projects, some of my modules have name conflict with 3rd-party package so I want to leverage alias imports to avoid name confusion.
Thanks.
The text was updated successfully, but these errors were encountered: