feat(cli): UTExportedTypeDeclarations support for file associations#25
Conversation
| if association.ext.is_empty() { | ||
| dict.insert( | ||
| "CFBundleTypeExtensions".into(), | ||
| plist::Value::Array( | ||
| association | ||
| .ext | ||
| .iter() | ||
| .map(|ext| ext.to_string().into()) | ||
| .collect(), | ||
| ), | ||
| ); |
There was a problem hiding this comment.
🔴 Inverted condition causes CFBundleTypeExtensions to be inserted only when ext is empty
The condition on line 328 is inverted. It inserts CFBundleTypeExtensions only when association.ext.is_empty(), which will always result in an empty array being inserted.
Click to expand
Actual behavior
The code:
if association.ext.is_empty() {
dict.insert(
"CFBundleTypeExtensions".into(),
plist::Value::Array(
association.ext.iter().map(|ext| ext.to_string().into()).collect(),
),
);
}This only inserts CFBundleTypeExtensions when ext is empty, resulting in an empty array.
Expected behavior
The condition should be if !association.ext.is_empty() to insert extensions when they exist.
Impact
File associations with extensions (the common case) will not have their extensions registered in the Info.plist, breaking macOS file type associations.
Was this helpful? React with 👍 or 👎 to provide feedback.
| association | ||
| .name | ||
| .as_ref() | ||
| .unwrap_or(&association.ext[0].0) | ||
| .expect("File association must have a name") | ||
| .to_string() | ||
| .into(), |
There was a problem hiding this comment.
🔴 Panic when FileAssociation.name is None due to removed fallback
The code uses .expect() on association.name which is an Option<String>, causing a panic when name is not provided.
Click to expand
Actual behavior
The new code:
association
.name
.as_ref()
.expect("File association must have a name")This panics when name is None.
Expected behavior
The old code had a fallback to use the first extension as the name:
.unwrap_or(&association.ext[0].0)Impact
The example config at examples/file-associations/src-tauri/tauri.conf.json has file associations without name fields (e.g., the png, jpg, gif associations), which will cause a panic at bundle time on macOS.
Recommendation: Restore the fallback: .unwrap_or(&association.ext[0].0) or use .unwrap_or_else(|| &association.ext.first().map(|e| &e.0).unwrap_or(&"Unknown".to_string()))
Was this helpful? React with 👍 or 👎 to provide feedback.
| if let Some(content_types) = &association.content_types { | ||
| dict.insert( | ||
| "UTTypeConformsTo".into(), | ||
| plist::Value::Array(content_types.iter().map(|s| s.clone().into()).collect()), | ||
| ); | ||
| } |
There was a problem hiding this comment.
🔴 UTTypeConformsTo uses wrong source field (content_types instead of exported_type.conforms_to)
When building UTExportedTypeDeclarations, the code incorrectly uses association.content_types for UTTypeConformsTo instead of exported_type.conforms_to.
Click to expand
Actual behavior
The code at lines 284-289:
if let Some(content_types) = &association.content_types {
dict.insert(
"UTTypeConformsTo".into(),
plist::Value::Array(content_types.iter().map(|s| s.clone().into()).collect()),
);
}This uses association.content_types which is meant for LSItemContentTypes in CFBundleDocumentTypes.
Expected behavior
Should use exported_type.conforms_to as defined in ExportedFileAssociation struct at crates/tauri-utils/src/config.rs:1215-1216:
pub conforms_to: Option<Vec<String>>,Impact
The conformsTo field in the config (e.g., ["public.json"] in the example) will not be used for UTTypeConformsTo, breaking custom type declarations that need to specify their conformance hierarchy.
Recommendation: Change to use exported_type.conforms_to instead of association.content_types
Was this helpful? React with 👍 or 👎 to provide feedback.
Benchmark PR from qodo-benchmark#166