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
[TIMOB-25748] iOS: Remove TiCore in favor of built-in JavaScriptCore #9798
Conversation
Generated by 🚫 dangerJS |
IOS.prototype.build = function (next) { | ||
this.fetchLibTiCore(next); | ||
// no-op (used to fetch TiCore in the past) |
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.
Clearly not related to this PR, but this jogs my memory. Weren't we going to pre-build libraries for iOS like we do for the other platforms at some point? Do we have JIRA tickets/PRs to track that?
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 remember you had an angry TODO comment somewhere that states that we should just place libraries inside the repo instead of fetching them manually. In case you mean that, it should be obsolete now that we remove TiCore. Other libraries like libAPSHTTPClient and libAPSAnalytics are prepackaged, just like Hyperloop should / will be in the future.
@@ -80,7 +54,6 @@ IOS.prototype.package = function (packager, next) { | |||
const DEST_IOS = path.join(packager.zipSDKDir, 'iphone'); | |||
|
|||
async.parallel([ | |||
this.fetchLibTiCore.bind(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.
Also need to remove the step below where we try to copy iphone/headers/JavaScriptCore since there's no files there anymore (that's why the build is failing right now, lines 62-64 in your modified file) - and the 'headers' entry in the array of folders/files we try to copy (line 66 in your modified file)
@@ -80,7 +54,6 @@ IOS.prototype.package = function (packager, next) { | |||
const DEST_IOS = path.join(packager.zipSDKDir, 'iphone'); | |||
|
|||
async.parallel([ | |||
this.fetchLibTiCore.bind(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.
Can we also remove libti_ios_debugger.a? libti_ios_profiler.a?
Those were to be used against TiCore and do not work with JSCore.
I've been told several times we can kill off our profiler because it's not useful and no one uses/knows about it. The debugger has been replace by using the official debugger APIs built into JSCore.
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.
TiProfiler is dead. I think it was used in the past when Titanium wasn't fully compatible with Instruments, which works fine these days. I'll search related guides and docs to clarify that.
…ed code in iOS build script.
@sgtcoolguy Ready for re-review |
Generated by 🚫 dangerJS |
iphone/cli/commands/_build.js
Outdated
@@ -5838,10 +5799,6 @@ iOSBuilder.prototype.copyResources = function copyResources(next) { | |||
transpile: this.transpile, | |||
resourcesDir: this.xcodeAppDir | |||
}; | |||
// generate our transpile target based on tijscore/jscore | |||
if (this.useJSCore) { | |||
analyzeOptions.targets = { ios: this.minSupportedIosSdk }; // if using jscore, target our min ios version |
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.
The block can't be removed entirely. That option setting needs to be moved up above then (because useJSCore is always true now). Without setting analyzeOptions.targets = { ios: this.minSupportedIosSdk };
we'll transpile everything down, not selectively based on the JS engine in iOS.
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.
Dangerous issue, thanks for picking this up!
package-lock.json
Outdated
@@ -2204,7 +2204,7 @@ | |||
"file-state-monitor": { | |||
"version": "1.0.0", | |||
"resolved": "https://registry.npmjs.org/file-state-monitor/-/file-state-monitor-1.0.0.tgz", | |||
"integrity": "sha512-Tmn8VmqNW++Vyd0aMgNPR1F+56gp4GE9iY1rpM5X4YrN1yDxLVBfL2Q7qr6FCyoYyNiyOHCFidK1Mpl5t58BSA==", |
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'd revert your changes to package-lock.json - it looks like it's using an older npm or something as it seems to have just replaced the integrity hashes with sha1 from the existing sha512 versions and toggled some other internal boolean flags - but changed no actual packages/versions used.
@@ -1,155 +0,0 @@ | |||
/** |
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.
This file is referenced in the native module template. I assume that the removal of these headers will mean that native modules need to be rewritten to #import JavaScriptCore/JavaScriptCore.h>
in place of #import #TiBase.h
- and that any Ti* methods/types need to be JS* now too?
Do we want to retain these headers to keep the modules from having to do that?
Maybe modify them to include what TiToJS.h had before (basically just the the aliasing of Ti* to JS*)?
Or do we anticipate native modules needing to be rebuilt/modified anyways (with this or other changes)? If so we should bump the api version in the package.json to reflect that module's need to be rebuilt and are not backwards compatible.
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.
So to follow on:
I was mistaken and thought TiBase.h was removed in this PR, but it is not.
However, The native module template uses TiModule.h, which tracing up the stack imports KrollObject.h which swapped from ToTiJS.h to the actual JavaScriptCore.h.
This means that any aliased Ti* types are now gone. These types were actually available to native modules (though I'm not sure how many actually used them directly). As a result, this is a breaking api change for modules, so the api version for iOS modules should be bumped: https://github.com/appcelerator/titanium_mobile/blob/master/package.json#L6
That would mean that native modules would need to be rebuilt/re-released. I'm not sure if they were going to need to be anyways as a result of this change...
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 test that so far? I would reaaaally like to prevent a breaking module change wherever possible. One possible solution could be to leave the bridge file where it is (legacy), but add a deprecation warning for developers to migrate them. I am planning the same for the Swift module effort, which would basically have a "shelled" file that only imports existing API's. This could eventually work out. Should I try that in this PR, a different one or should we break the modules intentionally?
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.
@sgtcoolguy I just tested with an existing app (that uses Ti.Facebook v3.8.0) and it works without recompiling the module. I think that unless we actively use TiCore symbols in modules (like TiValueRef
), we are fine. And since those are supposed to be private API anyway, people should not be using it at all.
…tance of "${applicationId}" in AAR manifest. (tidev#10206) - Now replaces all ${applicationId} instances in AAR AndroidManfest.xml. - Note: This was a bug when building with module "titanium-firebase-core" via Titanium 7.3.0.
JIRA: https://jira.appcelerator.org/browse/TIMOB-25748
no tests
as there are no new API's, but all existing test-suites should pass.