Gentype: suppress lints from generated files

[cometkim]

It's been a long time since early 2019, when TSLint was deprecated and no longer updated, also it introduced users to migrate to ESLint. Today, the default linter for TypeScript users is ESLint + typescript-eslint plugin. So replaces outdated comments emitting from the gentype.

[cristianoc]

Great.

What's the way to test that the generated files make eslint happy?
Currently make test-gentype does tsc -p tsconfig.json.

[cometkim]

@cristianoc Well... we can't handle all the rules in a user's configuration in advance. for example, import/first is from a third-party plugin, it would always throw an error if the user doesn't have that plugin.

Wouldn't it be right to /* eslint-disable */ on top of generated files? Like most codegens do.

[cometkim]

We can disable both TSLint and ESLint (and even others, Biome?) on generate files and mark it as non-breaking changes.

[cristianoc]

We can disable both TSLint and ESLint (and even others, Biome?) on generate files and mark it as non-breaking changes.

One issue is that inconsistencies were caught with that check while now we would be losing all checks on the generated code during development when changes to gentype are done.

The other question is if that would affect in any way the errors reported on user code that uses those files. Do we know?

[cometkim]

I believe that verifying snapshots is not the linter's role. And most of the inconsistencies happened same as before but were ignored by the eslint config.

The other question is if that would affect in any way the errors reported on user code that uses those files.

There is no reason for it to be included in lint checking, not type checking. This is simply because users are not interested in the code style of generated one.

For ESLint users at least, potentially meaningless error was reported for import/first (because it is a plugin), users had to manually add these files to the ignore path to disable it anyway

[cometkim]

I configured ReScript outputs as a ignored path for every my JS-Res mixed projects. Important messages come from tsc, not linter.

[cristianoc]

Looks great.
Ready to go?

Quick question. I've intentionally broken one file manually by mispelling type Propsx = { and noticed that both npm run tsc and npm run lint give an error. So linters are not totally disabled?

[cometkim]

Quick question. I've intentionally broken one file manually by mispelling type Propsx = { and noticed that both npm run tsc and npm run lint give an error. So linters are not totally disabled?

Hmm, let me check today. But both tsc and eslint do not have a spell checking capability afaik.

[cristianoc]

Quick question. I've intentionally broken one file manually by mispelling type Propsx = { and noticed that both npm run tsc and npm run lint give an error. So linters are not totally disabled?

Hmm, let me check today. But both tsc and eslint do not have a spell checking capability afaik.

Sorry for my bad description. I have renamed it to create an inconsistency:

type Propsx = {
  readonly person: { readonly name: string; readonly age: number };
  readonly children: React.ReactNode;
  readonly renderMe: React.ComponentType<{
    randomString: string;
    readonly poly: string;
  }>;
};

export const make: React.FC<Props> = (x: Props) => {
...

And noticed that the inconsistency is caught by both checks.

[cometkim]

Ah yes, this change should only affect gentype outputs. You modified src/hookExample.tsx file right? It seems hand-written code, not generated by gentype. So the linter still can report errors like unused-vars on a user's file.

[cristianoc]

Ah yes, this change should only affect gentype outputs. You modified src/hookExample.tsx file right? It seems hand-written code, not generated by gentype. So the linter still can report errors like unused-vars on a user's file.

Good catch. On a generated file, tsc complains and lint does not, as expected.

OK ready to merge?

[cometkim]

Yep