Remove lodash-es dependency

[es3n1n]

Hello,
I'm slowly starting to address techniq/layerchart#616. Figured that getting rid of lodash might be a good start.
Essentially, I reimplemented all the required functions that are used in the layerstack itself, plus memoize, which is used in layerchart. I tried to add more tests to the new pieces of code to ensure the same behavior compared to lodash, but please note that most of them were created using an LLM. I also tried to reference the originally linked just implementations where possible.

Here are some implementaiton notes/questions:

• For the isFunction implementation there are some additional pieces of code we might want to add to support safari 9, but given that it was released in 2015, perhaps we can just ignore that?

• For the isEqual implementation, do we want to support anything other than dates, maps, sets, arrays, objects?

closes #78

Also should this target the next branch instead? Kind of realized there's an active next branch only after i opened a pr, sorry

[changeset-bot]

🦋 Changeset detected

Latest commit: 68d26ed

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@layerstack/svelte-actions	Patch
@layerstack/svelte-stores	Patch
@layerstack/svelte-state	Patch
@layerstack/svelte-table	Patch
@layerstack/tailwind	Patch
@layerstack/utils	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@layerstack/svelte-actions

npm i https://pkg.pr.new/@layerstack/svelte-actions@93

@layerstack/svelte-state

npm i https://pkg.pr.new/@layerstack/svelte-state@93

@layerstack/svelte-stores

npm i https://pkg.pr.new/@layerstack/svelte-stores@93

@layerstack/svelte-table

npm i https://pkg.pr.new/@layerstack/svelte-table@93

@layerstack/tailwind

npm i https://pkg.pr.new/@layerstack/tailwind@93

@layerstack/utils

npm i https://pkg.pr.new/@layerstack/utils@93

commit: 68d26ed

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
layerstack	✅ Ready (View Log)	Visit Preview	68d26ed

[techniq]

Hey @es3n1n, thanks so much! 🫶. This will provide a great reduction in bundle size.

To answer your questions:

For the isFunction implementation there are some additional pieces of code we might want to add to support safari 9, but given that it was released in 2015, perhaps we can just ignore that?

While I try to target a broad range of browsers when possible, I typically don't stress over browsers more than 2-3 years old unless there is a strong use case to do so. Considering Safari 9 is almost 10 years old, I'm not overly concerned maintaining compatibility (and we've likely broken it elsewhere).

For the isEqual implementation, do we want to support anything other than dates, maps, sets, arrays, objects?

This sounds robust enough for me, unless we had any usage otherwise (off the stop of my head I can't think of anything else).

Also should this target the next branch instead? Kind of realized there's an active next branch only after i opened a pr, sorry

Sorry, but yes we'll need to target the next branch for layerstack, which LayerChart @next uses (and Svelte UX @next).

Regarding LayerChart specifically, a few points to note:

• We replaced lodash's memoize with the memoize package in @next a while back. I'm not against replacing it with something in-house, but will need to make sure we don't introduce any regressions. It's used in some hot paths for canvas style and string measurement caching, so will need to keep an eye on perf as well. I have some manual perf validation steps, but nothing automated yet.
• We've been working on a massive docs overhaul for LayerChart on the docs-v2 branch (PR) which is stacked off the next branch. See the PR preview here
  • Note: there be dragons as we're leveraging / kicking the tires of Svelte async with remote functions, and the project has been good to tease out some bugs / regressions (you'll find yourself needing to hit F5 on occasion).
• On top of this, I've been overhauling state management within the project (state-refactor branch / PR), which will simplify many APIs, consolidate simplified chart functionality within Chart, simplify testing, and enable more use cases.

With that said, when we go to update LayerChart with these changes, we'll want to do this on at least next, but it would be best to branch off doc-v2 or even better, state-refactor.

Sorry that we've kicked up a fair bit of dust during this process, but we're making great progress (I hope to finish / merge state-refactor into docs-v2 over the Christmas break 🤞. I've been buried under some work deliverables the past few weeks, but things are starting to calm down this week.

Thanks again for all the help!

[techniq]

oh, btw the reduced bundle sizes will be even more impactful as we now provide StackBlitz links for all 700+ examples, and are also working on a new integrated playground. It's a bit slow at the moment due to the package installs and lodash/deps was very much top of mind to improve this, so this is great timing :)

[es3n1n]

Alright, I've rebased to next and left only the stuff we're actually using.
I also removed memoize. I think it's completely fine to use the one from npm - it's pretty small anyway, and it's much easier than implementing our own and making sure there are no regressions :D

Once this PR is merged, I'll probably start looking at the layerchart. I'll make sure to base my changes on the state-refactor 👍

[techniq]

Looks good! Thanks for the comprehensive tests.

One last request, can you run pnpm changeset (patch) to update the CHANGELOG and trigger the CI workflows to deploy a npm release.

Thanks!

[es3n1n]

We should be good to go now!

[techniq]

@es3n1n all packages published.

• https://github.com/techniq/layerstack/releases
• https://www.npmjs.com/package/@layerstack/utils?activeTab=versions

Thanks again, and looking forward to the LayerChart improvements!