Exporting TypeScript types

Whilst migrating the main helmet package over to TypeScript, I discovered an issue to do with exporting types:

Property 'dnsPrefetchControl' of exported interface has or is using name 'DnsPrefetchControlOptions' from private module '"./node_modules/dns-prefetch-control/dist/index"'.

In this example, I believe the DnsPrefetchControlOptions type needs to be exported in the main module definition. However, because we are using CJS exports, we cannot simply prefix the type definition with export (as there can only be a single export). Instead, the suggested way is to use namespaces:

/* eslint-disable @typescript-eslint/no-namespace */
namespace dnsPrefetchControl {
  export interface DnsPrefetchControlOptions {
    /* ... */
  }
}

// eslint-disable-next-line no-redeclare
function dnsPrefetchControl (options: dnsPrefetchControl.DnsPrefetchControlOptions = {}) {
  /* ... */
}

In the interest of preserving CJS exports, does this seem like a reasonable way for now? In the future, we can make a breaking change to use ES modules everywhere which would make things a lot nicer, but this change would at least make it possible to migrate this module to TypeScript. 👍

[EvanHahn]

TypeScript types were added to Helmet in version 4, which you can install with npm install helmet@4. Closing this issue because I believe this is resolved, but feel free to comment or open a new issue.

[EvanHahn]

Ah, okay, I think that all makes sense to me now.

Given that…

1. helmet@4 is going to support all the way down to Node 8
2. Node 8 doesn’t support ES modules natively (without a flag, at least)
3. I want to prioritize native, no-transpilation setups over setups that require a transpiler (TypeScript or otherwise)

I think we should use export = like we do now. If that means we have to use deprecated TypeScript namespaces, that’s okay with me. It’s not ideal, but based on the givens above (which we could certainly debate), I think that’s the only option.

Does that sound right?