Allow running dtslint without header checks

[Maxim-Mazurok]

Hello DT-tools team! I've been using the same approach as DT for lining all auto-generated auto-updated Google Client API types, that are indirectly published to DT by reference.
My goal is to have the same testing and quality standards as DT.

Now original dtslint doesn't work with TS5.0:

The 'unnecessary-bind' rule threw an error in '/home/runner/work/google-api-typings-generator/google-api-typings-generator/types/gapi.client.walletobjects-v1/tests.ts':
TypeError: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. Use 'identifierToKeywordKind(identifier)' instead.

So I'm following DT footsteps and migrating to @definitelytyped/dtslint: Maxim-Mazurok/google-api-typings-generator#974

I do understand that @definitelytyped/dtslint is probably very specific to DT internal tooling, but it would be great to have the ability to use it outside of DT for use-cases such as mine, where types aren't published directly to DT, but still are referenced there and would like to have the highest level of quality.

Most of the header checks are irrelevant or even bad for me. For example, I use special versioning system to be in sync with how Google versions their schema revisions, and it doesn't pass the checks: gapi.client.abusiveexperiencereport-v1's package.json has bad "version": 0.0.20231106 must end with ".9999". Also even more critical one - my packages have to be public as I publish them myself to the public registry as https://www.npmjs.com/package/@maxim_mazurok/gapi.client.sheets-v4 for example, and then they are referenced in https://www.npmjs.com/package/@types/gapi.client.sheets-v4 so that I can push auto-updates hourly without extra maintenance burden for DT maintainers. Yet, I'm getting error parsing headers...

gapi.client.abusiveexperiencereport-v1's package.json has bad "private": must be `"private": true`

For now, I had to add a patch to disable these checks: https://github.com/Maxim-Mazurok/google-api-typings-generator/blob/dtslint-migration/patches/@definitelytyped+dtslint+0.0.197.patch

But it might become a maintenance burden with future updates.

If there was an option or a flag to disable header checks - that would be awesome! I could probably do that similarly to what I've done in the patch, if the flag is passed - assume that package.json is an empty object. If this looks fine - I'm happy to make a PR.

I appreciate your consideration!

[jakebailey]

I do think that we need to come up with some guidance on what we do and don't think should be usable outside of DT. Just flipping that one config to an empty object is likely not going to do the right thing for everything (I'm surprised it doesn't crash later), and part of me thinks that it's going to be challenging to create a tool which doesn't depend on DT's structure and would work externally (without a patch for your particular case).

e.g., more of the lint checks have been rewritten (or will be rewritten) to stop relying on hardcoded paths and start using repo information that assumes a certain layout. But it's possible that those rules aren't applicable externally anyhow.

Theoretically this is a dupe of #775, though I'm not sure either issue fully captures the though that will have to go into a final plan.

Half related, but I had sworn that you were looking into not using DT at all anymore, instead using explicit types configuration; has something changed on that front or has it just not been a priority?

[Maxim-Mazurok]

I see.. Well, fair enough I guess, you make the tools for your purpose, and I can understand that other purposes are technically out of scope, but still would be nice I think..
I could explore an option of just getting your eslint config and doing linting myself.

Half related, but I had sworn that you were looking into not using DT at all anymore, instead using explicit types configuration; has something changed on that front or has it just not been a priority?

I don't really remember and it hasn't been a priority, but as far as I remember, I wanted to have @types namespace as this is what most developers would be looking for when in need of types, and also being default types roots config for TS. So I wouldn't want to change that for the consumer experience's sake.
And also this doesn't affect my linting needs, I still don't have to use DT's rules, but I choose to as I believe DT is the best source of linting rules for types.

Anyway, thanks for considering, feel free to close if not planned, cheers!

[jakebailey]

I see.. Well, fair enough I guess, you make the tools for your purpose, and I can understand that other purposes are technically out of scope, but still would be nice I think..
I could explore an option of just getting your eslint config and doing linting myself

To be clear my reply was not a no, I just wanted to write down my thoughts (and felt bad for not replying earlier).