[TypeScript] Phase 1

[dimitropoulos]

This ticket implements Phase 1 of the TypeScript conversion: #3266

The following PRs were "pre-reviews" of all of the work contained in this PR.

1. insomnia-xpath [TypeScript] insomnia-xpath dimitropoulos/insomnia#1
2. insomnia-url [TypeScript] insomnia-url dimitropoulos/insomnia#2
3. insomnia-prettify [TypeScript] insomnia-prettify dimitropoulos/insomnia#3
4. insomnia-importers [TypeScript] insomnia-importers dimitropoulos/insomnia#4
5. insomnia-cookies [TypeScript] insomnia-cookies dimitropoulos/insomnia#5
6. insomina-testing [TypeScript] insomnia-testing dimitropoulos/insomnia#6
7. insomnia-inso [TypeScript] insomnia-inso dimitropoulos/insomnia#7

[develohpanda]

Continuing from: dimitropoulos#7 (comment)

@reynolek @dimitropoulos these options come from https://github.com/unjs/consola/blob/4477e87a5153d31d22a2692565959d90599a6b61/src/reporters/fancy.js#L9-L16. The exported TS types appear to be incorrect here

[develohpanda]

I understand that linting in parallel might be faster but duplicating the lint script across all packages seems unnecessary/impractical when it comes to making a change and having to remember to update all lint scripts to keep them aligned.

I'm curious to understand your thought process behind making this change (if it's documented somewhere please point me to it). Is it so that each package can operate as a single/standalone entity?

[dimitropoulos]

I did this because it seemed like an error to be honest. it's a quite significant amount of time, and, afterall, the thing that ultimately runs this is the CI. It was changed while splitting the typechecking step out on the CI. More than happy to consider it out of scope and change it back if you'd like - lemme know.

[develohpanda]

Just thinking out loud after our verbal convo - how do other lerna projects handle this? A single eslint call at the root, or individual ones in each package?

If we have eslintignore in each package now, I think we should be able to remove it from the root altogether because IDEs should correctly load from the appropriate package (right?)

[dimitropoulos]

predominantly (from my looking-around during Phase 0): they just use yarn. EDIT: I misunderstood your question. They predominantly do something similar to what we had before, but it doesn't work for us right now from the root because different packages use different parsers and you can only have one parser per running eslint instance. One way or the other, this is fairly optimal for us because it can do it multi-threaded this way so there's no reason I can see to remove it.

re: .eslintignore at the root: we can drastically reduce it, yes, but it will likely need to stay since, after all, there are still files at the root (including the root eslint config itself) that eslint checks.

[develohpanda]

different packages use different parsers

I'm not sure I follow here 🤔 Wouldn't they all use @typescript-eslint/parser (at phase 2/3)?

One way or the other, this is fairly optimal for us because it can do it multi-threaded this way

For performance, yes I agree but that's at the cost of misdirection where .eslintrc.js is defined at the root, but .eslintignore is defined per package 😅

[dimitropoulos]

They will use the same parser by phase 2, but this is only a PR for phase 1.

Re: .eslintignore I'm not sure I see the downside of having individual .eslintignores wherever we need them. This keeps the packages more isolated from each other, which is ideal in a monorepo because it means that there's that much less you have to know about the other packages in order to examine a specific one.

[develohpanda]

Does this need to explicitly exclude bin? When I run build insomnia-importers, the bin/cli file gets updated

[dimitropoulos]

closing this PR, as #3370 contains this PR's code as well as (almost all of) Phase 2's work.