Type annotations for default export

TypeScript Version: 2.1.1

Code

import * as webpack from 'webpack';
export default: webpack.Configuration {
};

Expected behavior:
No error

Actual behavior:

[ts] Expression expected. error at default:

I couldn't find an issue for this but it's very likely it's a duplicate

Please 👍 on this issue if you want to see this feature in TypeScript and avoid adding "me too" comments. Thank you!

Would not this be sufficient?

const config: webpack.Configuration  = { 

}
export default config;

Yes, that's what I do know but I wish I didn't have to.

related to #3792. we have tried to keep the module export as simple as possible on the syntax side.

I think it's a little more related to to the following scenario regarding function declarations.

if I want to write a decorator that is verified against the PropertyDecorator type in lib.d.ts, I can't write it easily. I have to use a function expression.

export let Encrypt: PropertyDecorator = function (obj, propName) {
};

which is case of friction whenever I want to actually implement a decorator without making a mistake.

I am trying to use a default export in the following way

readdirSync(join(__dirname, "../controllers/box"))

  .filter(f => f !== "*.spec.ts")
  .forEach(controllerFile => {
    const controllerBaseName = basename(controllerFile, ".js")
    import(`../controllers/box/${controllerBaseName}`).then((controller)=>{
      appRouter.use(
        `/box/${controllerBaseName}`, controller.default(boxServiceAccountClient))
    }).catch(error=>{
      console.log(error)
    })
  }); //end forEach

I get an error:

TypeError: controller.default is not a function at fs_1.readdirSync.filter.forEach.Promise.resolve.then.then.controller (/Users/bbendavi/Documents/cdt-box/dist/server/config/routes.js:16:71) at <anonymous> at process._tickCallback (internal/process/next_tick.js:160:7) at Function.Module.runMain (module.js:703:11) at startup (bootstrap_node.js:193:16) at bootstrap_node.js:617:3

I asked this on SO with a full file examples:
https://stackoverflow.com/questions/48696327/how-to-define-a-module-default-export-type-in-typescript

Would much appreciate your help!

import * as webpack from 'webpack'

export default {
...
} as webpack.Configuration

@IgorGee That's the proper way of doing it IMHO

The problem with

export default ... as X

is that it's a cast, so it purposely loses type safety.

Tom Crockett (@pelotom)

Tom Crockett (@pelotom) As a general matter of fact, you're completely right, I'd avoid putting this in my codebase. For the scope of this thread where this is about webpack configuration, I think we're just fine

Jean-Baptiste Louazel (@jlouazel)

Jean-Baptiste Louazel (@jlouazel) leaving aside whether type safety is any less important in a webpack config... the issue is not specific to webpack, it's about annotating the type of the default export in general.

@IgorGee That's forbidden in @typescript-eslint/recommended.

I think that satisfies this request to my satisfaction, in that case.

Siddhaarth Verma (@sid)

Siddhaarth Verma (@sid) Vishnoi It works on function declarations too.

export default (function (req, res)  {
   return 1;
}) satisfies RequestHandler;

Playground Link

Ashley Claymore (@acutmore)

Just want to point out that using both as and satisfies might actually be the best solution here until we get actual syntax. satisfies checks that the value conforms to the type, as forces the type instead of allowing TS infer its own type

type Union = { v: 1 | 2 }
export default { v: 1 } satisfies Union as Union; // Checked against Union and Union is preserved as the type of the export.

Playground Link

Thanks to Ashley Claymore (@acutmore) for suggesting this use of satisfies T as T

Another workaround is to pass the export value to an identity function to check its value:

function verify<T>(t: T): T { return t }

export default verify<React.FC<IProps>>(function(props) {
  // ...
})

I'm not sure if there's a canonical identity function that'd avoid introducing your own.

For now, we continue to export default exportDefault; with something like const exportDefault: webpack.Configuration = {}; .

as induces type coercion
satisfies is a type assertion. It does not type the variable (even though it will validate it)

satisfies is a type assertion. It does not type the variable

Oh, too bad. I thought an earlier commenter said that it did type it. We haven't upgraded to the version of typescript with this yet, but this was one thing I was looking forward to.

You can also declare a typed variable and assign it in your export.

type Union = { v: 1 | 2 };

let d: Union;

export default d = {
  v: 1,
};

McCall Alexander (@mccallofthewild)

McCall Alexander (@mccallofthewild) Then it could be reassigned.

Mon (@mon-jai)

Mon (@mon-jai) No. 😁 That's not how assignment works.

let a;
let b = a = 1;
a = 2;
console.log(b == a);
// `false`

Shouldn't the following code work?

// d.js
let d: number;
export default d = 1:

// Other files
import d from "d.js";
d = 2;

satisfies T as T doesn't reduce boilerplate in all circumstances. eg using a type from a value doesn't work at all:

export default {some:'value'} satisfies SomeType<typeof SomeValue> as SomeType<typeof SomeValue>

and even if it did work, I'm repeating my type declaration twice.

Doing export default: SomeType<typeof SomeValue> {some:'value'} would be great for reducing boilerplate

from 2017 -> 2024... Still this issue is open. wow.

Mr. Binary Sniper (@MrBns)

Mr. Binary Sniper (@MrBns) Some time ago, Ryan Cavanaugh (@RyanCavanaugh) proposed an initiative to deal with persistent issues - #54923. ~~You might want to ask Ryan Cavanaugh (@RyanCavanaugh) to add this issue to the list for upcoming discussions.~~

Oleksandr Tarasiuk (@a-tarasyuk)

Oleksandr Tarasiuk (@a-tarasyuk) unfortunately, in the announcement of that initiative they include:

Requesting Feature Updates

For the foreseeable future, we'll be working off the "most-upvoted" suggestion list. Please don't post comments in issues or iteration plans asking for feature updates. Once the top suggestions have been cleared out, we might change this policy, possibly by having a survey or something.

I don't see anything indicating that has changed, but it's possible I missed it

With that being said, if this issue is considered for a Feature Update, whoever is considering it, please note that #56235 (comment) (export default ... satisfies as T) is a possible solution to this issue and many others

For maximum type safety:

function define<X = never>(x: NoInfer<X>): X {
  return x
}

export default define<string>('hello')

If you don't hate micro package:
@txe/define-x

Navigation Menu

Repository navigation

Type annotations for default export #13626

28 remaining items

Requesting Feature Updates

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Type annotations for default export #13626

Description

Activity

mhegazy commented on Jan 23, 2017

mohsen1 commented on Jan 23, 2017

mhegazy commented on Jan 23, 2017

DanielRosenwasser commented on Jan 24, 2017

barakbd commented on Feb 20, 2018

Igor-Gold commented on Mar 10, 2019

jlouazel commented on Apr 1, 2019

pelotom commented on Apr 1, 2019

jlouazel commented on Apr 1, 2019

pelotom commented on Apr 1, 2019

oli-laban commented on Jun 10, 2019

28 remaining items

dobesv commented on Jan 31, 2023

mon-jai commented on Jan 31, 2023

dragomirtitian commented on Mar 16, 2023

rampion commented on Jun 30, 2023

ekcom commented on Jul 25, 2023

dobesv commented on Jul 25, 2023

mccallofthewild commented on Oct 4, 2023

mon-jai commented on Oct 4, 2023

mccallofthewild commented on Oct 4, 2023

mon-jai commented on Oct 5, 2023

MacroMan commented on Dec 18, 2023

MrBns commented on Sep 2, 2024

a-tarasyuk commented on Sep 2, 2024

saltman424 commented on Sep 2, 2024

Requesting Feature Updates

chbybnwr commented on Feb 25, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions