Replace Underscores.js with Lodash.js

[ChopinBach]

Should we replace Underscores.js with Lodash.js?

​Discussed in Slack today (April 10th, 2018).

It was suggested for converting WP Core to lodash, ​jscodeshift could be leveraged.

Here is a list of ​API pairings between lodash and underscores.

Concerns:

Lodash 5.0 is set to have some ​backwards incompatible changes that could make the migration awkward.

General backwards compatibility concerns as well. How do we want to handle Backwards Compat? Most likely only core will be changed, and a migration path/tool will be offered out to theme/plugin authors.

[johnbillion]

Can someone summarize the reasons for switching?

[aduth]

Context:

• Gutenberg PR: Reference Lodash as external module ​https://github.com/WordPress/gutenberg/pull/5933
• Core JS Meeting 2018-04-10 ​https://wordpress.slack.com/archives/C5UNMSU4R/p1523367735000195
• Core JS Meeting 2018-04-03 ​https://wordpress.slack.com/archives/C5UNMSU4R/p1522761992000666

Abbreviated summary of "reasons": ​https://github.com/WordPress/gutenberg/pull/5933#issuecomment-379794864

[adamsilverstein]

@johnbillion quick summery: since Gutenberg has chosen to use lodash, we should switch core's usage over as well when possible to avoid loading duplicate, redundant libraries. For example, using media in Gutenberg means we are loading both lodash and underscore.

[sc0ttkclark]

Just a friendly reminder from your neighborhood plugin developer that you'll want to replace underscore usage in core with lodash, but leave underscore as a registered script while noting in the official WP release that it has been deprecated and will be removed in WP 5.x (whatever version that might be) -- so that plugins using underscore can continue to remain compatible with this upcoming major WP release while they make the transition.

[desrosj]

@adamsilverstein @aduth Can you summarize what the levels of effort and risk would be for tackling this?

@sc0ttkclark 100%. I don't know that we would deprecate it, but leaving it available through wp_enqueue_script() or as a dependency is definitely the best way for backwards compatibility. I think we could continue packaging Underscore for a few releases, or we could switch to loading it from an external CDN.

[desrosj]

To clarify, what is the level of effort for replacing Underscore with Lodash throughout Core only with the knowledge that plugins/themes can continue enqueuing Underscore if they'd like.

[aduth]

If I recall correctly, it should be a generally low-risk effort. Underscore and Lodash are very similar tools, and in a large number of cases share an identical API. Sometimes there are small differences in naming.

Also mentioned in the original ticket, Lodash has a migration guide here:

​https://github.com/lodash/lodash/wiki/Migrating

In the past, I've observed some specific differences that can be more subtle and cause some issues:

​https://github.com/WordPress/gutenberg/issues/4043#issuecomment-361049257

Generally speaking, there should be a fairly straight-forward transition for the majority of usage.

Personally, I think the value of undertaking the effort should be considered, or at least targeting specific core scripts which currently depend on Underscore, and where there's a high value of migrating to Lodash. What comes to mind for me is reducing the chances that both Lodash and Underscore would be loaded on the same page in a default installation of WordPress. For example, it can be seen on the post editor screen that both are loaded (noted in comment above).

My suggestion would be to focus on those packages first. It's a bit hard to pinpoint, since anything which indirectly depends on Underscore will cause it to be loaded. Unless I'm unaware of some better option, it may require some close inspection of the $wp_scripts global to see how those dependencies are resolved. It might be a good first task to identify and prioritize those dependencies.

[aduth]

Discussed briefly during today's JavaScript chat: ​https://wordpress.slack.com/archives/C5UNMSU4R/p1587479046337900

[adamsilverstein]

I spent a little time looking at core use of 'underscore' and found the following dependencies:

The following core scripts depend on 'underscore':

• 'color-scheme-control'
• 'backbone'
• 'wp-util'
• 'code-editor'
• 'wp-theme-plugin-editor'
• 'customize-base'
• 'customize-models'
• 'customize-views'
• 'shortcode'
• 'wp-api'
• 'post'
• 'editor-expand'
• 'nav-menu'

'backbone' is depended on by:

• 'wp-backbone'
• 'wp-playlist'
• 'customize-models'
• 'ap-api'
• 'text-widgets'
• 'custom-html-widgets'

'wp-backbone' is depended on by:

• 'revisions'
• 'customize-widgets'
• 'customize-nav-menus'
• 'media-models'
• 'theme'

What comes to mind for me is reducing the chances that both Lodash and Underscore would be loaded on the same page in a default installation of WordPress. For example, it can be seen on the post editor screen that both are loaded (noted in comment above).

I would agree, fixing the duplicate script load on the editor screen is a high priority, so it makes sense to tackle the use by media-modals first. According to this document: ​https://github.com/lodash/lodash/wiki/Migrating#backbone Backbone should work fine with Lodash. I'm going to test by creating a lodash-wp-backbone and having media-models depend on that.

[adamsilverstein]

I'm going to test by creating a lodash-wp-backbone and having media-models depend on that.

I tried this and ran into some blocking problems. Going to have to take it more slowly to see what breaks.