modernize codebase

[ignatiusmb]

Hey, thanks for the project! I saw there's some request for help with providing types at #339 but also a lot of things missing in the repo itself, I see there's a lot of things we can possibly improve here, one of them is of course improvements in DX and build tools.

Just a heads up, this PR looks like it contains lots of files with huge changes, I'll try my best to make them manageable in each of the commits, please let me know if you'd like me to separate them in multiple PRs instead, thanks again!

---

This PR is mainly an attempt to close some of the TS stuff like #243 and #342, I'll try and explain through each of the changes in the order they're commited

• commited lockfile; as described in https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json, lockfiles are intended to be commited into the source, since we don't have a lockfile yet, I thought this would also be a perfect time to use pnpm as it's a better disk space efficient alternative to npm
• typescript + prettier; developing while having TS type-check our code would be a massive improvement since it will catch errors that won't be visible otherwise, it also closes the gap between not needing to manually sync the types after each changes since it will be tightly integrated with the source itself. last but not least, formatted and checked with prettier as it's considered a standard these days, we'll also use this to check/lint using GitHub workflows later on
• use class syntax; this is mostly an attempt to use the class declarator as it better encapsulates the code and logic into each place nicely without needing to hack into .prototype-s everywhere, still a WIP

Planned TODOs

• fix red squiggles and type-annotate everything
• use modern tooling and bundler
• add workflows for linting
• ...

Marking this as a draft for now, @ts-thomas does this seem okay for me to continue on?

[dr-charnog]

@ignatiusmb you are doing a valuable contribution, thanks for that and I am looking forward to this PR being merged.

Just as an opinion...

I think that migration to PNPM is unnecessary, as same as adding a new "mauss" dependency. Such types of libraries should depend on as few dependencies as possible.

[emersonbottero]

My 2 cents.. 🙂

• pnpm improves the development experience (saves a lot of disc space)
• for the tooling and bundler I would use vite
• add basic tests with vitest
• improve documentation with vitepress + my search plugin build with it 😎
• and I missed the interface of Index options 😅
• use exports in package.json like in vitepress package

The library is great!

[emersonbottero]

[ts-thomas]

@ignatiusmb thanks a lot for the big PR, I will check this very soon 👍

[davidhq]

• pnpm improves the development experience (saves a lot of disc space)

Have you tested this ? I actually have and it never saved any disk space.

pnpm works much faster than npm but it also breaks things a lot of times...

My 2c are that this particular change to pnpm is not advisable.

I usually use it to quickly test things and projects, when it stops working, I switch to npm... also for already mature codebase I go to npm once I don't have to reinstall modules all the time.

But space... no, I measured, it doesn't save one kilobyte but would be great if it did.

[nickreese]

I too would skip pnpm for a mature project but thank you for the efforts. Excited to see if it gets @ts-thomas's thumbs up or if I need to fork this branch.

[lucas-labs]

But space... no, I measured, it doesn't save one kilobyte but would be great if it did.

Yes it does, it uses hard links and junctions (on Windows).
If you have 10 projects using the same dependency they all point to the same "global store".

https://pnpm.io/faq (first faq)

I've been using pnpm for a long time now in multiple projects, some big some small, never had a single problem that I wouldn't have had with npm or yarn. In fact, flat node_modules gives you access to dependencies that are not in your package.json, which can be problematic, pnpm helped me find this type of issues many times.

[davidhq]

But space... no, I measured, it doesn't save one kilobyte but would be great if it did.

Yes it does, it uses hard links and junctions (on Windows). If you have 10 projects using the same dependency they all point to the same "global store".

Ok yes, in this case it's true... if module is installed in multiple projects, it is shared...
but inside one particular project, looking isolated, space is not saved... I just measured node_modules dir size inside a few projects and compared pnpm and npm and it was the same.

https://pnpm.io/faq (first faq)

I've been using pnpm for a long time now in multiple projects, some big some small, never had a single problem that I wouldn't have had with npm or yarn. In fact, flat node_modules gives you access to dependencies that are not in your package.json, which can be problematic, pnpm helped me find this type of issues many times.

That's great to hear. My experience was different. I guess it depends on luck. When this happened (and it wasn't some esoteric stuff) reinstalling with npm solved the issue... Last time I think it was with some Prisma ORM demo projects.

[benmccann]

These generally seem like good changes to me. I wonder if it might be easier to review if split up into separate PRs. The main question I would have is the new dependency on mauss

[benmccann]

why is this file so much smaller now? Is it just because of formatting? It's hard to tell what changed

[nosovk]

it seems that mauss used only to bring tsconfig and prettier config. Probably those files could be easily moved into the project without external dependency.

[ts-thomas]

There is a lot of wrong intendation which results in changed lines. The project is using 4 spaces per identation scope. So I need to manually compare changes and apply them to the new version. The whole type definition is now covered by myself, but I will take your definition and merge them.

Typescript isn't an option, as long as the Closure Compiler produces more optimized Javascript. Please show me how TS can produce better code and I will change to it.

NPM is a standard, I don't see any advantage of changing it, the codebase (without dev-dependencies) are just too small.