Typescript - Unable to export `Agent#lambda(...)` from client library due to absence of exported inline AwsLambda.Context.

[willbrazil]

Is your feature request related to a problem?
It's currently not possible to export a function form a typescript module when calling Agent#lambda because the interface AwsLambda#Context (defined in-line) is not exported in index.d.ts.

// Typescript file: some-app.ts
import apm = require('elastic-apm-node');
const apmInstance = apm.start();

export const run = apmInstance.lambda({} as any); // ERROR: Exported variable 'run' has or is using name 'AwsLambda.Context' from external module [...]

Describe the solution you'd like
AwsLambda could potentially be exported (?). Might be tricky since we currently export a default agent with export =.

Describe alternatives you've considered

1. Currently hacking by adding as any when exporting function from typescript file.

export const run = apmInstance.lambda({} as any) as any;

2. Directly exporting AwsLambda but blocked by default export of Agent

[watson]

I tried your example in VS Code and VS Code didn't show any errors for that code. When exactly are you getting it?

AwsLambda could potentially be exported (?). Might be tricky since we currently export a default agent with export =.

That's correct. When we added the index.d.ts file to the project, I tried to export all the different types, so that they could easily be used by TypeScript users, but it unfortunately didn't work with our way of exporting the main agent object.

Because we use export = agent, we're only allowed to export one thing. So I unfortunately had to remove it again.

If you know of any way we can do it without having to change the actual CommonJS export, please let me know :)

[willbrazil]

Thank you for such a quick response!

I get the error when I try to build (tsc --build) (intellisense also shows it).

Hmmm.. the fact you don't see the error made me check if it's because I'm using project references. That's indeed the issue. When using project references, we have to set composite and declaration compilerOptions to true.

I'm not sure how we'd address this without breaking backwards compatibility. Maybe something to keep in mind for when we do a major version upgrade :)

I'll see if I can come up with a less hacky solution over here and share back!

Thanks again!!

[albanv]

Hello, I'm encountering the same issue when I try to reexport Agent type with composite and declaration set to true in my tsconfig.json

import * as ElasticAPM from 'elastic-apm-node'

export type APM = typeof ElasticAPM

export function apmFactory (logger: Logger): APM {
  return ElasticAPM.start({
    ignoreUrls: ['/healthcheck'],
    ignoreUserAgents: [],
    logger,
  })
}

give me this compilation error:
index.ts:155:1 - error TS4082: Default export of the module has or is using private name 'Agent'.

[trusktr]

I've opened a request to fix issues like these in TypeScript by bringing declaration files to parity with language features. microsoft/TypeScript#35822

[jpike88]

This is pain in the butt, just ran into this... how is it that this is the only library out of hundreds I've seen that decides to break TS in such a weird way? Why not just fix your declaration files so paying customers can use types without hassle?

Exported variable 'apm' has or is using name 'Agent' from external module "/server/node_modules/elastic-apm-node/index" but cannot be named.

Just bump the major version, and change how the exports from your declaration file are done, it's worth it for such a critical issue as it renders your types useless outside an extremely simple use case.