Skip to content
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

Merged
merged 28 commits into from Jul 26, 2018

Conversation

hansemannn
Copy link
Collaborator

@hansemannn hansemannn commented Feb 4, 2018

JIRA: https://jira.appcelerator.org/browse/TIMOB-25748

⚠️ Do not merge, yet! We need to wait until master is 8.0.0.

no tests as there are no new API's, but all existing test-suites should pass.

@build
Copy link
Contributor

build commented Feb 4, 2018

Messages
📖

👍 Hey!, You deleted more code than you added. That's awesome!

Generated by 🚫 dangerJS

IOS.prototype.build = function (next) {
this.fetchLibTiCore(next);
// no-op (used to fetch TiCore in the past)
Copy link
Contributor

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?

Copy link
Collaborator Author

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),
Copy link
Contributor

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),
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

@hansemannn hansemannn closed this May 14, 2018
@hansemannn hansemannn removed this from the 8.0.0 milestone Jun 19, 2018
@hansemannn hansemannn reopened this Jul 20, 2018
@hansemannn
Copy link
Collaborator Author

@sgtcoolguy Ready for re-review

@hansemannn hansemannn added this to the 8.0.0 milestone Jul 20, 2018
@build
Copy link
Contributor

build commented Jul 20, 2018

Messages
📖

👍 Hey!, You deleted more code than you added. That's awesome!

📖

💾 Here's the generated SDK zipfile.

Generated by 🚫 dangerJS

@@ -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
Copy link
Contributor

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.

Copy link
Collaborator Author

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!

@@ -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==",
Copy link
Contributor

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 @@
/**
Copy link
Contributor

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.

Copy link
Contributor

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...

Copy link
Collaborator Author

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?

Copy link
Collaborator Author

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.

@hansemannn hansemannn closed this Jul 25, 2018
@hansemannn hansemannn reopened this Jul 25, 2018
@hansemannn hansemannn changed the base branch from master to next July 25, 2018 15:34
@tidev tidev deleted a comment from hansemannn Jul 25, 2018
@build build added the android label Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants