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.
Cast col.decks.selected() to int so the return type fits the annotation.
Thus, fix the comparison in col.decks.select() which was leading to
a superfluous db modification and in turn to a false indication of a
necessary sync right after another one in certain cases.
More than {{ is acceptable to start a tag, which means that `{{{Foo}}` won't be interpreted as "the content of `Foo`"
and should be rejected. For the sake of clarity and parsing, I suspect that those symbol should be rejected elsewhere
too.
Similary `{{Foo}}}` won't be interpreted as "Show the content of field `Foo}`" even if this field exists, so it's better
to reject `}`. It's clearly necessary to reject "}}" inside the field name, rejecting "}" seems easier to explain and
avoid future unexpected problem if the templates change.
The ":" are used to separate filters, and rejecting it in field name would ensure that there is no ambiguity.
