[TIMOB-9662] Android: Nested CommonJS Modules Replace Existing CommonJS Modules
GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2012-06-21T11:36:39.000+0000 |
Affected Version/s | Release 2.1.0 |
Fix Version/s | Release 2.1.0, Sprint 2012-13 Core |
Components | Android |
Labels | core, look1, regression |
Reporter | Dawson Toth |
Assignee | Bill Dawson |
Created | 2012-06-20T12:43:43.000+0000 |
Updated | 2017-03-16T22:04:27.000+0000 |
Description
Problem
When nesting CommonJS modules, module definitions can override existing CommonJS module definitions. This is a regression introduced sometime in the last month, though I do not have a specific point.
Reproduction
Attached "NestedConfusionReproduction.zip". Extract it to the Resources directory of an app, and run it on any Android environment. (Note that in this reduced reproduction, moving some of the requires around can avoid this bug. But in larger projects, or more complicated require scenarios, it cannot be so easily avoided.)
What's Happening Wrong in Reproduction
The app does the following:
- app.js require's a specific view (ti.cloud.ui/buttons/chooseAPhoto).
- The specific view requires a generic view (ti.cloud.ui/buttons/generic).
- Both views require a single utility module (ti.cloud.ui/utils) and store it in a variable U.
When the generic view's createView method is called, it alerts the U variable. It also alerts a fresh require of the utility module. The expected behavior is these two would output the same thing, right? But the alert shows that both are messed up: U contains buttons/generic and the fresh require contains buttons/chooseAPhoto. (Each has unique methods, so it is easy to tell which module has been passed to alert.)
Attachments
Added an additional reproduction explanation.
I've got this pinned down I think. Working on fix.
Pull request ready https://github.com/appcelerator/titanium_mobile/pull/2443
Tested with the latest CI, and everything's working great again (as far as my testing shows). @Neeraj: I'm pretty confident I've duplicated [TC-987] with this ticket. The behavior Ivan reported is identical to what I was seeing.
i think this was mistakenly reopened
Closing ticket as fixed.