-
-
Notifications
You must be signed in to change notification settings - Fork 59
Runtime portability improvements #478
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: main
Are you sure you want to change the base?
Runtime portability improvements #478
Conversation
|
unfortunately this tsconfig setting |
|
I still do not want to expose the Runtime code as an API because maintaining a stable interface at that layer requires much effort. |
|
@kateinoigakukun I understand the concern. I don't think this PR changes anything in that regard. |
|
Sorry, I still can't see a clear benefit in merging this change. I've gone through the discussion and the measurements again, and I still can't support this direction. The latency we are seeing comes from the implementation details of SwiftPM's plugin evaluator with native build system (especially the manifest caching disablement is the major 100ms-level bottleneck), not from the SwiftPM's plugin architecture itself. Once SwiftPM's swift-build migration lands, that overhead disappears, so we don't have a strong reason to work around plugins on our side. Also the BridgeJS stubs are just a hack, and they won't be necessary after we start using BridgeJS inside JavaScriptKit, so I don't want to split it out now. |
Have either of you tested how this works with |
|
@MaxDesiatov It's not working today swiftlang/swift-package-manager#9364 |
as discussed in #477
This PR
I think these changes are good even when the whole "how to best bundle/deploy/build/package" is not fully clear yet.