-
-
Notifications
You must be signed in to change notification settings - Fork 298
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 importing types #352
Conversation
Unrelated to this PR: The Typescript change will be in a new major, because we also changed the license, so if you want to rename some internal helpers to better reflect their real purpose feel free to do so and create a PR. If you have the time. |
Thanks looking forward to see this in action. I haven't looked at the code yet, but two things I would like to mention:
|
Yep, working on the rebase now. For the fs thing, I think we could use the browser override trick, and point to a file that just returns null. If fs is unavailable, importing will just be unsupported. |
Ready for review! I added support for namespace imports, and re-exports. Leaving CommonJS and libdefs for future work. Also added a browser override for |
I know a lot of the community has been dying for this, myself included. thank you! Hope this can get in after proper review 👍 |
Hey sorry to be that guy (I know how it is), but is there anything I can do to help move this PR along? |
I second this ^^ |
Sorry I was working on other stuff and Felix is also not available. I hope I will try to find some time soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice work.
It would be nice to add more unit tests, especially for resolveToValue
and resolveImportedValue
. We could use https://github.com/tschaub/mock-fs to create the tests.
Will this also work for type/typeof imports in flow? Didn't see any tests. If not I'm happy to do that in a separate PR.
I think only doing ES6 imports is fine.
export default function resolveToValue(path: NodePath): NodePath { | ||
export default function resolveToValue( | ||
path: NodePath, | ||
resolveImports: boolean = true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolveImports: boolean = true, | |
resolveImports?: boolean = true, |
I wonder if it makes more sense to have false
as default? That would be less breaking for outside resolvers/handlers. But we are also doing a major anyway...
Are we using more cases with true
in our codebase?
const code = fs.readFileSync(resolvedSource, 'utf8'); | ||
const parseOptions: Options = { | ||
...options, | ||
parserOptions: {}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why overwriting the parserOptions?
I haven't looked at it yet, but I wanted to note two things:
If we are going to support dependency resolution, then we need to support multiple syntax and module loaders at some point, or at least make it easy to plug those in. Short term we need to be able to either enable or disable dependency resolution (depending on what the default is), via CLI parameters and/or config, so that it still runs in environments where resolution does not work. |
Any ETA on this to get merged? |
@devongovett do you have time to finish this up? |
Vote for getting this merged! 👍🏼 |
@jdevo23, you might wanna exclude GitHub from your vacation autoresponder 😄 |
Does this PR also solve the issue of using react types from the namespace (instead of directly importing them) resulting in ie: |
@Vanuan I do not believe so.
|
so close... |
Very interested in the PR. Thank you! |
Any plans to merge this PR any time soon ? |
Thanks for opening the PR and putting in the work. I believe many of us would appreciate if this can get merged as soon as possible. |
ITT: A lot of people asking if the work can be done for them. (Me included) |
@haffmaestro not quite.. check out @phated's efforts to get this over the line: #464 and give him a big cheer!! 🙌 |
Fwiw, that work ☝️ is now ready for review. It's a beefy PR (lots and lots of tests) and I'd love for some people to look at it! |
hi, when will this pr will be merged? does anybody care about this? i have to decide about my usage. |
@kubilaykiymaci Looks like a lot of progress was made by @phated in #464 which has been merged 👏. I don't think this pr will ever be merged, but looks like v5.4.0-alpha.0 includes #464 so that might solve your problems. |
Closes #33.
This adds support for importing propTypes, flow, and typescript from other modules. Various people have tried to do this through external handlers in the past, but this has been more challenging because they have needed to reimplement or copy many of the builtin helper functions available in react-docgen. This PR adds builtin support for importing, and should be much simpler than external solutions.
Current limitations:
node_modules
is supported, but flow libdefs (flow-typed
folder,.js.flow
files, and.d.ts
files) are unsupported. Would need to reimplement a custom resolver for those.Some of these could be resolved, but we could also decide to leave some for future enhancements in order to start somewhere.