* cards will still be mostly counted by ctype rather than queue
* if the user wants to include inactive cards buried and suspended will
be first filtered out, before the rest is counted by ctype
Rather than creating a separate rule for each package, we can just
create a generic one and reuse it. Also switch to keyword arguments
in the resulting macros, as it's easier to read.
This reverts commit 62600051ae, reversing
changes made to 88553acb0d.
- Standard graphs render incorrectly on latest version - the wrong number
of days are shown, and the grid lines look wrong. Any version after 0.8.3
seems to suffer from this problem.
- Pie graphs and stack graphs don't render - they are provided in separate
files, and plot.js in previous Anki versions has them included in the one
file. To maintain compatibility with add-ons, we'd need to create a single
file as before, instead of importing multiple files.
If the above issues are fixed I'd be happy to merge this in again, but
as the old graphs are on the way out, it's probably not worth the effort.
While 'SvelteComponent | null' seems to make it into the .tsx file
created by svelte2tsx, the subsequent tsc call seems to discard the
'| null' part when creating the .d.ts file. Hack around it with a cast
for now; this may be fixed if we move to ts_project in the future.
Allows some type errors to surface that were only being picked up
on Windows.
The root cause seems to be TypeScript picking up other .d.ts/.tsx
files in the same folder, which it can only do on Windows due to the
lack of sandboxing. On other platforms the other files can't be found,
and tsc changes the types into 'any'.
I experimented with modifying rules_svelte to build all .tsx files up
front and convert them to .d.ts in bulk, but ran into further issues
with conflicting types, as the typings in svelte2tsx seem to conflict
with Svelte's built-in types, and passing the dependencies in explicitly
causes them to be checked even though --skipLibCheck is passed in to
TypeScript.
Forcing sandboxing off is an ugly hack, and our best approach moving
forward may be to switch to ts_project for the Svelte generation -
it does appear that rules_nodejs favours it over ts_library anyway.
