[TIMOB-24543] iOS: Module assets not copied to packaged module, additional weird behaviors
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | High |
Status | Open |
Resolution | Unresolved |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | cb-tooling |
Reporter | Hans Knöchel |
Assignee | Unknown |
Created | 2017-03-29T11:47:41.000+0000 |
Updated | 2020-01-31T20:53:45.000+0000 |
Description
Here is the thing: The developer has a native iOS module, creates it with
appc ti new -t timodule
and finds the "assets" directory in the top directory. You create a "test.js" or place an image in there. When using the (deprecated) build.py, it will encrypt the files and copy the generated ones into /iphone/assets. When using the appc ti build -p ios --build-only
command, the directory will not be copied to the zip and the generated "assets" directory is not copied to iphone/assets. If you place the assets in iphone/assets directly, this will still not copy it to the module zip.
See the attached module project and use the above comments to check the output.
Proposed fixes:
- Copy the encrypted assets into the zip file
- Do not place the generated "assets" diretory in /iphone (only happening with build.py, so that's fine since it's deprecated).
Hey [~cbarber], more iOS module CLI stuff! I also noticed that the generated .zip is sometimes corrupt and throws a zip-error, but that's something different.
I'm not very well versed on how .js files should be handled during the module build. CommonJS module should definitely be encrypted via
titanium_prep
, but for a native module has a .js file in the assets directory, I'm not certain the expected behavior. Regarding the corrupt zip files, that's interesting. We switched to archiver instead of adm-zip and we haven't had too many issues. Every Android build uses archiver to generate the apk. One thing that comes to mind is I have a pending PR (https://github.com/appcelerator/titanium_mobile/pull/8900) just waiting for someone to click the merge button that will update archiver from v1.0.1 to v1.3.0. There may have been a known issue that has been resolved?