Restructuring

[localusercamp]

Introduction

In this discussion i want to propose some ideas which as i think would be great to implement or discuss at least.

🔍 Performance issues

I have explored the source code recently and found that many thing is poorly written in case of performance which must be the first priority for library of this type. Great example of this is my PR about fork(). Implimentation was really bad at performance - .reduce() with destructuring arrays on each step.

I think we need to focus on rewriting existing functionality to make it usable in projects of any scale.

📂 Project structure

If you look at any serious library nowadays you probably will see a monorepo. It is very convinient for adding integration packages (for nuxt for example), docs, build tools and other utils. All things at the end of your fingertips.

When i saw repo for the first time my first impression was "Where is a tests folder?" =D.

I do not mean to say that we should use monorepo, i just want to say that in my opinion we need to think about making folder structure less confusing, expecially for newcome contributors.

🌈 RFC discussion topic

In many projects there is a RFC topic in which maintainers may propose a change to the library and gather some feedback.

It would be nice to have such instrument at least because we need to discuss thing like this post somewhere.

🩹 TypeScript return types

I think we need to be consistent about return types from functions. Now there are some functions which declares return types and some which not. TypeScript now infers types way better.

I think we need to always declare return types.

[aleclarson]

🔍 I think we need to focus on rewriting existing functionality to make it usable in projects of any scale.

On board with this notion as long as we also prioritize keeping the code readable. I think we can find a balance between performance and readability that everyone can be happy with.

Also on this note, I plan to add benchmarks to the test suite, using Vitest's bench API. But if you want to spearhead that effort, let me know! I can set up the Github action that reports benchmark results on PRs.

📂 When i saw repo for the first time my first impression was "Where is a tests folder?" =D.

I'd be fine with moving the tests to a root folder named test or spec, but we should keep the test files split by folder like the source code and docs are. Though I assume you agree.

🌈 In many projects there is a RFC topic in which maintainers may propose a change to the library and gather some feedback.

I've been using the feedback wanted label in Issues, but I suppose you're referring to using Discussions instead? If so, I think I agree that it'd be best to keep that stuff out of the Issues tab. 👍

🩹 I think we need to always declare return types.

Agreed and already done in #39 before you opened this :)

---

Thanks for opening this! Let me know if I missed any of your points 🏆

[aleclarson]

Okay, I've added an RFCs discussion category. Only maintainers can post to it. Others can post to the “Ideas” category.

[localusercamp]

I'd be fine with moving the tests to a root folder named test or spec, but we should keep the test files split by folder like the source code and docs are. Though I assume you agree.

Yeah that would be really nice.

[aleclarson]

Now that the tests are located in the ./tests/ folder, I think we can close this. Return types are required for exported functions. The RFC topic in Discussions was added. All that's left is the “Performance issues” part, and that's an ongoing effort.