Replace lodash with native API

[SukkaW]

Feature Request

The idea came from hexojs/site#1139 (comment) & #3677.

There is an article suggests we don't need lodash anymore.

According to benchmark below we can see es6 performance more or less as same as Lodash, in term of CPU, Memory or Handling time, at least in browser.

• https://dustinpfister.github.io/2017/11/20/lodash_foreach/
• https://hackernoon.com/es6-lodash-native-javascript-nodejs-example-tutorial-map-function-functional-programming-performance-speed-69645e613049
• https://www.reddit.com/r/javascript/comments/8j2hmq/performance_lodash_vs_es6_map/

There are also some benchmark of lodash vs es6 and es6 is definitely much faster in browser:

• https://blog.bitsrc.io/you-dont-need-lodash-or-how-i-started-loving-javascript-functions-3f45791fa6cd
• https://codeburst.io/why-you-shouldnt-use-lodash-anymore-and-use-pure-javascript-instead-c397df51a66

IMHO, we might consider replace at least some lodash with native js.

A guide about how to replace lodash with es6: https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore

A list of files that requires lodash:

hexo

• lib/plugins/console/deploy.js
• lib/theme/view.js
• lib/plugins/filter/template_locals/i18n.js
• lib/theme/index.js
• lib/hexo/load_config.js
• lib/plugins/filter/post_permalink.js
• lib/plugins/helper/toc.js
• lib/plugins/helper/date.js
• lib/hexo/multi_config_path.js
• lib/plugins/filter/new_post_path.js
• lib/hexo/post.js
• lib/hexo/index.js
• test/scripts/hexo/load_config.js
• test/scripts/filters/backtick_code_block.js

We might start with lib located under lib/plugins/

warehouse

• lib/document.js
• lib/model.js

cc @curbengh @segayuu

[SukkaW]

Also, benchmarks are needed to see if the generation becomes faster after we remove lodash.

[curbengh]

I created a project to help us learn from each other's PRs in this task.

Currently, Hexo exposes lodash function globally. If we manage to refactor everything, we might consider dropping lodash entirely. That is definitely a breaking change, perhaps part of v5 roadmap.

[SukkaW]

Currently, Hexo exposes lodash function globally. If we manage to refactor everything, we might consider dropping lodash entirely. That is definitely a breaking change, perhaps part of v5 roadmap.

@curbengh We might drop in helpers & filters first, which might not cause any breaking changes and can be done in v4.

[SukkaW]

Currently, there is no better ways to replace lodash.merge or lodash.asignIn with vanilla JS. I assume it is the reason we should use lodash.

[curbengh]

One annoyance I found with Object.assign() is that it doesn't replace key with undefined value, especially when assigning a default config for a plugin. a key will have undefined/null value when the value is left empty, even the default config has empty keys. As such, I always need to check for undefined and assign default value again.

lodash's _.defaults (used previously in hexo) doesn't need that extra step.

// Sample _config
const hexo = { aaa: { bbb: undefined } }

hexo.aaa = Object.assign({ bbb: 'ccc' }, hexo.aaa)
// undefined

hexo.aaa = _.defaults({ bbb: 'ccc' }, hexo.aaa)
// 'ccc'

hexo.aaa = _.defaultsDeep({ bbb: 'ccc' }, hexo.aaa)
// 'ccc'

hexo.aaa = _.merge({ bbb: 'ccc' }, hexo.aaa)
// 'ccc'

hexo.aaa = _.assign({ bbb: 'ccc' }, hexo.aaa)
// undefined

hexo.aaa = _.assignIn({ bbb: 'ccc' }, hexo.aaa)
// undefined

hexo.aaa = _.extend({ bbb: 'ccc' }, hexo.aaa)
// undefined

---

A quirk with _.defaults() is that the parameters need to be reversed, otherwise it replaces the user config...

// User config
const hexo = { aaa: { bbb: 'custom' } }

hexo.aaa = _.defaults({ bbb: 'ccc' }, hexo.aaa)
// 'ccc'

hexo.aaa = _.defaults(hexo.aaa, { bbb: 'ccc' })
// 'custom'

But it doesn't replace null though 😞

const hexo = { aaa: { bbb: null } }

hexo.aaa = _.defaults(hexo.aaa, { bbb: 'ccc' })
// null

[SukkaW]

@curbengh Yeah, only replace _.defaults with Object.assign when there is no undefined will be met.
Also, when there is no prototype thing need to be merged, Object.assign could be used to replace _.assignIn as well, just as I did in #3785

[SukkaW]

I have tried Object.getPrototypeOf, Reflect.getPrototypeOf even deprecated __proto__, but none of them could match the performance of lodash.merge.

[SukkaW]

I have nearly finished:

function extend(...args) {
  for (let i < args.length - 1; i >= 0; --i) {
    for (const key in args[i])
      args[0][key] = args[i][key];
  }

  return args[0];
}

The extend() below could merge multiple one-level objects along with its prototype. But it just can not perform a deep object merge.

And unfortunately, the locals in lib/theme/view has multiple level.

---

The config, theme config along with lodash itself was bind to Locals as prototype:

hexo/lib/hexo/index.js

Lines 359 to 365 in e423773

	Locals.prototype.config = config;
	Locals.prototype.theme = Object.assign({}, config, theme.config, config.theme_config);
	Locals.prototype._ = _;
	Locals.prototype.layout = 'layout';
	Locals.prototype.env = this.env;
	Locals.prototype.view_dir = join(this.theme_dir, 'layout') + sep;
	Locals.prototype.site = this.locals.toObject();

[SukkaW]

Hexo has completely replace lodash with native JavaScript after #3969 is merged, so the issue can be closed now.

I have added a separate item Remove _ (lodash) from Locals to Roadmap (#2492). Since removing lodash from Locals should considered as a Breaking Changes, we will finish it in Hexo 5.0.