Short-term:
- none
Long-term:
- Get rid of
doTtemplates, because we can't even be sure that we're using data that we're passing into them (no linting) - Replace text writer with AST generation
- Just as top-level namespace is based on method ID, exactly the same logic applies for non-top-level namespaces. Meaning that in this setup:
we're getting
{ name: "some-name", resources: { firstResource: { methods: { firstMethod: { httpMethod: "GET", path: "some/path/1", id: "thirdNamespace.firstMethod", }, }, }, }, }
gapi.client.thirdNamespace.firstMethodandfirstResourcename is being ignored. Seeuses method ID instead of resource name/keytest which is failing This doesn't really cause any trouble right now, because IDs seem to match resources, but gapi uses IDs instead, so we probably should do that as well - Maybe fix integration test
all apis have idsto verify that all api defs have method ids (not same asapi.id) - Add
| discovery.RestDescriptiontoload()ingapi.client - Refactor
dt/appto useapp, maybe create an extendable class? - Reduce number of tests by mocking
- Add
flatPathtogapi.client.discovery, see https://clouddebugger.googleapis.com/$discovery/rest?version=v2 for example - Deal with reserved keywords in variables, for example
'debugger' is not allowed as a variable declaration name.for https://clouddebugger.googleapis.com/$discovery/rest?version=v2; previously was "solved" by skippingdebuggerwhich obviously doesn't do a great job - Support non-$ref response types? Like
getPublicKeysin https://identitytoolkit.googleapis.com/$discovery/rest?version=v1
Done:
- Add support for multiple Google Ads versions (probably try
bla.com/v7,bla.com/v8until we get 404), see #499;- v999 seems pretty empty, so let's just ignore it for now
- Finish
getExtraRestDescriptions
- Based on testing, the namespace isn't API name, but rather should be taken from the top level ID of methods, there also can be unlimited number of namespaces, like for Directory API there are both
gapi.client.admin.*andgapi.client.directory.*, because of ids.- Update generation to use method ids instead of API name for top-level
- Add
namespacesto readme template data
- Add
gapi.client.load(url)signature toindex.d.tsbecause it's recommended now, see https://github.com/google/google-api-javascript-client/blob/master/docs/reference.md#----gapiclientloadurlorobject--- Add
gapi.client.load(url)to readme - Update
tests.tswith.load(url)
- Add
- Package per version, like
@types/gapi.client.speech-v1p1beta1, for example. DT only supports\d+.\d+versions (see https://github.com/microsoft/DefinitelyTyped-tools/blob/bf52b08dedb8e7860337a5e1091f42d07d849ffb/packages/header-parser/src/index.ts#L169) At the same time Google API versions are all over the place, likedirectory_v1orv1p1beta1non-sense; seediscovery.spec.tsSo it seems like the only real option to publish all the versions is to have a separate package per version, like@types/gapi.client.speech-v1p1beta1, for example- Valid package names (seems like we can't use
:in package names), usevalidate-npm-package-nameto check because there can be any string in ID
- Valid package names (seems like we can't use
- Add support for multiple namespaces in the readme
- Add support for multiple namespaces in tests:
-
/** now we can use gapi.client.admin, gapi.client.directory, ... */ -
await gapi.client.admin.asps.delete({<<Property 'asps' does not exist on type 'typeof admin'
-
- Remove
| discovery.RestDescriptionfromload()ofgapi.client.* - Handle camelCase in api ID
- Fix dt/app
- Look into how we're going to deprecate current @types packages?
-
There's
notNeededPackages.jsonwhich is used when library now includes type definitions, so it results in messageThis is a stub types definition for X. X provides its own type definitions, so you don't need @types/X installed!which is not our case (see)Submitted Can't mark old package as deprecated when renaming to DT-tools
In the meantime, generate both old and new packages and mark old as deprecated.
Fixed a bunch of bugs,
git status | grep -v modified | grep -v "new file"looks fine now; Looked though some files in DT, ran tests, fixed more issues, should be fine now.Old packages were deprecated on npm in DefinitelyTyped/DefinitelyTyped#64771
-
Not going to do:
-
Maybe mark all methods in old packages as deprecated?
no need, whole packages were deprecated on npm already in DefinitelyTyped/DefinitelyTyped#64771
-
Only generate deprecated package for DT if it actually was there before and needs to be deprecated. Probably maintain a list
no need, deprecated packages were removed from DT in DefinitelyTyped/DefinitelyTyped#64771