lsndr/rrule-rust

Library for working with recurrence rules written in rust

rrule-rust's Issues

Implement nth weekday

Add tests for yearly frequency

Add method to RRuleSet to return applied exrrules

Add benchmarks

Add `semantic-release`

Branches

1. master for latest
2. next for next

Flow

1. Add reusable build & test workflow
2. Create Release workflow
3. Create Test workflow for PRs

Introduce `DtStart` object

This will represent DTSTART property, like RRule represents RRULE

class DtStart {
  datetime: DateTime;
  tzid: string;
}

Move code from `/lib/js` to `/lib`

Rename methods of RRuleSet

exdate to setExdate() and etc.

This will be a breaking change

Add jsdoc for methods

Add linter

Add method to RRuleSet to return applied rrules

Switch to typescript

Make enums non-const

Current behavior:

export const enum Frequency 

Desired behavior:

export enum Frequency 

This will require to create enum definition on TS side, since non-const enums are generated by napi-rs, so compatibility with TS is not guaranteed

Add information about known bugs/limitations of RRules crate to Readme.md

Implement generic errors mapper

Research possibility of usage of shared references in methods like `getRrules`

1. Research whether it's possible
2. Research whether it has any performance penalties

Add tests for weekly frequency

Return custom date object instead of UNIX timestamp

Possible design:

class RRuleDate {
  day: number;
  month: number;
  year: number;
  hour: number;
  minute: number;
  second: number:

 toDate(): Date {}

 toUTCDate(): Date {}
}

Make sure this type is compatible with luxon's Date.fromObject method

relates-to: #37

Add `filter` method to `RRuleSet`

Motivation

Iteration over RRuleSet is much slower than using all function. Method filter can cover some of the iterator use cases. But it firstly requires research how fast it is.

Possible contract

public filter<S extends DateTime>(predicate: (value: DateTime, index: number) => value is S, limit?: number): DateTime[]

Not possible to create an RRuleSet with timezone "local"

With the new API it's not possible to create an RRuleSet with the timezone set to "local", e.g. this fails:

new RRuleSet(DateTime.create(2024, 1, 1, 0, 0, 0, false), "local");
// => Error: 'local' is not a valid timezone

The reason is that timezones always get parsed with chrono_tz and then passed into rrule::Tz::Tz. Should local and utc be treated as a special string to instruct the RRuleSet constructor to use rrule::Tz::LOCAL or rrule::Tz::UTC respectively?

Add e2e tests

1. Write simple e2e tests using jest in e2e folder
2. Add workflow which will be called manually against specified package version

Create wrapper around rrule crate

1. Create wrapper around rrule crate with napi-independent api
2. Use this wrapper in js::* instead of rrule crate

Investigate possibility of usage date without time in `EXDATE` and `RDATE`

Improve performance of `RRuleSet` iterator

At the moment it is much slower than calling set.all(). Iteration over set should not significantly differ from using all method.

This task requires:

1. Research how to improve the performance
2. Provide PR with perf improvement

Finish documentation

Update eslint and utilize `--no-warn-ignored`

Add husky

Introduce `ExDate` and `RDate` objects

This will represent EXDATE and RDATE objects

class ExDate {
  datetime: DateTime;
  type: 'date' | 'date-time';
  tzid?: string;
}

Write tests for rust code

Repsect `TZID` when parsing datetime in `EXDATE` and `RDATE`

As for now it would be enough just to respect the timezone. In future we will need to provide api to set exdate and rdate with custom timezone (or we won't need because according to RFC, TZID in EXDATE/RDATE should be the same as in DTSTART).

Spec:

https://icalendar.org/iCalendar-RFC-5545/3-8-5-1-exception-date-times.html
https://icalendar.org/iCalendar-RFC-5545/3-8-5-2-recurrence-date-times.html

Requirements:

1. TZID should be used in calculations,
2. TZID should be included in RRuleSet.toString() result (?)

Return JS Date instances instead of UNIX timestamps

I would like to discuss whether it would be better for the API to return JS date instances instead of UNIX timestamps. While this may make it slightly slower, it would also make it more convenient to use. In reality, it shouldn't have a significant impact since, on the JS side, timestamps would likely be converted into JS dates regardless. What was the main reason for choosing UNIX timestamps in the first place?

Use npm instead of yarn

Add tests for monthly frequency

Make js rrule and rruleset immutable like in create

Add benchmark tests to CI

1. Research expected performance range on ubuntu-latest
2. Create a workflow, which run on the on each PR (only) on ubuntu-latest. Make it fail if its result is not in the expected range

Rename `__test__` to `tests`

Run release workflow in order

Write contribution guide

Add wasm support

Exclude internal commits from release notes

Commits like updating dev-deps, ci and e.t.c are not needed for users. They should be removed from release notes

Improve methods documentation

Add `dist` folder

1. Mode index.js and index.ts to dist folder
2. Exclude dist from git (Not sure it's possible)

webpack build error. Module not found: Can't resolve '@rrule-rust/lib-android-arm-eabi'

I don't know how to run this package, it reported errors in webpack packaging, and it also reported errors in my project running.

Separate prettier and linter

1. Separate linter
2. Exclude fist files from linter

Add method to RRule to change frequency