chore: test that autocomplete works without the fallback, re-order the tests #559
Conversation
| @@ -65,13 +65,14 @@ function getVirtualLanguageService( | |||
| return (versions[fileName] ?? 1).toString(); | |||
| }, | |||
| getScriptSnapshot: (fileName) => { | |||
| fileName = relativeNodePath(fileName); | |||
| if (fileName in codeHolder) { | |||
| const relativeFileName = relativeNodePath(fileName); | |||
There was a problem hiding this comment.
This was actually a bug - I was passing the relative filename to the fallback resolver and that needs the original absolute filename so it can actually load it from disk.
| fallbackServiceHost, | ||
| }); | ||
| }); | ||
|
|
||
| afterEach(function () { | ||
| it('autocompletes', async function () { |
There was a problem hiding this comment.
The best way to fully test/prove this automatically (ie. that it can recreate the list) is do comment out deps in extract-types.ts to make it just an empty structure, run extract-types so none of the @types/node and lib files are in there, then run this test. It then finds the entire list.
I tried modifying extract-types to calculate the list automatically by running autocomplete, but it becomes a bit code-surgery with things passed down just for testing and a chicken and egg problem of extract-types using autocomplete which imports the extracted types which aren't generated yet... I tried to fix it with dynamic import, but then TS doesn't want to import the code from the script and it just becomes a rabbit hole.
I think this test that lists what's missing even if you start over with an empty list and the rest of the tests fail because they don't use the fallback is probably good enough.
There was a problem hiding this comment.
(I have now added a version of this as a comment next to the test.)
Just a follow-up to make sure that we test this properly.