-
Notifications
You must be signed in to change notification settings - Fork 986
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
Fix error parsing plist_file_entry when adding extension in xcode #765
Conversation
Thanks for submitting the PR. Now we just need to get working tests for this change :-) @leogoesger Please check the failing tests. |
@nikhilkh I corrected the linter error and unit test. Thanks |
Codecov Report
@@ Coverage Diff @@
## master #765 +/- ##
==========================================
+ Coverage 74.42% 74.42% +<.01%
==========================================
Files 11 11
Lines 1830 1834 +4
==========================================
+ Hits 1362 1365 +3
- Misses 468 469 +1
Continue to review full report at Codecov.
|
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.
Great! CI looks better now.
Looks like you accidentally added package-lock.json in your last commit.
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 left some feedback.
const xcBuildConfiguration = xcodeproj.pbxXCBuildConfigurationSection(); | ||
const plist_file_entry = _.find(xcBuildConfiguration, entry => entry.buildSettings && entry.buildSettings.INFOPLIST_FILE); | ||
var projectName = ''; | ||
if (fs.readdirSync(project_dir).find(d => d.includes('.xcworkspace'))) { |
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 would recommend pulling this out into its own variable. No need to call this twice.. It would lower the number of file disk reads (readdir
) and loops.
E.g.
const workspaceCollection = fs.readdirSync(project_dir).find(d => d.includes('.xcworkspace'));
if (workspaceCollection) {
projectName = workspaceCollection.replace('.xcworkspace', '');
}
var plist_file_entry = _.find(xcBuildConfiguration, function (entry) { | ||
return ( | ||
entry.buildSettings && | ||
entry.buildSettings.INFOPLIST_FILE && | ||
projectName ? entry.buildSettings.INFOPLIST_FILE.includes(projectName) : true | ||
); | ||
}); | ||
const plist_file = path.join(project_dir, plist_file_entry.buildSettings.INFOPLIST_FILE.replace(/^"(.*)"$/g, '$1').replace(/\\&/g, '&')); |
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 am not sure if this produces correct results always.
What happens if there is two -Info.plist
that has very close identical names.
For example lets say our projectName
is MyApp
. The expected plist would be MyApp-Info.plist
. Now what if there was another plist named MyAppExtension-Info.plist
. This would also match from what is described above. It seems we are assuming that the order of the xcBuildConfiguration
always returns our project first before other.
Additionally, we are trying to remove the need of using third-party libraries such as lodash
. I would recommend rewriting this area are such.
const { buildSettings: { INFOPLIST_FILE : infoPlistFile } } = Object.values(xcBuildConfiguration)
.filter(({ buildSettings }) => (
buildSettings &&
buildSettings.INFOPLIST_FILE &&
projectName ? buildSettings.INFOPLIST_FILE.match(new RegExp(`/${projectName}-Info.plist"$`)) : false
))[0];
const plist_file = path.join(project_dir, infoPlistFile.replace(/^"(.*)"$/g, '$1').replace(/\\&/g, '&'));
If you use the above code, would recommend confirming that it continues to produce the same results as you expect.
The code above will always expect to find at least one and in my case I always expect actually two results (Debug
and Release
). Since the InfoPlist path will be identical, I only take the first one [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.
Thanks, I have never worked in xcode, nor in Cordova before. As far as JS goes,
MyAppExtension-Info.plist".includes("MyApp-Info.plist")
is false. The only way to return true would be ExtensionMyApp-Info.plist".includes("MyApp-Info.plist")
. Instead of doing the check, it might be easier to just use
entry.buildSettings.INFOPLIST_FILE === `${projectName}-Info.plist`
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.
Here is an actual INFOPLIST_FILE
value that I grabbed from a new empty project.
"MyApp/MyApp-Info.plist"
Please note that the surrounding double quotes are also in string.
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.
Update: Here are some more sample INFOPLIST_FILE
values. On the blank project I added some random watch extensions to create more data.
"MyAppWatchExtension Extension/Info.plist"
"SomeOtherWatchExtension WatchKit Extension/Info.plist"
"SomeOtherWatchExtension WatchKit App/Info.plist"
I am not sure why this one didn't have the double quotation wrapper like the other examples, but it seems there can be cases where its not wrapped.
MyAppWatchExtension/Info.plist
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, just wanted to point out that you wrote above:
The code you showed in comment is true,
MyAppExtension-Info.plist".includes("MyApp-Info.plist")
But what you wrote in code didn't reflect that previously.
entry.buildSettings.INFOPLIST_FILE.includes(projectName)
for example it would have been like these which would have matched in all cases.
"MyApp/MyApp-Info.plist"".includes("MyApp")
MyAppWatchExtension Extension/Info.plist
But I do see it is updated to ${projectName}/${projectName}-Info.plist
now.
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
return ( | ||
entry.buildSettings && | ||
entry.buildSettings.INFOPLIST_FILE && | ||
projectName ? entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`) : 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.
The ternary operator (? :
) needs to be enclosed in parenthesis. It has lower priority than the &&
operator. Else, it crashes on my app because it returns true for an entry that has no buildSettings
.
return ( | ||
entry.buildSettings && | ||
entry.buildSettings.INFOPLIST_FILE && | ||
projectName ? entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`) : 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.
How about this idea:
projectName ? entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`) : true | |
!(projectName && entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`)) |
What is the status of this proposal? |
I included the suggested edits |
Thanks. I restarted a Travis CI build job due to a test timeout, it seems to be green now. I have some other remarks coming up. |
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 am very sorry to say that there are some things that need to be fixed before we can consider merging this proposal:
1: As I said in PR #792, I discovered that we need to add a test case for some existing code. Someone needs to add a test case that will fail if the internal filter on *-Info.plist is broken for any reason.
2: Extra package-lock.json
file is included in this PR. Please remove it.
3: The changes proposed are not properly covered in the test suite. We need a test case that can reproduce the issue described in #764 and ensure that the issue does not reappear in the future.
Another thing is that when I tried removing a few lines from the proposed change, npm test
did not fail in my work area:
diff --git a/bin/templates/scripts/cordova/lib/projectFile.js b/bin/templates/scripts/cordova/lib/projectFile.js
index 84200517..862addd1 100644
--- a/bin/templates/scripts/cordova/lib/projectFile.js
+++ b/bin/templates/scripts/cordova/lib/projectFile.js
@@ -42,9 +42,6 @@ function parseProjectFile (locations) {
let projectName = '';
const workspaceCollection = fs.readdirSync(project_dir).find(d => d.includes('.xcworkspace'));
- if (workspaceCollection) {
- projectName = fs.readdirSync(project_dir).find(d => d.includes('.xcworkspace')).replace('.xcworkspace', '');
- }
const xcBuildConfiguration = xcodeproj.pbxXCBuildConfigurationSection();
const plist_file_entry = _.find(xcBuildConfiguration, function (entry) {
return (
return ( | ||
entry.buildSettings && | ||
entry.buildSettings.INFOPLIST_FILE && | ||
!(projectName && entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`)) |
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.
Needs to be corrected (I got it wrong in my suggestion):
!(projectName && entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`)) | |
!(projectName && !entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`)) |
or better yet:
!(projectName && entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`)) | |
(!projectName || | |
entry.buildSettings.INFOPLIST_FILE.includes(`${projectName}/${projectName}-Info.plist`)) |
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 would like to recommend that we close this PR in favor of PR #795, which includes these updates, added test cases, and some more rework. I would like to thank @leogoesger for your efforts in reporting #764 and contributing this proposed solution. @leogoesger will definitely get co-author credit once we merge PR #795.
@brodybits Thanks, and no problem :) |
See apache#765 (comment) Co-authored-by: エリス <[email protected]>
See apache#765 (comment) Co-authored-by: エリス <[email protected]>
Closes #764