-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
feat(apple): Add support for iOS #334
Conversation
|
This PR is big already, I will open for review and add support for cocoapod and fastlane in another one. |
@HazAT FYI |
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.
Looks good to me from a JS dev perspective :) Can't say much about the code snippets/SDK configuration specifics but I think the general wizard flow looks good. I had some comments/suggestions.
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
…try-wizard into feat/apple-support
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.
Thanks for adding my suggestions!
One more thing:
For folks who start the wizard without the -i arg, I think the grouping here isn't ideal. Wdyt about moving iOs to the top or below RN? I think we should sort the selection here roughly by platform (mobile, browser/JS + utilities like source maps).
At some point, depending on how many other wizards we add, we might want to somehow make these groups more apparent but for now I'd say moving iOS up should be good.
return; | ||
} | ||
|
||
const pbxproj = path.join(projectDir, xcodeProjFile, "project.pbxproj"); |
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.
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.
Yes. The ".xcodeproj" is actually a folder that keeps project configuration files.
I think we should not show the "Successfully..." message in this case.
I briefly tried the wizard locally but couldn't get beyond the pbxproj step:
You just tried to run it, or you really have an xcode project to test it? Because it should have worked if you have a project.
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.
Yes. The ".xcodeproj" is actually a folder that keeps project configuration files.
Okay, all good then! I guess I was just confused by the xcodeProjectFile
variable then 😅
You just tried to run it
Yeah, but not very methodically and without an actual xcode project. Just wanted to get over a few steps so I created some empty files 😅
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.
@brustolin do you know a repo which would be a example app to test this stuff with ourselves?
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.
Sound good. Can we try to find out which project exists to reorder the list? |
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.
Thanks for doing this, @brustolin 💪 . I added some comments.
src/apple/templates.ts
Outdated
options.attachScreenshot = true | ||
options.attachViewHierarchy = 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.
h
: I don't think we should enable that by default. Especially the screenshots could contain sensitive data, even in a development build.
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.
we could also consider having them //commented out so it is easy enough for the user to decide themselves
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.
if I may, we could just add a comment to the snippet explaining that it can have sensitive data and turn it off in case you don't want it. Or we could add another step "Enable recommended features (could send PII to Sentry)"? and only after accepting it add the snippet
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 like the idea to show this options in the wizard and explain whats happening, but in another PR.
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 think adding a comment won't be sufficient. With the wizard, it can happen that some people don't check the code that much. They just hit compile and run after executing the wizard. We could add them //commented out, or an extra step would also be OK.
Co-authored-by: Philipp Hofmann <ph.hofmann@pm.me>
We sort of do this in the sentry-wizard/lib/Steps/ChooseIntegration.ts Lines 58 to 90 in ebb501e
However, this just influences the default selection in the list, not the order. I'd argue this should be enough. |
@brustolin sounds good 🚀 if you could link to the parent issue for those PRs when you get there just let us know. only thing for me, before we make it customer facing is to ensure we have some telemetry with no PII, so we can track that it is working well. We identified a lot of simple edge cases with -sorucemaps wizard this way and are able to ship a lot of little improvements |
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.
LGTM from the Cocoa SDK perspective.
Co-authored-by: Philipp Hofmann <ph.hofmann@pm.me>
Seems like a check in #334 unintentionally disabled telemetry collection by default. I missed this when reviewing the PR. As a consequence of this and merging in #360, we didn't collect any telemetry data in the last 3.7.0 release. This patch removes the unnecessary check and restores telemetry collection. Furthermore, this patch also adjusts the welcome message to no longer show the telemetry collection note in the welcome message if it is disabled.
Added the flow to add Sentry to an iOS project.