Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-16078] Implement full NodeJS require specs so we can use NPM for modules

GitHub Issuen/a
TypeNew Feature
PriorityCritical
StatusClosed
ResolutionFixed
Resolution Date2016-07-07T18:32:42.000+0000
Affected Version/sn/a
Fix Version/sRelease 6.0.0
ComponentsAndroid, iOS
Labelsbreaking-change, npm, package.json, require
ReporterFokke Zandbergen
AssigneeChristopher Williams
Created2013-12-23T08:07:55.000+0000
Updated2018-11-16T15:42:06.000+0000

Description

I know from [~jhaynie] that Hyperloop (and thus Ti.Next - likely Titanium 4.x) will support the full [NodeJS require specs](http://nodejs.org/api/modules.html) so to make it possible to use NPM as a package manager for all kinds of modules. This is also the direction ALOY-86 has been going, asking for widget dependency management. I open this ticket to request looking into the possibility of implementing this in Titanium 3.x already. * What are the obstacles to change the require implementation to require both JS and native modules from the local and global node_modules paths? * What does it take to get Alloy to loading e.g. widgets from local and global installed node_modules? * How should the builder copy in global node_modules to the project when it packages the app? I think this would spur and new wave of Titanium native/CommonJS modules and Alloy widgets, sync adapters etc that would really boost the platform, as well as making it easier to re-use proprietary components in multiple projects myself. Ultimately, I think tiapp.xml and manifest could even be replaced by package.json?

Comments

  1. Ritu Agrawal 2013-12-26

    Makes sense. Moving this feature request to engineering for further evaluation.
  2. Fokke Zandbergen 2013-12-26

    Also see the blog I wrote about the fantastic implications of these features at http://www.tidev.io/2013/12/23/hyperloop-npm/
  3. me@gmail.com 2013-12-26

    I 1000% agree "Ultimately, I think tiapp.xml and manifest could even be replaced by package.json"
  4. Chris Barber 2013-12-26

    I've thought about getting rid of tiapp.xml quite a bit and determined that we're better with it than without it. 1. XML allows comments. This may not seem that important, but it is. People comment out and uncomment modules and flags all the time. 2. XML allows attributes. This can be hacked in JSON, but XML attributes are pretty elegant. 3. XML files can easily be validated against a schema. Furthermore, I'm cautious about mucking up the package.json. If the is a syntax error in the package.json, then we are going to get a ton of Jira tickets about NPM which is obviously not the problem. There doesn't seem to be any "future reserved words" in the package.json, so if we start using "modules" or something, then NPM decides to use that for something special, we're hosed. So, my vote is to keep tiapp.xml around a while longer.
  5. Fokke Zandbergen 2013-12-26

    I'm fine with tiapp.xml staying as long as package.json (NodeJS/NPM) compatible require is coming ;)
  6. Tony Lukasavage 2014-01-19

    Let me first begin by saying that I don't think any of this should be done before 4.0. These are major breaking changes, and while they could be introduced early through configuration settings (perhaps set a property in tiapp.xml that tells Titanium to use node.js-style requires), the core of Titanium needs to take care not to impact its current commonjs implementation within 3.X. I fully agree with "my vote is to keep tiapp.xml around a while longer" As to [~cbarber]'s points:

    From a technical perspective I don't think this is a big deal, and certainly doesn't outweigh the potential benefits of using the package.json format. The whole of the node.js community has lived without comments forever. That said, because they never had comments they are different than our developers who will have had comments and would have them taken away. There would undoubtedly be explanations to be made, but again, this seems a trivial bump to get used to in a major version transition. If we find it to be critical, it would be pretty easy to handle our own JSON parser for package.json that supports comments, but I would advise against it.

    I don't understand what XML attributes provide that JSON properties don't, particularly considering that JSON properties can be any string.

    JSON files are also easily validated. The difference between syntax validation and schema validation for what we use these configuration files is minimal enough that I don't see this be a blocker at all.

    WRT the reserved words and fitting Titanium's own configuration in there, we have a number of things we can do to make sure that this works. First off, we need to contact npm's maintainers and see what they think. Isaac has been very helpful in the past, so I just emailed him directly to see what his thoughts were. I'll find out if a sanctioned way of customizing the package.json exists, and if not, if we can get one in place. Given that they're going to finally try and monetize npm with npm Inc., I would think suggestions like this would be right up npm's alley. But I agree that we need this answer before we could even seriously consider it.
  7. me@gmail.com 2014-01-31

    Could we get some official word on 3.x support so I know if it's worth my time to create a shim module?
  8. Ingo Muschenetz 2014-01-31

    For 3.X support, it would not happen in the first half of 2014 at the earliest. If you'd like to take a stab at a shim module, it would be great.
  9. Ingo Muschenetz 2015-11-18

    [~cng] I think this is worth considering for 6.0, depending on effort. Thoughts?
  10. Christopher Williams 2016-05-23

    Need to wait for https://github.com/appcelerator/titanium_mobile/pull/8004 until I'll then work on adding node_modules folder searching to our require implies for iOS/Android...
  11. Fokke Zandbergen 2016-05-24

    (y)(y)(y)(y)(y)(y)(y)
  12. Christopher Williams 2016-06-09

    I'm still waiting on reviews for the PR that must be merged first. I'm going to push this ticket out to next sprint.
  13. Chee Kiat Ng 2016-07-07

    Tested the PR: https://github.com/appcelerator/titanium_mobile/pull/8075

    Steps to test

    1. *appc new --classic* 2. Obtain this module scapegoat from https://github.com/brentertz/scapegoat 3. put the module in /Resources/node_modules/scapegoat 4. put this in app.js 
        Ti.UI.createWindow().open();
    var scapegoat = require('scapegoat')
          escape = scapegoat.escape,
          unescape = scapegoat.unescape;
    
    var html = '<h1>Hello World</h1>',
          escaped = escape(html),
          unescaped = unescape(escaped);
          
    alert('html: ' + html + '\nescaped: ' + escaped + '\nunescaped: ' + unescaped);
    5. *appc run -p ios*

    Expected Result

    An alert will show with this result 
        html: <h1>Hello World</h1>
    escaped: <h1>Hello World</h1>
    unescaped: <h1>Hello World</h1>
    Repeat with *appc -run -p android* you can get the same result
  14. Christopher Williams 2016-07-07

    Merged to master.
  15. Lokesh Choudhary 2016-08-16

    Verified the implementation in android & IOS. Closing. Environment: Appc Studio : 4.7.0.201607250649 Ti SDK : 6.0.0.v20160816021339 Ti CLI : 5.0.9 Alloy : 1.9.1 MAC El Capitan : 10.11.6 Appc NPM : 4.2.7 Appc CLI : 6.0.0-24 Node: 4.4.4 Nexus 6 - Android 6.0.1 iOS simulator: iPhone 6S 9.3
  16. Sebastian Klaus 2016-12-14

    Following your guide cause this !https://d3vv6lp55qjaqc.cloudfront.net/items/0j2F080W0j3u0s3m3R1h/Bildschirmfoto%202016-12-14%20um%2008.31.57.png!
  17. Ingo Muschenetz 2016-12-14

    [~benutzername] Can you please post the specific code you are using?
  18. Sebastian Klaus 2016-12-14

    I'm using the exact example of [~cng]s last comment
  19. Sebastian Klaus 2016-12-14

    Fixed. Problem is using tishadow which does not support node_modules in the Resources folder. Will file a ticket

JSON Source