[TIMOB-26543] TiAPI: require() behavior differs across platforms
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Android, iOS |
| Labels | n/a |
| Reporter | Hans Knöchel |
| Assignee | Unknown |
| Created | 2018-11-10T19:59:46.000+0000 |
| Updated | 2018-11-12T11:33:58.000+0000 |
Description
We noticed two weird glitches between iOS and Android:
1. The "utils" module seems to be treated quite special on iOS, because the kroll-core thinks we want to use "Ti.Utils" - whyever that is
2. If the "utils" module causing an error in Alloy controller if require'd via
./utils on Android, but works fine on iOS.
To replicate, simply create a new Alloy project and add a file "utils.js" to app/lib. Then, create a sub-controller, let's day controllers/test/index.js and try to import/require it from there
The app crashes on Android, works fine on iOS.
Workaround: Rename the file to something like "app-utils".
1) The
utilsmodule behaviour only happens as a fallback if just use the wordutilsas the module, using an absolute or relative path fixes this issue. When requiring a file from libs in a controller you almost always wanna use an absolute path. 2) This looks like a parity bug,require('./utils')where utils resides under lib should not work from any controller to my knowledge. The files don't reside in the same folder so _shrug_, I wouldn't agree that this is a major issue however. Can you confirm the code below is correct? We can probably distill that down to a pure classic example.function doClick(e) { Alloy.createController('/sub/index.js').getView().open() } $.index.open();function doClick(e) { const util = require('./utils'); alert(util);} $.index.open();[~eharris] I agree it is not major, since a workaround is applicable. It's still something many people run into and takes a good bunch of time to properly find out what's going on. Your example sounds correct and probably even works, but in our case, we used ES6+ imports and they all crashed. E.g.:
import Utils from 'utils'; import { method1, method2 } from 'utils';