Huuuuuuuuuge

It's also supported by other VCS providers like codeberg (.codeberg/... instead of .github/..., everything else works the same).

You can also run gh workflows locally with "act".

Agreed with the payloads bit.
Errors are rarely useful without payloads, and implementing payloads is basically just going back to the C way of doing it.

I'd be interested to learn too if you find out.

Modules have the same drawbacks as free functions – I have to know which function I want to call beforehand.

e.g: I want to get the `head` of a list, or a default value for empty lists. Do I import Data.List.Extra? Data.List? Relude? Prelude?

With dots, I'll see the right one in suggestions.

I've done it, don't really regret it.
`Types` was the easiest way out of not having cyclic dependencies.

Very Nice!

Here's an idea you might like: Map every Op to a "stack effect". e.g: `add` can have a stack effect of -1 (pops two, pushes one), and `get` can have 1 (pushes one, pops none).

The computing "maximum" stack size for a function is is nearly 0 overhead (just a global var in the generator)

Ha, Jam's parser is a single 7k LoC file as well.
Bun's parser is 25k LoC, IIRC. Though that one is a little unwieldy.

Taking a look this weekend.

> ping me if I forget

will do!

Not rude in the least.
It's not everyday I get constructive criticism like this, so I appreciate it.

Once again, thanks a lot for sharing your perspective. I'll take some time out this weekend to see what I can learn from elm-review/format, and if I find any unanswered questions, I'll try to get in touch with you.

Once I have a demo-able tool, I'd love to hear about your thoughts on it again ❤️

My primary focus is on just three tools for now: optimizer, linter, formatter.

My goal isn't to be an all encompassing JS solution, or replace ESBuild or NPM (I trust @rolldown.rs for that!) I try to focus on polish, and have the "tooling" layer be as transparent as can be.

convince many people to use it. And I'm perfectly fine if I build a polished, reliable tool that's useful to just me, and people who have similar needs.

I'd love to see anything you can share about this.

Re: Formatter

From what I've seen, people do care about prettier compatibility (Biome mentions that they have 97% prettier conformance, and that's honestly a great selling point).

However as you said, I too prefer config-less formatters.
I already know that this means Jam's formatter won't...

Re: TypeScript

I honestly don't believe I could juggle a day job and then implement something like stc right now even if I tried, seeing that even Donny has given up on it.

So yeah, no plans of working on it for now.

...and ship them as shared libraries. There is a lot of research to be done here, and I hope for tools like oxc to considered it and figured something out by the time I get there

... get the toolchain to a point where I can gauge demand for custom rules, and then figure out a plugin API (Zig shared lib plugins are already WIP, but I understand they're not as amenable for developers).

I want to see if it's possible to give users a seamless way to write plugins in zig...

Re: Custom Rules

I mention this in Jam's README, but the eventual goal is to build a JS plugin available using either Kiesel or QuickJS (not immediately though, but it's a part of the reason I'm helping Linus out with Kiesel dev).

Figuring out a nice Zig->JS API is challenging.
I hope to...

That said, I can't claim I've worked on very capable multi file analyzers before, So if you can talk about some tools (elm-review?) that might be doing this, I would love to hear about it. You're spot on about the usefulness of a tool that's limited to the file scope, and Jam won't be that.