Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect typing of resolve type CalendarResponse in async.fromURL #210

Open
jamie--stewart opened this issue Aug 15, 2022 · 4 comments
Open

Comments

@jamie--stewart
Copy link

👋 Hello,

We use this library for downloading ICS files from user-supplied URLs.

In real-world usage we are seeing a number of responses that do not match the typing of CalendarResponse (Record<string, CalendarComponent>).

An example is:

{
  version: '2.0',
  calscale: 'GREGORIAN',
  prodid: 'SANITISED room calendar',
  '20220813T082405Z - 25326@ord5': {
    type: 'VEVENT',
    params: [],
    uid: '20220813T082405Z - 25326@ord5',
    start: 2022-08-12T23:00:00.000Z,
    datetype: 'date-time',
    end: 2024-04-03T23:00:00.000Z,
    dtstamp: 2022-08-13T08:24:05.000Z { tz: 'Etc/UTC' },
    summary: 'RoomId: SANITISED - Room not available'
  }

You can see above a number of string values ahead of the VEVENT object.

The typing for CalendarResponse would appear to be more accurately Record<string, CalendarComponent | string>.

I'd be happy to look at raising a PR for this, if you agree that it is an issue?

@Apollon77
Copy link
Contributor

Or would it also be an option to declate the type as partial?

@jamie--stewart
Copy link
Author

Hi @Apollon77, I'm not 100% sure what you mean there. I'm saying that the value of the object's keys are sometimes string, sometimes CalendarComponent, not that they may be undefined?

@Apollon77
Copy link
Contributor

ahh kk

@Apollon77
Copy link
Contributor

I think @jens-maus is happy about a PR :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants