add definitions of ajv

[plantain-00]

case 1. Add a new type definition.

• checked compilation succeeds with --target es6 and --noImplicitAny options.
• has correct naming convention
• has a test file with the suffix of -tests.ts or -tests.tsx.

[dt-bot]

ajv/ajv.d.ts

Checklist

• is correct naming convention?
  • https://www.npmjs.com/package/ajv - https://github.com/epoberezkin/ajv
• has a test file? (ajv/ajv-tests.ts or ajv/ajv-tests.tsx)
• pass the Travis CI test?

[blakeembrey]

@sandersn It doesn't look like this should have been merged, the type definitions were already contributed to the library in April - see ajv-validator/ajv#163. Is there any way you can make checking the library part of the PR process so these get rejected - it's not the first one I've come across now, since people misunderstand how it all works and there's a lot of issues like ajv-validator/ajv#225 (not everyone asks the library author first).

[sandersn]

At the very least we should check notNeededPackages.json and give an error if it's in there. @andy-ms does this already happen? Our bundling instructions tell authors to update notNeededPackages.json. (Although, note that file didn't exist in August.)

However, I don't think checking the library itself would be reliable enough since it depends on authors following the bundling instructions correctly. @andy-ms @RyanCavanaugh do you have thoughts on this?

On the human side, we could also:

1. Add "please check the library for existing typings" to the PR template check list.
2. Add the same request to the 'create a new package' instructions.

[blakeembrey]

Sounds great 👍 Though the manual list might be tricky for authors, I definitely don't add every library I publish to that list so I wouldn't expect others to. Seems like it's more useful for deprecation from DefinitelyTyped as you can't automate it for new packages (side note: would it help to have a job that updates your list with packages found on NPM with types fields automatically?).

Why wouldn't checking the library be reliable enough? If it can't be checked automatically, there's no way TypeScript would resolve it. At the very least, it seems like it'd be a simple automatic check which compliments the other points. Sure, there's still some cases where it won't work (e.g. the author uses typings.json), but it'd be a good start and Typings will (hopefully) be able to go away soon enough.

[plantain-00]

FYI: I started a PR to remove the types. #13028

[ghost]

notNeededPackages.json is just for libraries deprecated from @types, not for every library in existence.

We already do include The package does not provide its own types, and you can not add them. in the PR request template. There is similarly a warning on the first line of the "create a new package" instructions.

I was thinking of adding a check in types-publisher that warns for any packages that have added their own typings. We could do something similar in dt-bot too.

[blakeembrey]

Thanks @andy-ms! Having it automated would be a nice-to-have as I've seen not everyone is actually aware that modules can publish the .d.ts files and instead think that you must publish using NPM @types. It's resulted in some fun conversations such as pillarjs/router#48 - which, to note, might be some place that TypeScript can improve documentation.