-
Notifications
You must be signed in to change notification settings - Fork 464
generate import type instead of import
#2425
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
base: master
Are you sure you want to change the base?
Conversation
|
@jimisaacs: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/ |
Yikes - clones won't have an `apollographql` based `remoteUrl`, which means this test has been failing for contributors for about 2 years :-(.
|
Thanks for your help on this @hwillson !!! |
|
Thanks for working on this @jimisaacs. Since this is a breaking change we'll have to be careful with how it's rolled out. We're discussing those plans internally, and will get back to you shortly. |
|
+1 for this change. If there is any help needed, please ping me. Also, if this breaking change seems like a large step forward, an intermediate solution could be to introduce a config setting that would indicate if the generation would create |
|
@hwillson any update on the internal discussions? :) We really need this, we depend on |
Hello, this is my attempt to fix codegen to be able to use
"importsNotUsedAsValues": "error"in tsconfig.json.It definitely fixes my codebase, which is a pretty gigantic codebase.
At first I thought of maybe doing a more robust solution, but then I thought, I don't think the codegen actually needs any other type of import other than
import type.TODO:
*Make sure changelog entries note which project(s) has been affected. See older entries for examples on what this looks like.