Cannot directly import _Date

[JontyMC]

Describe the bug

After importing the _Date class like this:

import { _Date } from '@faker-js/faker/date';

When running, I get the following error:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './date' is not defined by "exports" in ******\node_modules\@faker-js\faker\package.json

Reproduction

import { _Date } from '@faker-js/faker/date';

Additional Info

I want to import _Date because I want to use it in a delegate for configuring a test data builder:

date?: (date: _Date) => Date;

[Shinigami92]

Yeah, we could export it, but we should then name it like FakerDate or something like this
Currently it is an internal not exported type

... But when we do that, we need to export all module classes as types 🤔
Maybe DateModule would be a better name?

[Shinigami92]

@JontyMC As a workaround, try type FakerDate = typeof faker.date for now

[JontyMC]

Thanks for workaround.

The type is in the public API, so it is really external. What would be the downside in exporting it?

[ST-DDT]

I want to import _Date because I want to use it in a delegate for configuring a test data builder:

date?: (date: _Date) => Date;

You should probably use the Faker instance there instead. Since you cannot create the _Date type independently.
Is there a specific reason, why you want to use the _Date instance instead of the Faker instance?

Another workaround: date?: (date: Faker['date']) => Date

[JontyMC]

Using the _Date instance creates a nicer API, as you would ony ever want to use that module in this case.

[ST-DDT]

I like both the FakerDate and DateModule names. Any preference?

But I'm unsure whether these names are really easier to use then Faker['date'] and how often they will be used.
I assume most of the time Faker will be used like this x: (faker: Faker) => X or maybe even like this: x: () => X (directly from import)

[JontyMC]

I don't see a downside to exporting the types (probably prefer FakerDate), it might stop someone raising the same issue. Workarounds are fine now I know them.

[Shinigami92]

FakerDate feels like a wrapper around Date (the real js thingy), and IMO this is wrong / gives a wrong assumption to the user.

_Date is currently just one if many faker "modules", we already call them modules when we talk about them.
And even in code we already write module

faker/src/definitions/definitions.ts

Line 69 in b34ef46

[module in keyof Definitions]?: Partial<Definitions[module]>;

So <Thing>Module would be a much better name. I would also not explicitly rename the _Date class, but all modules consistently.

@JontyMC #778 (comment)

The type is in the public API, so it is really external. What would be the downside in exporting it?

Could you explain what you mean by this?
As far as I know we have a bundling process and you cannot expect that the src code is the same as the bundled output in dist due to minification and other stuff.
It would be needed to explicitly exported in https://github.com/faker-js/faker/blob/main/src/index.ts and currently that is not the case. So even if you can get it somehow, it is not officially supported by us and can break in any version.
Were as faker['date'] is definitely safe to be used for now, or at least you get a TS error when the name changes somehow ^^

[JontyMC]

The faker.date API is externally facing and has a contract in terms of the functions and properties it provides. I assume these won't change without deprecation and version bump, so in that sense the "type" is officially supported. Given this contract has a type already, it may as well be exported (perhaps it would be better as a typescript type or interface).

Also, the typescript _Date class is exported in the dist folder and visual studio auto imports @faker-js/faker/date when I used it.

[Shinigami92]

Accessing @faker-js/faker/date is not officially supported (at least not by design). It is nowhere documented and not intended to be used like this.
If it would be official, it would be importable from @faker-js/faker

[ST-DDT]

Note: The import will probably stop working in v6.2 because we intend to move the modules from src/<module>.ts to src/modules/<module>.ts