-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
no-unused-modules
does not work properly with flow types exports
#1564
Comments
cc @rfermann |
@rfermann thanks a lot for your reply and for your effort. Flow docs show these examples exports.js // @flow
export default class Foo {};
export type MyObject = { /* ... */ };
export interface MyInterface { /* ... */ }; imports.js // @flow
import type Foo, {MyObject, MyInterface} from './exports'; AFAICS this doc is not complete (unfortunately, Flow is notorious for bad documentation 😞) and there can be these ways of importing Flow types: import type { MyObject } from './exports' and
Please let me know if I can provide any additional info. |
The first step should probably be reverting #1542 and releasing a patch |
👍 |
While scanning the source code, i found this pull request. After commenting out all changes on After reading the related issue, there was a fix in place which has been reverted and replaced with the fix provided in the PR mentioned above. @ljharb can we revert the PR #1494 and restore the original fix instead? This would help increasing the flow support for |
@rfermann sure, want to open up a PR that does that? |
I guess this line causes the issue since it completely skips the whole module and that's why On the other hand, it isn't clear to me why Not sure I'll be able to do any quick investigations in a few weeks. It makes sense to revert #1494, but it worth adding some tests for this particular issue, so anyone can revisit fix for #1343 later |
That's because in this case Meanwhile i reverted the changes of #1493 locally but kept the tests, trying to make them still pass but with different changes on the source files. Only one is left so far, so if I am lucky, I will be able to provide a solution soon. |
Make sure you’re using babel-eslint or flow parser https://astexplorer.net/#/gist/052189089ff2f468742815723f2dfeba/latest Otherwise it isn’t possible to detect whether import specifier is a type or a value |
Also, instead of removing only type imports from the dependency graph we can add some meta information to them, e.g |
Btw, looks like this PR #1231 already do this, except |
@ljharb the next week is pretty busy for me, but I guess I'll have some free time after that for a fix and test coverage |
@maxmalov thanks for linking to the other PR. Surprisingly I (partially) came to the same solution without even looking at this one 😅 The downside is, this does not make all tests provided by @maxmalov pass. Although the last test for But I am not sure if the test is supposing the correct line number in this case, as both lines are importing from the same file. |
@rfermann it looks like the issue related to multiple imports from the same module. Consider the following example: // @flow
import type { MyType } from './types';
import { type OtherType, myVariable } from './types'; The first is the import declaration with How I understand the current implementation, only the first import will be captured, leaving the second one untracked. This approach works for |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@Hypnosphi This was my original idea fix #1564 (comment), but after a few tries I've ended up in a case when |
@Hypnosphi sure. we should add some tests to prevent that from happening again. cc @nicolashenry |
I will take a look when I have more time but it seems that I may introduced wrongly TypeAlias and InterfaceDeclaration by babel-eslint as Typescript types when it seems to be Flow types. So some typescript tests which existed before my changes were probably relying wrongly on babel-eslint parser and I tried to make it compatible with it too but it was probably a bad idea unless some people are using babel-eslint parser with Typescript source code instead of @typescript-eslint/parser or typescript-eslint-parser. I will try to change typescript tests to use typescript parsers only or maybe try to do a proper fix for Flow type imports but I am not a Flow user so I will may have some difficulties to do it. |
@Hypnosphi Can you provide me a test case? I can't reproduce using unit tests from #1542 even adding |
@Hypnosphi It seems to be related to the loading order, if I rename |
This PR introduces support for Flow type exports #1542
However, it only takes into account the identifier import style
https://github.com/benmosher/eslint-plugin-import/pull/1542/files#diff-48b646acd6be2c915b501dc667163bd4
And it does not work for the declaration import style. Example
Module a.js:
Module b.js:
Will result in an error in module A:
Note:
It seems to work fine for me if I use identifier import style
The text was updated successfully, but these errors were encountered: