-
Notifications
You must be signed in to change notification settings - Fork 743
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
Removing Swift codegen (v1) #1873
Conversation
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.
Just want to make sure this AST stuff isn't used elsewhere, I'm pretty sure this is good though!
And lets fix that test instead of deleting it?
@@ -1,18 +0,0 @@ | |||
import Foundation |
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.
@designatednerd Are these AST objects being used by the Javascript Frontend? Is there even anything that is creating them currently, other than unit tests for the experimental codegen? I think we can delete these from main
, but just want to make sure.
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.
They should not be, this was being created off reading everything in using the TS CLI, you should be able to nuke them from orbit
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.
@AnthonyMDev I think all the issues I tried to address for enums are at least still in the codegen project, but it might be useful to think about leaving a bunch of test names and just throw XCTSkip
on those tests for now until it's actually implemented
case "GitHub": | ||
self = .gitHub | ||
case "Upload": | ||
self = .upload | ||
case "AnimalKingdom": | ||
self = .animalKingdom |
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.
did we mean to delete this?
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.
I did, it was only there to be used with swiftExperimental
. It comes back in an RFC-focused branch.
@@ -67,7 +67,7 @@ class ApolloCodegenTests: XCTestCase { | |||
let namespace = "ANameSpace" | |||
let prefix = "MyPrefix" | |||
|
|||
let options = ApolloCodegenOptions(codegenEngine: .swiftExperimental, |
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.
for what it's worth I think it's worth keeping the swiftExperimental
case since it's still eventually going to be used, just for a completely different setup
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.
It comes back in an RFC-focused branch. My opinion was that if it stayed in main
then it should blow up, aka fatalError
, because it does nothing at this point. That led me to think it was better to nuke from main
and bring it back where we actually use it.
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.
eh, fair enough. I'm always more in favor of just leaving it but I see your point too.
@@ -58,7 +58,6 @@ public struct ApolloCodegenOptions { | |||
} | |||
|
|||
let codegenEngine: CodeGenerationEngine | |||
let additionalInflectionRules: [InflectionRule] |
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.
just please please please remember to re-add this, it solves so many goddamned problems
If we are (temporarily) not using some of these dependencies any more, we should remove them from SPM and the podfile. I'm pretty sure that Stencil, PathKit, and InflectorKit are all not being used after we kill this code. We're going to need to re-add them on the branch for the codegen RFC at some point, but we don't need our consumers to be downloading and including them in their projects right now for the time being. |
1d6eb19
to
3133906
Compare
3133906
to
42a75f2
Compare
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.
Revoking my approval: Please don't remove InflectorKit and the related code completely. That can be used for pluralization/depluralization as needed, which we absolutely will need regardless of whether we use stencil or not. I'm fine with removing the code from the initializer for now since it's not being used, but this is a case where I really don't think removing it just to put it back in later exactly as it was is worth it.
I'm fine with losing Stencil (which IIRC is where the PathKit dependency comes from) since @AnthonyMDev it sounds like we're not going to use it going forward.
@designatednerd I feel quite strongly that we shouldn't have code in @AnthonyMDev - do you have an opinion on this or the workflow? |
I don’t really feel strongly either way. I see both sides and don’t really have any additional arguments to add to either of them. FWIW, I think I lean towards removing them, even if we are going to re-add them later, but not passionate about that. Also, the more I think about it and research, the more I think it’s likely we will end up using Stencil. |
In my research I'm fine with ripping out the other stuff as there are other ways to get from point a to point b, but to me it feels like a waste to rip out something that's already set up and tested just to put it right back in when we start needing to do basic pluralization/depluralization of types, which we'll need to do quite quickly when we get the codegen going. |
It is pretty hard to navigate, but where is the "legacy" codegen resides? I suppose that is some Typescript code somewhere in some other repo, but have a hard time to find exact where it is and how we packaged up to legacy_cli that we use. Edit: Found it in https://github.com/apollographql/apollo-tooling/tree/master/packages/apollo-codegen-swift, apollo-tooling (instead of apollo-cli) is where tripped me initially. |
* main: (856 commits) Add execution tests for ApolloClient clearCache callback queue (apollographql#1901) Use the provided callback queue instead of the store's default. (apollographql#1904) chore(deps): update dependency path-parse to 1.0.7 [security] (apollographql#1899) Release - 0.46.0 (apollographql#1897) Update subscriptions tutorial to be compatible with recent changes (apollographql#1893) Add docs and improve merging of records from WebSockets into cache. (apollographql#1892) Publish response from the `WebSocketTransport` to the `ApolloStore` (apollographql#1889) fix(deps): update dependency gatsby-theme-apollo-docs to v4.7.14 Removing Swift codegen (v1) (apollographql#1873) Update toolchain versions used by circleci (apollographql#1875) fix(deps): update dependency gatsby-theme-apollo-docs to v4.7.13 Community Updates - ROADMAP/README (apollographql#1867) [Release] - 0.45.0 (apollographql#1862) WebSocket Fixes - Revert to Starscream 3.x and invert dependency (apollographql#1861) Docs/discussions_2_community branch changes (apollographql#1858) Replace spectrum with Discourse (apollographql#1857) fix(deps): update dependency gatsby-theme-apollo-docs to v4.7.12 Configure Renovate (apollographql#1854) Revert "Reconfiguring renovate 2/2" Reconfiguring renovate 2/2 ... # Conflicts: # Sources/Apollo/GraphQLQueryWatcher.swift # Sources/ApolloWebSocket/WebSocketTransport.swift
This PR removes the initial implementation of Swift codegen from the main branch.
It does this in distinct commits, some of which will be reverted in another branch..
Swift codegen is not dead; there will be a new branch where v2 of the RFC will be built until it is ready for an alpha release.