Issue with _.partial and placeholders

[eauchat]

Thanks for the amazing library!!!
Hope this issue can be of any use for improving it, if so this will be my tiny tiny contribution to a tool I've benefited so much for very long :)

I'm having an issue with using the default placeholder with _.partial.

Here is a code example of the issue:

var _ = require("underscore");

const add1 = (a, b, c, d) => { return a + b + c + d }
let myFunc1 = _.partial(add1, 10, 100, _, 5)
console.log(myFunc1(1000))
// "110[object Object]5"

_.partial.placeholder = _

const add2 = (a, b, c, d) => { return a + b + c + d }
let myFunc2 = _.partial(add2, 10, 100, _, 5)
console.log(myFunc2(1000))
// 1115

The following:

console.log(_.partial.placeholder)
_.partial.placeholder = _
console.log(_.partial.placeholder)

seem to log twice the underscore object/function but they look slightly different:
first log:

function _8(obj)
    VERSION: "1.13.8"
​    _: function _8(obj)
​    after: function after4(times7, func)
    ...

second log:

Object
    VERSION: "1.13.8"
​    __esModule: true
​    after: function after4(times7, func)
    ...

I'm wondering if the issue comes from the bundler I use (esbuild), but this issue does not occur with underscore 1.13.2 so I'm wondering what may provoke this change and if it is desired.
Feel free to close if that seem out of underscore's scope, but I'd love to understand what could be causing this issue.

Note that the issue is not so hard to resolve, just need the _.partial.placeholder = _ line. But without it, placeholder won't work, the underscore function will be passed as argument.

[jgonggrijp]

Thanks for the explicit appreciation, it means a lot to me and @jashkenas (even though he will probably not read this).

Also, thanks for the detailed report. This helped me quickly diagnose the problem. The problem is indeed with esbuild. It hit a persistent "gotcha" with interoperability between ESM and older module systems that boils down to the following.

In old module systems, every module can export only one thing. CommonJS calls this thing module.exports. If you want to export multiple things, this is still possible, because you can make that one thing an object that has the multiple things as properties. Since that one object is the "real" thing you're exporting, it can also be a function. Underscore leverages this by making the wrapper function _ double as its namespace handle (and the partial placeholder and the entry point for configuration). It has this approach in common with other old libraries, like jQuery where it is the $ wrapper.

That one export is analogous to ESM's default export: it is what you get by default when importing from the module and it can be anything the exporter wants it to be. However, ESM actually allows multiple exports, in addition to or even instead of the default export. The exports are bundled together in a namespace object. Importantly, that namespace object is outside of the library author's control. It is not analogous to module.exports but rather to module itself. AMD and UMD have no analogy to ESM's namespace object whatsoever.

Due to the fact that ESM has this additional layer of exports, there is room for confusion on how to emulate lines like var _ = require('underscore');. The correct interpretation, which I know is followed by node.js and rollup, is the following:

import _ from 'underscore';

but the following, wrong but also plausible-looking interpretation is occasionally followed as well, in this case by esbuild:

import * as _ from 'underscore';

This is why your _ is ESM's namespace object, which Underscore has no access to and can therefore not be the default placeholder, instead of the traditional multipurpose function that Underscore explicitly defines and sets as export default, export _ as well as _.partial.placeholder.

You can confirm that the problem is only with esbuild by going to https://underscorejs.org, opening the devtools and writing _ === _.partial.placeholder into the console. It will echo true. Important to note: Underscore is already written using ESM notation internally and the bundle on the website was generated using rollup.

There are a few things you can do:

1. Change your import line to var _ = require('underscore')._;. While undocumented, the _ function contains circular references to itself (_._ and _.default) because we noticed that some tools are messing up their interop. Hence, this adjusted import line will work with any tool regardless of the interpretation. You can rely on these references to continue to exist in future 1.x and 2.x versions of Underscore.
2. Start using ESM import notation. esbuild is messing up here because it (incorrectly) converts your CommonJS notation to ESM notation and then uses the ESM formatted version of Underscore directly. You might as well skip the CommonJS emulation.
3. Report this as a bug to esbuild. This might not lead to a change because there is a highly vocal minority who strongly believe that the wrong interpretation is the correct interpretation. However, you could try whether linking to my explanation above adds any weight.
4. Switch to a better bundling tool such as rollup.

I cannot explain why you see this issue with 1.13.8 but not with 1.13.2, unless you also updated esbuild in parallel. In that case it might be a recently introduced bug (or "feature") in esbuild.

I will close this issue and mark it as "invalid", because this is not an issue with Underscore but with esbuild. Please don't take this as a criticism; you were right to identify and investigate this issue and also to ask for help here. The conversation can also continue.

[eauchat]

Thank you so much @jgonggrijp for the detailed answer, very precious and extended explanations which help me understand the issue :)

Thanks also for the many ideas on how to workaround the issue :)

I'm in the process of switching to ESM notation so I guess this means very soon I won't have the issue, which is great.
Still I reported the issue to esbuild so that the feedback is there and maybe that can be useful for improving it, I don't know.
For the rest I'm going to stick to using esbuild for now because it has many qualities one of which being to be much faster than rollup, which for the use I'm making is very precious, but it's good to know some alternative may be behaving differently.

Thanks again so much for taking the time to answer in such a detailed way, I appreciate it a lot :)