Refactor i18n

[hgiesel]

Moving to ts_project has broken types for me on both VS Code and Neovim. This is an error message:

[ts 2607] [E] Element does not support attributes because type definitions
⇒ are missing for this Svelte Component or element cannot be used as such.

Underlying error:
JSX element class does not support attributes because it does not have a
⇒ '$prop_def' property.
─────────────────────────────────
[ts 2786] [E] Type definitions are missing for this Svelte Component. It
⇒ needs a class definition with at least the property '$prop_def' which
⇒ should contain a map of input property definitions.
Example:
class ComponentName { $prop_def: { propertyName: string; } }
If you are using Svelte 3.31+, use SvelteComponentTyped:
import type { SvelteComponentTyped } from "svelte";
class ComponentName extends SvelteComponentTyped<{propertyName: string;}> {}

Underlying error:
'ButtonGroup' cannot be used as a JSX component.
Its instance type 'ButtonGroup__SvelteComponent_' is not a valid JSX
⇒ element.
Property '$prop_def' is missing in type 'ButtonGroup__SvelteComponent_'
⇒ but required in type 'ElementClass'.

This PR fixes types for me. Obviously we should find a solution that fixes it for everybody :)

To fix the typings for svelte files, I had to move the rootDirs parameter inside the sub projects.
To fix the typings for tr and backend_proto I had to reinstate the symlinks you originally had added.

I also used the opportunity to rewrite i18n quite a bit. The old i18n_helpers is now the main i18n file. As the generated files are more difficult to handle, I thought it would make more sense, if the other subprojects depended on the one actual file, not on generated files. I also removed the singleton class and replaced it with ordinary functions.

[dae]

Strange, the typings are working fine for me. I have the latest "Svelte for VS Code" installed ( v105.4.1 ) and start it by opening the root Anki folder after building with 'bazel build //...' to ensure all the Svelte files have been generated. Might be worth trying a 'bazel clean' to clear out old files that are in the wrong location, and making sure you're opening the base folder rather than just a single subfolder? I don't mind the rootDir change if it doesn't break anything, but would like to understand what's wrong first.

The reason for the current i18n layout is because rexporting symbols breaks tree shaking:

dae@dip:Work/code/dtop% bazel build -c opt ts/graphs && du -hs bazel-bin/ts/graphs/graphs.js
304K	bazel-bin/ts/graphs/graphs.js
dae@dip:Work/code/dtop% gh pr checkout 1405
dae@dip:Work/code/dtop% bazel build -c opt ts/graphs && du -hs bazel-bin/ts/graphs/graphs.js
408K	bazel-bin/ts/graphs/graphs.js

I agree the current layout is a bit awkward, and no objections from me on a change if you can preserve the tree shaking aspect.

[hgiesel]

Here the author of esbuild himself says it:

Tree shaking is supported with import * as x but not when x is then re-exported and re-imported.

I've done several bazel clean and git clean but to no avail, I can't get typing for tr. In return tree-shaking works again. I still refactored i18n quite a lot. tr is now outside of the i18n directory.

I also changed tsconfig's lib and module to es2020.
es2018, es2019, and es2020 all seem to have enough support.

[dae]

Refactor looks good; some comments below.

I'm still puzzled by this symlink requirement though. Will test on another machine and get back to you.

[dae]

Is this safe? The current minimum Qt target is 5.14, which is Chromium 77 - which does not support things like the nullish coalescing operator. Neither does iOS 12 / early iOS 13.

Does this change enable something important that we were missing, or was it just about making things neater?

[hgiesel]

In that case no, I'll revert it. I only needed to add support for .fromEntries.
Is there some reference list of platforms Anki aims to support. I basically went through the lists on icanuse and looked out for:

• support for Chromium 83
• support for iOS 14/15
  in which case we could go with es2020.

[dae]

Currently it's Chromium 77/iOS 12

• iOS 12 support will likely be dropped soon, but I try to support a few versions back, so I'd like to retain 13 support unless there's a compelling reason for dropping it early
• The current Windows and Mac builds use Qt 5.14 due to bugs in 5.15 (5.15 is only used when running from Bazel). Ideally we would drop 5.x support once the 6.2 branch is polished, but in past Qt updates, newer versions have broken things for some users. We'll know more once 6.2 has been polished a bit and has a packaged build available, but I wouldn't be surprised if we end up needing to bring back alternate versions based on 5.x for users that have trouble with the 6.2 build.

[dae]

(it might be worth setting up eslint to warn us when we use something outside those versions - feel free to look into that if you're interested :-)

[dae]

#982 tracks the 5.15 issues

[dae]

Ok:

• installed VS code on other machine

• installed svelte add-on

• checked out latest main branch from this repo

• opened it in VS Code

• went to CongratsPage.svelte. Was prompted to install TS tools; did so and restarted. Was told extension modified, restarted VS code again.

• I can see the "../lib/i18n" line underlined in red because the sources haven't been built yet.

• I go to lib/proto.ts and see ./backend_proto is also underlined red.

• I go to editor/index.ts and see that the i18n and components imports are highlighted red

• I go to a terminal and run bazel build ... in the checkout folder

• I restart vs code

• I see that the lib/i18n and backend_proto references are now working, but I'm getting errors in DeckOptionsPage about dynamic svelte component.

• I dug around to find out why my other machine wasn't showing the DeckOptionsPage errors, and it turns out I had a ~/node_modules folder that was affecting things - when I renamed that and restarted VS Code, my main machine now shows the same error with SveltedTypedComponent. Is it possible your i18n/proto issues are due to a node_modules folder?

Any ideas about the DynamicSvelteComponent issues in DeckOptionsPage?

[dae]

I suspect this is caused by our node_modules being in ts/ instead of the root folder. With a symlink all files stay in ts, but when we reference ../../bazel-bin it presumably hunts further up the tree, and results in it not being able to find libraries like 'svelte', breaking the definitions. Will look into moving the location tomorrow and see if it helps

[hgiesel]

I think you might be right. According to this StackOverflow answer:

When you set multiple rootDirs, tsc will find the parent directory that is common to all of them and treat that as the rootDir. This is why you're getting the outDir structure that you're getting.

So this means that our inferred rootDir is the repo directory, not ts/

[hgiesel]

At this point, everything in this PR everything except removing this line is just refactoring i18n into a directory.
Removing this line is what fixes autocompletion for Svelte components for me.

[dae]

Unfortunately that didn't work for me - I tried the latest code in this PR, and the generated i18n files can't be found by vscode on my machine.

Moving node_modules to the root folder and setting rootDir to .. seems to solve things - could you give #1408 a try? If that works, we can just drop the rootDirs change from this PR and it should be good to merge in.

[dae]

Want to squash and rebase this over main so we get a nice clean commit? :-)

[hgiesel]

Sounds good :)

[dae]

Sorry, that wasn't clear. I'd meant to suggest you do that (so we can test it over main the main branch before merging in - if I squashed it with the git interface it would presumably show up as authored by me instead). But I didn't want to hold this up and we've tested it already, so I just used GitHub's 'squash and merge' this time

[hgiesel]

I did get you, I was just about to push the squashed commit :) I'll also try to be more clear next time.

[dae]

All good :-)