Visual Studio Code support?
markst opened this issue · comments
Hey @johnno1962, firstly thanks for all your work on HotReloading!
I stupidly made the issue on wrong repo here: jordansinger/SwiftUI-Kit#46
Cheers for responding.
I wonder if you might offer some help as to how I can get HotReloading to work when debugging using vscode.
I've created a demo repo here: https://github.com/markst/hotreloading-vscode-ios
Hot reloading works great when running the generated Xcode project from Xcode.
However when launching the project from vscode, hot reloading doesn't work.
Hi, I'm not sure I can support you on that journey but looking at your repo, you don't seem to have added the HotReloading repo to your Package.swift or loaded the iOSInjection.bundle? You would normally do the latter here: https://github.com/markst/hotreloading-vscode-ios/blob/dev/Demo/Injection/Injection.swift#L11
Ah the Package.swift is simply there for SourceKit-LSP support, which may not be necessary.
The HotReloading is repo is added in the project.yml: https://github.com/markst/hotreloading-vscode-ios/blob/dev/project.yml#L6
As I mentioned - it is working fine when building & running in Xcode.
@johnno1962 That's fine, I wondered if something might be screamingly obviously as to why it may not work using xcodebuild
On second thoughts, there is very little prospect of VSCode support as InjectionIII needs to know where to find the build logs in order to work out how to recompile Swift source files. It might be possible to adapt it but the priority for now will be absorbing the changes that come with Xcode 14.
Ah well in that case it seems that passing the Xcode DerivedData directory to xcodebuild does resolve my issue:
xcodebuild -scheme Demo -configuration Debug -sdk iphonesimulator -derivedDataPath ~/Library/Developer/Xcode/DerivedData -allowProvisioningUpdates ARCHS=arm64 <
Top marks for creativity there! Are you saying Injecting works now?
Wow! No changes to HotReloading required? I'll put a pointer to your repo in the README. It may be using the build logs from when you were using Xcode but still great work.
It may be using the build logs from when you were using Xcode but still great work.
I thought that, but have deleted my ~/Library/Developer/Xcode/DerivedData directory multiple times & still works.
@johnno1962 unless the logs are located elsewhere?
I'm a bit surprised to be honest HotReloading is finding them, but if it works it works ¯\(ツ)/¯. Let me know how you get on and if it's stable I'll ad a note to the HotReloading README.
I've added a section to README which explains how to overcome the derivedLogs location:
https://github.com/markst/hotreloading-vscode-ios#support-hotreloading
This is awesome work! I''ve added a section to the README of HotReloading with a pointer to your project already. I'm wondering if it is possible to use a fixed DerivedData path without the Xcode hash? HotReloading should still find your logs and this would mean people can clone your project and use it without having to modify it.
In fact, it's already going to work isn't it? The Xcode hash you've entered is probably going to be used anyway. I feel a tweet coming on.
Sort of related to johnno1962/InjectionIII#388 then?
If using a DerivedData path without the hash, somewhere along the way the directory with the hash gets created:
Far as I can tell, two reference to DerivedData logs are:
https://github.com/johnno1962/HotReloading/blob/main/Sources/HotReloading/StandaloneInjection.swift#L31
https://github.com/johnno1962/HotReloading/blob/main/Sources/injectiond/InjectionServer.swift#L362
I think the hashed path will get created just by viewing the project in Xcode without building it. This aside does injection work if leave off the hash? Perhaps it doesn't make much difference in the end.
Nope, fresh DerivedData and hashed path gets created without ever opening Xcode. It get's created the first time saving after launching using iOS Debug.
Injection only works when passing hashed path to xcodebuild -derivedDataPath.
I'm happy with this setup, no real pressure to support custom derived path.
Interesting, but if people clone your project the hash will be different and it won't work for them which is a shame. I guess they could figure it out.
I did make a start at building a swift package which could be used to generate the hash as part of the vscode environment. https://github.com/markst/xcode-project-hashes
I guess ideally I'd create a vscode extension which would automate the process: markst/hotreloading-vscode-ios#4
Hey Mark, I'm happy you're still looking on this. I assume you found the XcodeHash implementation to work from. The other news is that I re-wrote The HotReloading Project to take out all the unnecessary code involved in working with the app that had accumulated over the years and is no longer required: https://github.com/johnno1962/InjectionLite. You may want to switch over to that? This code works out the correct build logs to work from by using the last modified one.
had a real quick go integrating InjectionLite using Xcode in my demo project, but need to dig deeper as to why it's not working for me:
Hi @markst, Don't you just need an @ObserveInjection var forceRedraw at the end of your View struct to force the redraw? See: https://github.com/johnno1962/HotSwiftUI. To avoid crashes on more substantial edits you should also have a .eraseToAnyView() or .enableInjection() at the end of your view body to "erase" the concrete type returned so it doesn't change over an injection.
thought I'd share this if it's of interest: https://github.com/markst/vscode-xcodegen-builder
Sounds Handy! Did you get your view refresh problems sorted out in the finish?