feat: Shell API autocomplete type definitions MONGOSH-2031 MONGOSH-2032 MONGOSH-2173 #2434
Conversation
```sh cd packages/shell-api && \ npm run compile && \ npx api-extractor run ; \ npx ts-node bin/api-postprocess.ts ; \ cat lib/api-processed.d.ts ```
| @@ -294,7 +294,7 @@ describe('completer.completer', function () { | |||
|
|
|||
| it('returns all suggestions', async function () { | |||
| const i = 'db.'; | |||
| const attr = shellSignatures.Database.attributes as any; | |||
| const attr = shellSignatures.DatabaseImpl.attributes as any; | |||
There was a problem hiding this comment.
The fact that Database and Collection are now types and the classes got replaced with DatabaseImpl and CollectionImpl is having a lot of knock-on effects and kinda ended up being responsible for most of this diff.
I'm wondering if we should keep them as Database and Collection but then rather name the new types to be something like DatabaseWithSchema and CollectionWithSchema. Then maybe the change will be smaller?
Not sure which way around would work out better ergonomically overall.
| "types": "./lib/index.d.ts" | ||
| }, | ||
| "./api": { | ||
| "types": "./lib/api-processed.d.ts" |
There was a problem hiding this comment.
I'm not sure what would be the best way to export/publish this and then reference it from the outside.
I think import type ShellApi from '@monogdb-js/shell-api/api' works with this and I tried it manually from a file, but I'll see shortly when I plug this into mongodb-ts-autocomplete
| InterruptFlag, | ||
| }; | ||
|
|
||
| // TODO: do we really want all these? |
There was a problem hiding this comment.
Just a reminder for myself to remove this TODO comment before merging and after bringing it up with the team.
There was a problem hiding this comment.
I started looking into all the ae-forgotten-export errors, but in the end I made those warnings for now. It is kinda a lot and as you start adding them one by one their dependencies end up becoming errors..
I don't think we need this as the shell api, though - that warning/error is probably more useful for something that's used as a library.
| it('calls help function', async function () { | ||
| expect((await toShellResult(apiClass.help())).type).to.equal('Help'); | ||
| expect((await toShellResult(apiClass.help)).type).to.equal('Help'); | ||
| }); | ||
| }); | ||
| describe('signatures', function () { | ||
| it('type', function () { | ||
| expect(signatures.Collection.type).to.equal('Collection'); | ||
| // TODO: do we want the signatures to be CollectionImpl or Collection? |
There was a problem hiding this comment.
Just a reminder for myself to remove this TODO comment before merging and after bringing it up with the team.
| @@ -0,0 +1,102 @@ | |||
| // TODO: does it make sense to have all this stuff? Don't we just need enough for the top-level API, ie. the globals? | |||
There was a problem hiding this comment.
Just a reminder for myself to remove this TODO comment before merging and after bringing it up with the team.
There was a problem hiding this comment.
This would all become one big ShellAPI import in monogdb-ts-autocomplete where we set up the db, sh, rs, sp globals so we can reference things like ShellAPI.Database. But I suppose we can hide it by importing it as a type.
| 'Running "' + joinedCommand + '" in ' + args[2]?.cwd ?? process.cwd() | ||
| // eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
| // @ts-ignore TS2869 Right operand of ?? is unreachable because the left operand is never nullish. | ||
| `Running "${joinedCommand}" in ${args[2]?.cwd ?? process.cwd()}` |
There was a problem hiding this comment.
drive-by. For some reason I got a compile error on this line in CI.
| "@mongosh/service-provider-core", | ||
| "@mongosh/types", | ||
| "mongodb", | ||
| "bson" |
There was a problem hiding this comment.
We have bson set up in mongodb-ts-autocomplete, so I might remove it from here.
lerouxb
changed the title
lerouxb
changed the title
| @@ -0,0 +1,44 @@ | |||
| declare global { | |||
There was a problem hiding this comment.
This file is basically a snippet that gets appended at the end of api-globals.d.ts after we api-extract that. See bin/api-postprocess.ts.
I first tried to write a babel plugin to walk the ShellAPI class's methods and the ShellBson interface's methods, but that turned out to be really complicated.
There is one benefit to having them all mapped here explicitly: We don't end up accidentally leaking everything on ShellAPI into the global scope whether we want to or not. And it is arguably handy seeing them all enumerated here.
The only other variables added as globals would be db, sh, sp and rs which all get specified dynamically by mongodb-ts-autocomplete so they reference the server/database/collection schema generics.
This is a continuation of Anna's work here.
Notes: