TS4082: Default export of the module has or is using private name 'Ember.Helper'

[dfreeman]

When trying to generate declarations for an addon that exposes a helper with any of the 2.8 series of @types/ember releases, I see the following error:

TS4082: Default export of the module has or is using private name 'Ember.Helper'

To reproduce:

ember addon my-addon --yarn && cd my-addon
ember install ember-cli-typescript
ember generate helper foo
ember ts:precompile

[chriskrycho]

How is it imported? Looks public here and it's just a normal class here. 🤔

[dfreeman]

import { helper } from '@ember/component/helper';

export function fooHelper(params/*, hash*/) {
  return params;
}

export default helper(fooHelper);

[dfreeman]

There's been a bunch of motion in the past couple weeks to make the declaration emitter more helpful in these kinds of scenarios, but it looks like for names in other modules, things are still open: https://github.com/Microsoft/TypeScript/issues/9944.

In the meantime, the workaround here is to change that import to import Helper, { helper } from '@ember/component/helper';, though that won't play nicely with the noUnusedLocals lint.

[chriskrycho]

Oh, 🤦‍♂️ – I finally understand the privacy problem here. (For other readers who may have been confused: it's because in the specific context of the module @ember/component/helper, the class Ember.Helper itself isn't public – it's public elsewhere, and another type which is equivalent to it is also public, but that type is private in the module.

Ugh.

[dfreeman]

🎉 Looks like this will be fixed in TS 2.9 https://github.com/Microsoft/TypeScript/pull/24071

[dfreeman]

This may or may not actually be fixed by more recent TS releases, but at some point we solved this particular problem by declaring the return type of helper in @types/ember to just be any.

The overall problem still exists in both 2.9 and most 3.0 beta I checked (3.0.0-dev.20180609), as evidenced by https://github.com/alexlafroscia/ember-cli-react/pull/8. We may want to consider documenting workarounds for this issue more generally or, if someone has the time, investigating what it would take to solve the problem upstream in tsc with import types.

[Roustalski]

Not sure if this is helpful in the context of Ember, but a google search brought me here when facing the same issue.

In react land, if I have something like this:

src/somefile.ts

import * as React from 'react';

export default class BlahBlah extends React.Component<Models.Props> {
...

I get the same error message: [ts] Default export of the module has or is using private name 'React.ComponentClass'. when importing BlahBlah from ./somefile, which means that somefile exposes its private reference to React. I solved this by re-exporting React from somefile:

import * as React from 'react';

export { React };

export default class Login extends React.Component<Models.Props> {
...

[n8agrin]

I'm having the same problem you describe @Roustalski. I wrote up an attempt at a repro here https://github.com/Microsoft/TypeScript/pull/24071#issuecomment-402849519

FWIW your solution does work for me, but I'd much rather not have to instruct engineers on the how and why they need to re-export variables and instead let the Typescript compiler do that for them.

[trusktr]

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

[chriskrycho]

Long since resolved by fixing type declarations in DefinitelyTyped and – more importantly – publishing types from Ember’s source.