Suggestion For V5

[jonchurch]

Hey @jdalton great to see activity here.

The past week I had started fixing up master and diving into the v4 codebase to understand the partial migration that had been started in master. I figured out which tests are broken on master (not entirely exhaustive, excludes suites that fail bc a lodash method they tested was deleted) and in most cases tracked down the commit that likely did it.

I almost posted my WIP Short Term Maintenance plan on Saturday, glad I held off! You've already knocked out items on that list.

Suggestion for V5

I'd like to suggest a direction for V5 and V6 if I may be so bold. My personal goals from my above plan and Step 0 were:

Goals

1. Get master branch to a state where it can be cloned and successfully run all tests
2. Ensure Github Actions workflows run tests on; PR opened, PR updated, push to master branch
3. Clear the way for contributions to Lodash v5
4. Document breaking changes that have already been merged to master, evaluate if they should be rolled back
5. Explore if the v4 release can be released without breaking changes from a fixed up master branch
6. Modernize master branch to 2023 package maintenance standards (debateable what that means 😂)

Non-Goals

1. Release v5
2. Break v4
3. Open PRs that are impossible to review rigorously due to volume of changes

Step 0: Decide on Master Branch Direction

Due to breaking changes already in master, decide whether it will serve as the base for a new major release or a fix-up of v4. This will inform all subsequent steps.

Examples of breaking commits are (in order of earliest to latest):

• 3b4cbc70e7
• 5baad4df1015
• bb7c959479
• 3e2b0bb763
• aa1d7d870d

I'd like to suggest that the v5 release break only the legacy AMD/UMD module support, and avoid lodash method functionality breakage.

The more I worked on my fork at jonchurch/lodash (js-test branch) the more I thought about what could bring value to a new release.

The big question is, can we publish a v5 that does not introduce breaking changes to the method functionality?

I want to see lodash v5:

• Use modern module systems (CJS and ESM dual publish)
• Drop support for ES5
• Update the DX for contribution to modern standards
  • linting
  • github action workflows on all commits to master and PRs
• Use modern package.json exports
• Export lodash.js as a barrel file instead of it being all in one to avoid publishing copies of all the methods as duplicated single files (which is what v4 currently does in the main package)
• Avoid breaking lodash v4 method functionality

These breaking changes are largely DX, package, and long term maintenance oriented. They also represent what I think is a logical way to break up development into something easier to follow and audit by the community. One new release with both packaging, test structure, support level, and functionality changes would be a pretty massive delta that could get very confusing to follow very quickly.

The TS rewrite could also happen in this v5 release, and in fact might make the transition to a functionally breaking v6 much smoother and easier to migrate to.

Having a transitional v5 release like this could also make any fixes needed to v4 compatible code much easier. We can tell people to upgrade to v5 to receive any critical fixes, and EOL v4. Imagine having to make changes to v4 with the old setup, after investing in the new setup. I think having a modern v5 with v4 API support will make it much more pleasurable to commit and release fixes to v4 compatible APIs (but release the fix in v5 only).

Those commits I listed are a non-exhaustive list of breaking changes, but they are pretty close I believe. It might make sense to start master over with a fresh migration of v4, instead of attempting to revert the non-backwards compatible changes merged into master in the past 4 years.

My Ask

What do you think? Do these suggestions resonate with you?

If offered help to achieve this functionally backwards compatible v5 approach, would you accept it?

Thanks for your time. (P.S. I'm fine with v5 using Bun for the dev runtime, runtime doesn't matter to me here)

[jonchurch]

Forgot to add but want to make clear: getting to v6 with functional changes is still the overall goal. This is a plan to get there. V5 could always introduce Future Flags so folks can get ready for v6

[Shinigami92]

TBH following are just my opinion

last lodash version v4.17.21 was released on February 21, 2021 and since then nothing was changed anymore for the lodash ecosystem in production anymore

I start to agree with @jdalton that v5 can be a fresh restart

That would mean:

• no CJS support anymore
• maybe get rid of code that is definitely not useful anymore due to JS native support

If there really really should be fixes to v4, it should be done on a separate branch for backports

---

