Typescript errors

[Oliver-Habersetzer]

I tried several configurations when trying to use typescript with this library:

Initial setup

tsconfig.json:

{
  "compilerOptions": {
    "outDir": "dist",
    "allowSyntheticDefaultImports": true,
    "alwaysStrict": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "importHelpers": true,
    "lib": ["es2017", "esnext.asynciterable", "DOM"],
    "module": "commonjs",
    "moduleResolution": "node",
    "noEmitOnError": true,
    "noErrorTruncation": true,
    "noImplicitAny": false,
    "noImplicitReturns": true,
    "resolveJsonModule": true,
    "sourceMap": true,
    "strict": true,
    "target": "es6"
  },
  "exclude": ["node_modules", "release"]
}

My usage

import * as Holidays from 'date-holidays';
const holidays: Holidays = new Holidays();
// ...
const holiday = holidays.isHoliday(moment().toDate());

results in node, ts-node and tsnd:

(node:12220) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'fn' of undefined
    at Holidays._dateByRule (C:\Users\WurstBroHD\Desktop\keenoras-den-bot\node_modules\date-holidays-parser\lib\Holidays.js:427:23)
    at Holidays.isHoliday (C:\Users\WurstBroHD\Desktop\keenoras-den-bot\node_modules\date-holidays-parser\lib\Holidays.js:288:31)
... (omitting my own files)

this is what I got after replacing the import * as Holidays ... with import Holidays ...:

 uncaughtException: date_holidays_1.default is not a constructor
TypeError: date_holidays_1.default is not a constructor
at Object.<anonymous> (C:\Users\WurstBroHD\Desktop\keenoras-den-bot\src\modules\Ranker.ts:14:28)

...with Ranker.ts:14:28 being the line const holidays: Holidays = new Holidays();

Maybe this is related to #102 but they didn't give any useful info on the issue so I hope this helps!

If you don't know any fix to this, could you provide a known good tsconfig.json? Maybe my compiler settings are not the way you tested with TS.

---

[Edit 1]
I used all of the settings of your types/tsconfig.json but with the same result: TypeError: date_holidays_1.default is not a constructor

[soullivaneuh]

Working for me with this implementation:

// holidays.ts
import * as DateHolidays from 'date-holidays';

const holidays = new DateHolidays.default();

holidays.init('FR');

export default holidays;

[Oliver-Habersetzer]

Thanks, I'll try that one out. But it seems to be more of a workaround than a fix on the behalf of this library.
In my opinion ts is very important to use - especially in bigger projects.
Sometimes the types cause a bit of problems but in the end the compiler is able to keep you from making a lot of mistakes.

[Oliver-Habersetzer]

Nope, still the same error. it doesn't even recognize the .default() part.
@soullivaneuh: could you provide more of your configuration / environment?

[jp928]

I have same error on 3.2.0

[kenmasumitsu]

I got the same issue.
But, when I set "esModuleInterop: true" in tsconfig.json, it worked.

tsconfig.json

{
  "compilerOptions": {
    ...
    "esModuleInterop": true,
  },
  ...
}

sample

import Holidays from 'date-holidays';
const x = new Holidays();
console.log(x);

[capc0]

im using

import Holidays, * as HolidayDefinition from 'date-holidays';

const germanCountryHolidays = new (HolidayDefinition as any)('de') as Holidays;

console.log(germanCountryHolidays.getHolidays(2021))

[zack-ccm]

I'm also seeing this issue with fresh create-react-app starting in version 3.

[tonganh]

im using

import Holidays, * as HolidayDefinition from 'date-holidays';

const germanCountryHolidays = new (HolidayDefinition as any)('de') as Holidays;

console.log(germanCountryHolidays.getHolidays(2021))

This help me for that issue in Typescript.

[tiec7]

Working for me with this implementation:

// holidays.ts
import * as DateHolidays from 'date-holidays';

const holidays = new DateHolidays.default();

holidays.init('FR');

export default holidays;

I used this to make it work.

This issue is also open since more than a year, if you don't intend to fix it, would be nice at least to update documentation.

[winterec]

im using

import Holidays, * as HolidayDefinition from 'date-holidays';

const germanCountryHolidays = new (HolidayDefinition as any)('de') as Holidays;

console.log(germanCountryHolidays.getHolidays(2021))

This was the only form that worked for me, but it's the jankiest import I've ever used.

Is there a straightforward way that the typescript support could be improved?

[mehrad-rafigh]

Following up on @winterec comment...I have to agree with him. Is there going to be a better Typescript support for this library?

[jukkaleh-atoz]

3.16.14 works fine with typescript 4.8.4

import Holidays from "date-holidays";
const hd = new Holidays("FI");
hd.setHoliday("04-30", {
  name: { en: "Labour Day's Eve", fi: "Vappuaatto" },
  type: "observance",
});
hd.setHoliday("easter -1", {
  name: { en: "Holy Saturday", fi: "Lankalauantai" },
  type: "observance",
});
hd.setHoliday("easter -3", {
  name: { en: "Maundy Thursday", fi: "Kiirastorstai" },
  type: "observance",
  });
const annualHolidays2023 = holidays.getHolidays(2023, "fi");

[mehrad-rafigh]

I stopped using this library, since my usecase was very small and I was able to use the Gauss Algorithm for detecting Easter Sunday. Everything else can be built on top of Easter Sunday.

[karlhorky]

Maybe related: the published types for [email protected] are apparently incorrect in a few different ways, as checked by the "Are The Types Wrong?" tool by @andrewbranch:

(cc @commenthol)

Are The Types Wrong?

👺 Masquerading as ESM

Import resolved to an ESM type declaration file, but a CommonJS JavaScript file.

⚠️ ESM (dynamic import only)

A require call resolved to an ESM JavaScript file, which is an error in Node and some bundlers. CommonJS consumers will need to use a dynamic import.

🐛 Used fallback condition

Import resolved to types through a conditional package.json export, but only after failing to resolve through an earlier condition. This behavior is a TypeScript bug. It may misrepresent the runtime behavior of this import and should not be relied upon.

💀 Resolution failed

Import failed to resolve to type declarations or JavaScript files.

❌ No types

Import resolved to JavaScript files, but no type declarations were found.

[karlhorky]

Also some 2 errors and 2 warnings on [email protected] from Publint:

The types is not exported. Consider adding pkg.exports["."].import.types: "./types" to be compatible with TypeScript's "moduleResolution": "bundler" compiler option. (More info)

The types is not exported. Consider adding pkg.exports["."].require.types to be compatible with TypeScript's "moduleResolution": "bundler" compiler option. Note that you cannot use "./types" because it has a mismatching format. Instead, you can duplicate the file and use the .cts extension, e.g. pkg.exports["."].require.types: ".cts" (More info)

Should be the first in the object as required by TypeScript. (More info)

File does not exist (More info)

[johnnyPescarul]

Still having this same issue when running test on date-holidays version 3.23.8
After many tries, I realized that I skipped over @kenmasumitsu recommendation to set the esModuleInterop to true.
This was the only solution that worked for me.

see here:
#168 (comment)