That lodash-es doesn’t ESM lodash/fp, which means there is no straightforward way of using it with Vite after version 5. God help me.

I don’t even want to use it, I just want to get legacy code building on a modern version of Vite without rewriting a couple thousand lines of code. Aaaargh

▲

mediumdeviation 13 hours ago | parent | next [-]

Another fun fact - lodash/fp doesn't deduplicate with lodash when bundled. For a couple of months I was wondering why our app had bundled two copies of lodash. I dismissed it as a measurement artifact at first. It took so long to realize there was actually two copies of lodash and it was because one developer on our team had a preference for fp syntax.

▲

esperent 13 hours ago | parent | prev [-]

> lodash-es doesn’t ESM lodash/fp

Most of my career has been JS and TS and I have no idea what this means.

▲

soulofmischief 12 hours ago | parent | next [-]

I'm guessing you're only a few years into your web career, so I'll provide some background. lodash is a popular library that fills in many blanks that pre-2015 JavaScript had. It still provides value in modern JavaScript, but it's no longer as important as it used to be.

JavaScript is actually based on a standard called ECMAScript. ActionScript shares this standard, as an example. In 2015, we got ECMAScript 5, which modernized JavaScript in many ways. With that came many changes such as ECMAScript moving to a yearly update cadence, in response to the large amount of effort involved in implementing ES5, which came with a ton of changes.

One of those changes was ES modules, or ESM, which provided an official way for working with modules. The import/export syntax you're used to is a part of that spec. Before this, we had competing non-standard specifications for module loading, such as CommonJS.

ES5 reduced the need for tools such as lodash, and so it's less common in newer projects. It also is old enough to have been around before ESM was adopted, and is a large project, and so like many projects it either had to completely rewrite everything, or use transformation tools such as babel. If not, the user was responsible for using babel/etc to transform the code. Now, in modern stacks, because this is unnecessary, native support for CommonJS is being phased out, leading to OP's conundrum.

Now we have TypeScript, and the horrors of JavaScript 10+ years ago are a fading memory.

▲

esperent 10 hours ago | parent | next [-]

Nope, I'm about 15 years in and (unfortunately) deeply familiar with all of that. As someone else pointed out below, it was the use of ESM as a verb that threw me off.

Thanks for taking the effort to type out a history lesson though, hopefully someone will benefit from it.

	▲	nailer 6 hours ago \| parent [-]
		Sounds like we both got into JS around when node was released. Good times. I miss early JSConf and NodeConf.

▲

esperent 10 hours ago | parent | prev [-]

Nope, I'm about 15 years in and (unfortunately) deeply familiar with all of that as I lived and worked through it.

As someone else pointed out below, it was the use of ESM as a verb that threw me off.

▲

nailer 12 hours ago | parent | prev [-]

It’s not just you, nobody uses ESM as a verb, I think they mean:

The package doesn’t export lodash/fp in the ESM version.

	▲	johnfn 2 hours ago \| parent [-]
		Well, some people use it as a verb :)