Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1168] Replace underscore with Lo-Dash

GitHub Issuen/a
TypeImprovement
PriorityMedium
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sAlloy 2.0.0
ComponentsTooling
Labelsn/a
ReporterTim Poulsen
AssigneeFeon Sua Xin Miao
Created2014-10-15T17:06:40.000+0000
Updated2019-08-08T09:54:18.000+0000

Description

Investigate the ramifications of replacing underscore with Lo-Dash. Test Alloy compile-time and runtime code to determine what changes would be needed. Create a plan for deprecating, then replacing underscore, if that's the option we take. This will include documenting any differences for developers. Underscore 1.7.* is incompatible with Alloy. So if we stick with that, we'll need a ticket to update Alloy to support the newest underscore releases.

Comments

  1. Malcolm Hollingsworth 2014-10-15

    What changed and to what degree that means underscore is no longer a viable library? If one or two things; baby and bath water comes to mind. If everything - then how did this happen on a dot update?
  2. Tim Poulsen 2014-10-15

    With ALOY-1159 we'll be updating to Underscore 1.6.0. The key change between it and 1.7 seems to be: {quote} "Underscore templates no longer accept an initial data object. _.template always returns a function now." {quote} from http://underscorejs.org/#changelog However, even accounting for that difference, the Alloy compiler errors out with a ".split is not a method of undefined" error. The fix for that might be easy, and might be the ultimate change here. Lodash offers an underscore-compatible version, is faster, offers additional methods which are not provided by underscore, and provides more consistent APIs. See http://stackoverflow.com/a/13898916/292947 for example. There's also a Backbone-only subset, which devs could possibly drop in for greater speed / smaller size if they're not using other functions. If we go with lodash, we would use the underscore version and expose it within Alloy as the _ variable so that the change should be transparent to developers.
  3. Creative 2015-06-23

    This priority should be higher, the performance and extra functions are a huge help for development. I've personally added it myself in the Alloy.js file already (by overriding the _ variable) but sadly it is overwritten during compilation on each app/models/*.js file, so I cant use it everywhere. It would be a really nice feature to actually edit the alloy.js yourself, because its very unclear that additional javascript is added during compiletime. Why dont we just have a one-time-only generated alloy.js?
  4. Creative 2015-11-25

    Can we increase the priority for this improvement? Perhaps even we should aim for a setup where the end user can use an alloypackage.json to decide which packages to require (but somehow still have a default package.json shipped with Alloy which is overwritable and in the root of the project dir). Imagine a package.json where all modules are automagically loaded into the Alloy namespace...
  5. Brenton House 2016-03-15

    I am getting ready to replace underscore w/ lodash and can submit a PR when it is finished, if so desired. Is there any reason that the underscore used by the build is tied to the underscore used by the app? Can those two be separated so that Alloy build uses its own underscore/lodash and the app has its own version? Thanks!
  6. Brenton House 2016-03-16

  7. Feon Sua Xin Miao 2017-12-12

    PR: https://github.com/appcelerator/alloy/pull/862 Note: the pr only take lodash as an npm dependency and use it internally by the Alloy complier.
  8. Feon Sua Xin Miao 2017-12-12

    https://github.com/appcelerator/alloy/pull/842 includes a version of lodash in the lib folder.
  9. Hans Knöchel 2019-08-08

    Was the lodash change ever merged to Alloy or does it still use Underscore?
  10. Ewan Harris 2019-08-08

    At runtime, alloy still uses underscore. I'll add this into the "Alloy 2.0.0" release just to keep it on my radar

JSON Source