Open Oliver-Habersetzer opened 4 years ago
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;
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.
Nope, still the same error. it doesn't even recognize the .default()
part.
@soullivaneuh: could you provide more of your configuration / environment?
I have same error on 3.2.0
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);
im using
import Holidays, * as HolidayDefinition from 'date-holidays';
const germanCountryHolidays = new (HolidayDefinition as any)('de') as Holidays;
console.log(germanCountryHolidays.getHolidays(2021))
I'm also seeing this issue with fresh create-react-app starting in version 3.
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.
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.
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?
Following up on @winterec comment...I have to agree with him. Is there going to be a better Typescript support for this library?
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");
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.
Maybe related: the published types for date-holidays@3.21.4
are apparently incorrect in a few different ways, as checked by the "Are The Types Wrong?" tool by @andrewbranch:
(cc @commenthol)
Import resolved to an ESM type declaration file, but a CommonJS JavaScript file.
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.
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.
Import failed to resolve to type declarations or JavaScript files.
❌ No types
Import resolved to JavaScript files, but no type declarations were found.
Also some 2 errors and 2 warnings on date-holidays@3.21.4
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)
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: https://github.com/commenthol/date-holidays/issues/168#issuecomment-871043120
I tried several configurations when trying to use typescript with this library:
Initial setup
tsconfig.json
:My usage
results in
node
,ts-node
andtsnd
:this is what I got after replacing the
import * as Holidays ...
withimport Holidays ...
:...with
Ranker.ts:14:28
being the lineconst 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