Linting

[mrsimpson]

What's in here

This PR adds linting to the fork. Since the current codebase contains a lot of linting issues, this takes the smalles possible step to ensure code-consistency.

Motivation

Linting surfaces code smells. Linting with the same rules ensures that PR diffs are kept small and readable.

How it's been done

As per the commits, I did the following

• Lint-fix what can be fixed easily
• ignore some uncritical rules
• fix other errors

Verdict

While checking the linting, there were quite some code-smells like inconsistent returns of function/methods. I tried to fix them so that they are syntactically fine. I couldn't always judge whether this is desirable wrt the intended architecture.

I manually tested the application (prompted, edited files and so on), lgtm. But it would be great if somebody threw another pair of eyes on it 👀

[coleam00]

Thank you for getting started on this @mrsimpson, I appreciate it a lot!

[wonderwhy-er]

hm, small merge caused conflict, at some point we need to sync and merge this

[mrsimpson]

@wonderwhy-er

This is what I meant when I wrote ;)

Also, the overall mechanism of loading new LLMs is very … simple and relies on a couple of files being added. Usually, I’d expect some registry-mechanism here to allow for modification free extensibility when e. g. adding new providers.

Small changes to the providers cause conflicts (even semantically compatible ones ).

I merged the main branch again, so here's another chance to get linting fixed ;)

[wonderwhy-er]

Running checks

Sadly as merge is possible without running checks we may still get unlinted things in

[wonderwhy-er]

CI/CD failed with typecheck

[mrsimpson]

Sadly as merge is possible without running checks we may still get unlinted things in

I added #378 to prevent this

[mrsimpson]

CI/CD failed with typecheck yes, saw this.

I introduced a type where things were not ... clear.
I'll update this PR and check the types again. Once I'm done with this, I'll notify you here, @wonderwhy-er .
I'd add the typecheck to #378 afterwards ;)

I'll have to take a break for some hours now though – other commitments :(

[mrsimpson]

@wonderwhy-er sort-of fixed the type checker: The reason why the type check on the previous commit failed was that it was ironically cleaner than the main branch.

In some files, Stackblitz hast put a @ts-nocheck in order to make the code look more ... mature on Youtube. When I linted it, //@ts-nocheck was converted into a block comment due to the subsequent line – and was not recognized by the tsc as excempted anymore.
And as there was no forced tsc (even build doesn't trigger it), I missed this 🙈

Now, in order to keep this PR as low-invasive as possible, I reverted those affected files in which I had started to introduce better types to the main branches state, including the ts-nocheck. This is actually worse, but we'll tackle this later.

All quality checks pass on my end now.

Kindly verify and merge before new conflicts appear.
You may also consider merging #378 in order to make things worse again soon.

[wonderwhy-er]

Merged

[coleam00]

Thanks @wonderwhy-er and @mrsimpson!