Bump types package to 2.0.0

[ejizba]

Haven't had any issues with the beta version since releasing last week, so let's get the real version out!

Related to #398

[hossam-nasr]

Looks good! Let's get the real version out

[glasser]

Hi! We maintain a package (apollo-server-azure-functions) that defines code that our users can use in their Node Azure Functions. We import the types Context, HttpRequest, and AzureFunction from @azure/functions (and use them only as compile-time TS types). We are admittedly not huge Azure Functions experts — our project integrates with a variety of web frameworks and serverless environments.

Can you help me understand the impact of upgrading our dependency on @azure/functions from v1 to v2? I see that the README says that users should choose a version that matches their worker version. If we start publishing our package with a dependency on v2, will it break users who haven't upgraded their worker to v2 yet? Should we make our dependency be on "@azure/functions": "1.x || 2.x"?

[ejizba]

In terms of the types package, there were no breaking changes between v1 and v2. Since "@azure/functions" is strictly for TypeScript types, I would actually recommend you make it a devDependency in your project, which means the version you choose wouldn't affect your users at all. This would also prevent the package from being included as a "production" dependency when deployed to Azure.

[glasser]

Part of our API returns a function that uses types from this package in its signature. And, because of this, the published `.d.ts` file includes import type { Context, HttpRequest } from '@azure/functions'; My understanding is that that means it should be a non-dev dependency?

[ejizba]

Yeah I couldn't find any clear answer/recommendation for handling that. IMO, however, it's more important to prioritize the production-scenario, meaning we don't want to include any dev-like dependencies (TypeScript stuff definitely fit in this category) in our production app.

Here are a few arguments for including "@azure/functions" as a non-dev dependency and why I still do not think it's worth it:

• Users leveraging your package will automatically get the "@azure/functions" package when doing npm install, meaning the TypeScript build will never fail because it's missing.
  • All TypeScript projects get the "@azure/functions" package by default and even if it's missing, the error is pretty clear/fixable.
• You can enforce the version of "@azure/functions" that you support.
  • I actually don't think this is true at all - if the version you specify is different than the version specified directly in the user's package.json, they will just get 2 installs of "@azure/functions" in the "node_modules" folder like this ("npmtypesref" is the name of my test npm package - aka it's analogous to your package):
    

Lastly, my recommendation is based on patterns I see for other packages. For example, I couldn't find any package depending explicitly on "@types/node" even though I'm sure plenty of packages references that in the exports for their types.