Update Lodash to 3.x

[marcelgerber]

Now that Lodash 3 was released (latest version as of writing this: Lodash 3.1.0), we should consider switching over to the new version.

It's not 100% backwards-compatible (see Lodash Changelog for breaking changes), so I'd suggest this:
We should leave src/thirdparty/lodash.js untouched and introduce a new src/thirdparty/lodash-3.js, which will be the only version used by Brackets itself and which extension developers can switch over to.
If possible, we can also log deprecation warnings to the console to remind developers of switching over to the new version.

I'd like to start working on this this week if you're okay with that.

[le717]

Question: once it was decided the Lodash 2 deprecation period was up, would lodash-3.js be renamed to simply lodash.js or would it remain versioned? If it was renamed, you have to somehow alias lodash-3.js to lodash.js to prevent all the extensions from breaking again and again eventually deprecate and remove lodash-3.js, and the cycle continues with every major update increase.

On the other hand, leaving the file versioned by major version from now on would make it clear what version is in use and reduces the amount of deprecation work that must be done: just mark the old version and when it comes times, remove it and everything else stays the same.

[marcelgerber]

Yeah, I intended to have versioned files, just like Python did it with python = Python 2 and python3 = Python 3.
Furthermore, as these changes are, from what I can tell, not too breaking (or, Brackets & extensions didn't make use of the full potential of Lodash), I think after some time we can create a RequireJS alias that maps lodash to lodash3, so that we can safely remove the old version. Most extensions should still work.

[peterflynn]

I'd actually vote in favor of just directly upgrading the library in place. We've done that in the past for libraries that had breaking changes, e.g. jQuery.

Looking at the changelog, I think the impact should be very limited. Many of the changes are edge cases that would be unusual to rely on, or APIs that aren't used frequently. A number of extensions include their own copy of Underscore or Lodash, and although I sorta wish they didn't, that also reduces the impact.

I did a sweep through the entire extension registry and these are the only potential issues I was could see:

• baig.brackets-zotero -- .rest with > 1 arg
• gruehle.markdown-preview -- .template with > 1 arg
• quick-require -- .template with > 1 arg
• themes -- .template with > 1 arg
• maybe bsirlinger.github-access -- .flatten, unclear if relies on deep flatten
• maybe fdecampredon.brackets-epic-linter -- .flatten, unclear if relies on deep flatten

It looks like backwards-compatible fixes should be possible in all those cases, so I suggest we file bugs on each extension and then wait for the start of a release cycle after most of the fixes are in (since we're in no rush to upgrade Lodash).

[le717]

Off topic, thanks for posting that list. I read the change log but missed _.template. I'm updating the Show Whitespace extension and didn't know Lodash 3 changed it.

[le717]

After hearing @peterflynn's case, I'd also vote direct update without versioning, as it has been done before and the risks here look to be minimal.

[marcelgerber]

@peterflynn @le717 I filed issues with all the extensions you found (and also one other) so we can hopefully do the update in Release 1.4 👍