Cannot find name 'DedicatedGatewayRequestOptions'

[raskyer]

• Package Name: @azure/cosmos
• Package Version: 3.16.0
• Operating system: Windows
• [v] nodejs
  • version: 16.15.0
• [v] typescript
  • version: 4.0.0
• [v] Functions
  • version: 3.0.0

Describe the bug
I am trying to use @azure/cosmos inside an Azure Function written in typescript.
When I try to npm run build, the build fails with : node_modules/@azure/cosmos/dist/types/latest/cosmos.d.ts:1365:78 - error TS2304: Cannot find name 'DedicatedGatewayRequestOptions'. at the stage of tsc.

To Reproduce
Steps to reproduce the behavior:

1. Create an azure function in typescript
2. NPM Install @azure/cosmos 3.16.0
3. Try to run locally the function

Expected behavior
Be able to run the function without tsc bug.

Additional context
I try to run the function locally, using Visual Studio Code, but I guess it will happen on terminal or in remote too.

[raskyer]

In cosmos.d.ts

My package.json :

{
  "name": "...",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "prestart": "npm run build",
    "start": "func start",
    "test": "echo \"No tests yet...\""
  },
  "dependencies": {
    "@azure/cosmos": "^3.16.0"
  },
  "devDependencies": {
    "@azure/functions": "^3.0.0",
    "@types/node": "^12.0.0",
    "typescript": "^4.0.0"
  }
}

[xirzec]

@jay-most To resolve this I think you need to configure dtsRollup.betaTrimmedFilePath in your api-extractor.json file and have the typings resolve accordingly. Perhaps since you're not splitting up beta from public surface, you can just move over the value from publicTrimmedFilePath?

More info here:
https://api-extractor.com/pages/setup/configure_rollup/

[raskyer]

@xirzec Is there a workaround ? Downgrading the version or an action I can do on my side ? And if no workaround exists, do you have an idea of how long it will take to have a fixed release ?

I don't want to urge you, of course! But it prevents my team and I from developing our project for the french elections on Azure. If no workaround is found we will have to migrate to another cloud service.

[sajeetharan]

@raskyer Thanks for reporting this. We are investigating on this and we will update here! @jay-most any comments on @xirzec's suggestion ?

[jay-most]

Let me take a look. @raskyer

[witemple-msft]

@raskyer As a quick workaround until we can get a fix released, you can enable the skipLibCheck option in your tsconfig file. This option will cause the typescript compiler to skip checking dependencies' .d.ts files for completeness. Your code will still be checked against the cosmos.d.ts types, but the cosmos.d.ts file itself will not be checked (effectively, it'll be like the missing interface is declared empty).

Another option, if you want to keep lib checking enabled, is to declare the missing type in your project (such as in the index or entry-point file):

declare module "@azure/cosmos" {
  interface DedicatedGatewayRequestOptions {}
}

This will create an ambient definition for the interface in your project that will safely merge with the real definition once a fix is released (at which point you can just remove it).

@joheredi @xirzec for FYI. Not sure I agree with using betaTrimmedFilePath for a stable library. We should do that if we are going to release a 3.16.0-beta, but in this case the interface cannot be marked beta since it is a dependency of a stable interface (RequestOptions). The only logical case for a stable interface to depend on a beta interface is if the package is itself releasing a new minor beta. The reason we missed this is probably because we test with skipLibCheck disabled ourselves.

[xirzec]

@joheredi @xirzec for FYI. Not sure I agree with using betaTrimmedFilePath for a stable library. We should do that if we are going to release a 3.16.0-beta, but in this case the interface cannot be marked beta since it is a dependency of a stable interface (RequestOptions). The only logical case for a stable interface to depend on a beta interface is if the package is itself releasing a new minor beta. The reason we missed this is probably because we test with skipLibCheck disabled ourselves.

Yeah, I agree this one is a bit odd due to the fact a stable interface depends on it. I think this will be a good case study as we figure out the guidelines for beta APIs.

[xirzec]

@raskyer We have published the fix in 3.16.1 to npm, please let me know if you experience any further issues with the TS compiler when using this new version. 😄