just an example and maybe debatable, but _.now() has potentially no value anymore, because it's possible in every modern environment to just use Date.now()
so why would it worth it to have the burden in the lodash codebase to maintain this and even need to write tests for it and then have the potential that no one out there uses it 🤷

[Lsnsh]

I want to see lodash v5:

• Use modern module systems (CJS and ESM dual publish)
• Drop support for ES5
  ...

Some suggestions are good, but "Drop support for ES5", may be not a good idea, if it means droping support in final bundle package.

---

I think the new major releases, while being as compatible as possible with historical releases, need to find a ways how to avoid or fundamentally solve problems that were difficult or laborious to solve in the old major releases as much as possible, otherwise this could be a reincarnation.

I can only look at it from the user's perspective for now. I really enjoy using lodash, it's easy to use, but I'm not familiar with its history and challenges.

I just came over here after learning about what happened to lodash from a friend.

Thank you to all the friends who have contributed to lodash, I hope I can contribute too, maybe only a very small one.

[joonseokhu]

That would mean:

* no CJS support anymore

dropping CJS support makes some trouble...

For example, if you have a nodejs backend project with test suits written with jest,
then you cannot switch project to esm. Currently jest does not support ESM

[Shinigami92]

That would mean:

* no CJS support anymore

dropping CJS support makes some trouble...

For example, if you have a nodejs backend project with test suits written with jest, then you cannot switch project to esm. Currently jest does not support ESM

Might sound unfair, but maybe this is a problem by jest, not lodash 🤔
There are also more modern Test Frameworks like vitest, bun:test or even native node:test nowadays.
I think it should be a non-goal for lodash to stick with technologies from the past, but move on into the future with v5.
If you still need lodash x CJS, feel free to use v4.

[jdalton]

@joonseokhu

For example, if you have a nodejs backend project with test suits written with jest,
then you cannot switch project to esm. Currently jest does not support ESM

Check out bun.sh it has a built-in test runner bun test that mimics jest API and works with ESM.

@Shinigami92

Reducing package bloat is a goal. I'm toying with making v5 (a breaking change release) more prescriptive and narrow. I may take the opportunity to add bun specific enhancements because I want to promote Bun's way of working with module formats (things "just work").

[jonchurch]

I think it should be a non-goal for lodash to stick with technologies from the past, but move on into the future with v5.
If you still need lodash x CJS, feel free to use v4.

I see two issues here; one is that lodash is critical software and leaving millions of users without an upgrade path to a maintained version means that millions of users will never upgrade, the second is that from a release management point of view lodash never deprecated any of the things you're suggesting it drops despite having years to do so.

It's my personal opinion that software which is heavily relied upon should deprecate things it plans to drop before doing so.

(I was once upon a time working on Express v5 which will likely never be released, and one of the shocking things to me there was that simply moving folder structure was breaking for folks bc so many had relied on deep imports before the package.json exports or files keys were added to package.json which prohibits importing code outside of what you plan to expose)

Even for dropping AMD support, that's something we currently have the opportunity to warn people about before doing. I don't expect the impact to be large, but it's painless to communicate it to folks just as you would any part of your software you are deprecating.

Overall (super IMO, and "this is just like how I feel, man") I believe high quality software should provide an upgrade path to its users as well as deprecation warnings, whenever possible. And it is indeed very possible here.

[jonchurch]

@jdalton

Check out bun.sh it has a built-in test runner bun test that mimics jest API and works with ESM.

(assuming here that you were suggesting folks consuming a lodash only ESM v5 switch to bun for testing)

Why use the stick when you can use the carrot? This may be the path people end up taking, but it won't happen overnight.

I believe many projects will not opt into changing part of their test infrastructure, and will instead either transpile away the ESM or not take the upgrades at all, reducing the reach in the ecosystem of all the improvements that are planned.

The "carrot" here would be letting folks know that lodash is moving into the future, and they can come along by upgrading incrementally.

EDIT: I won't be angry if this is not the direction that is taken. My goal here is to start a conversation and put forth options ❤️

[jonkoops]

For example, if you have a nodejs backend project with test suits written with jest, then you cannot switch project to esm. Currently jest does not support ESM

It does support ESM, just in an experimental manner with some caveats around mocking.