-
-
Notifications
You must be signed in to change notification settings - Fork 84
Fix test fixture upgrade scripts #942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great thank you! Left a few minor comments
.vscode/settings.json
Outdated
@@ -22,5 +22,6 @@ | |||
"pojo", | |||
"subword" | |||
], | |||
"files.eol": "\n" | |||
"files.eol": "\n", | |||
"typescript.tsdk": "node_modules/typescript/lib" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is nice; let's upgrade Typescript in this PR as well though I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I upgraded TS as well, but I left the website at 4.5 as the typedocs only supports up to 4.5 and I didn't want to risk breaking the website!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm I think that will be a problem, because we run typedocs on all the code in cursorless to generate api docs. We should prob pin both to the same version
When we switch to nx we'll only have one set of versions for everything fwiw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can try upgrade it but I'm not familiar with docasaurus and it's typedocs so I'd need someone to double check that. It may end up being a much bigger upgrade - if it does need more than a simple dependency upgrade do we want to just do that here or make a different PR for upgrading the website deps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I upgraded TS in website, it seems working to me as far as I can tell. The types are getting output in the contributor docs but I'm not sure they're 100% correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably also make VSCode actually ask whether we want to use it too, otherwise nobody will actually switch to it.
"typescript.tsdk": "node_modules/typescript/lib" | |
"typescript.enablePromptUseWorkspaceTsdk": true, | |
"typescript.tsdk": "node_modules/typescript/lib" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@auscompgeek that sounds reasonable to me. Any objections @SimeonC ?
Re types in website; I just kicked off a deploy preview. I'll take a look at docs once it's out to see if they look sane
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh. Unfortunately this PR breaks the api docs. For example, in the docs for runCommand
, see how on production there are a bunch of links in the description, but these seem to have disappeared for some reason in the deploy preview 😕
src/definitions/utils.d.ts
Outdated
type GetOptional<T> = { | ||
[K in keyof T as Pick<T, K> extends Required<Pick<T, K>> ? never : K]: T[K]; | ||
}; | ||
|
||
type GetRequired<T> = { | ||
[K in keyof T as Pick<T, K> extends Required<Pick<T, K>> ? K : never]: T[K]; | ||
}; | ||
|
||
type UnionUndefined<T> = { | ||
[K in keyof T]: T[K] | undefined; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we want to expose these globally? From what I can tell, everything in this file gets exposed globally, but these are just helper functions for EnforceUndefined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I've never really bothered thinking about that. If that's an issue we could just change it to a manual import, or I could use a namespace for the utils - whichever you prefer.
With the namespace way Utils
would be globally available but it does clutter it less, we could put all the types in the Utils
namespace so the only "globally" available type is the Utils
variable.
declare namespace Utils {
type GetOptional ...
}
type EnforceUndefined = Utils.GetOptional...
// some other file
EnforcedUndefined<... // This is OK
GetOptional<... // would error
Utils.GetOptional<... // This is also OK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pokey What approach do you want me to take here? import { EnforceUndefined } from '...'
or the Utils namespace or just leave it as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh I'd be tempted to just require users to import EnforceUndefined
. With auto-import, that's not particularly onerous, and it makes the code a bit better self-documenting, as you can see in the imports where it's coming from. I'm not a huge fan of globally available symbols
src/scripts/transformRecordedTests/transformations/reorderFields.ts
Outdated
Show resolved
Hide resolved
Didn’t upgrade the website as the typegen package requires ts 4.5
…ds.ts Update key order Co-authored-by: Pokey Rule <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking pretty good to me too!
I think we should split this PR into two:
I believe these two pieces are completely orthogonal, and the former is more imperative, while the latter is causing the problems. Make sense? |
Sure we could do that. I haven't had the time to come back to look at whether the fix for the docs is just some missing new config or it needs a refactor. |
Co-authored-by: David Vo <[email protected]>
for more information, see https://pre-commit.ci
Thanks for updating and completing it, looks good to me! |
- closes #945 - closes #1044 - depends on #1322 - depends on #1327 ## Checklist - [x] Split into smaller PRs for ease of review - [x] Try DX tests again #1289 - [x] I have updated the [docs](https://github.com/cursorless-dev/cursorless/tree/main/docs) and [cheatsheet](https://github.com/cursorless-dev/cursorless/tree/main/cursorless-talon/src/cheatsheet) - [x] File issue for speeding up cheatsheet / making it not optional locally #1307 - [x] Set package manager in package.json https://nodejs.org/api/packages.html#packagemanager - [x] Re-add lint rule to prevent api types from importing anything - [x] Try local install - [x] Make sure cheatsheet works - [x] Make sure local extension build depends on building cheatsheet, or allows no cheatsheet - [x] Figure out why we're getting so many extra `internal` modules - [x] Update #931 to indicate we're now patching instead of swizzling - [x] Make sure lint rules are actually running in CI - [x] Check that we've addressed everything in #945 - [x] Incorporate changes from #1166 - [x] ~~Make sure this PR doesn't break doc links; see #942 (comment) There's no way to avoid these links getting broken if we upgrade typedoc; filed #1304 to track - [x] Revert #1284 - [x] I have added [tests](https://www.cursorless.org/docs/contributing/test-case-recorder/) - [x] I have not broken the cheatsheet - [x] Generate cursorless-vscode package.json automatically, and change the name we use to `@cursorless/cursorless-vscode` in the `package.json` checked into source control - [x] Be sure to update meta-updater to check for that instead of name `cursorless` (see fixme in its `index.ts`) ## Desiderata - From #1289 ### Correctly flagging errors - [x] `D1`: It is a compile error to import external packages that are not listed in `package.json` - [x] `D1.1`: `vscode` (for some reason this one behaves strangely) - [x] `D1.2`: Other packages - [x] `D2`: It is **not** a compile error to import from local packages that you depend on, using our preferred syntax (eg `@cursorless/foo`) - [x] `D3`: It is a compile error to import from local packages that you depend on, **not** using our preferred syntax (eg `../foo`) - [x] `D4`: It is a compile error to import from local packages that you do **not** depend on, either - [x] `D4.1`: using our non-preferred syntax (eg `../packages/foo`), or - [x] `D4.2`: using preferred syntax (eg `@cursorless/foo`) - [ ] `D5`: It is a compile error to import from anything other than `index.ts` in another module - [x] `D5.1`: **no** `@cursorless/foo/bar` - [x] `D5.2`: **no** `../foo/bar` - [x] `a`: Even if you depend on the module - [ ] `b`: Even if `bar` was re-exported in `foo/index.ts`. In that case it should be required to import `@cursorless/foo`. Untested, but probably works, and I ran out of steam 😅 - [x] `D6`: It is **not** a compile error to import external packages listed in `package.json` - [x] `D6.1`: `vscode` (for some reason this one behaves strangely) - [x] `D6.2`: Other packages ### Auto-import - [x] `D7`: Auto-import doesn't import from external packages not listed in `package.json` - [x] `D7.1`: `vscode` (for some reason this one behaves strangely) - [x] `D7.2`: Other packages - [x] `D8`: Auto-import imports from external packages listed in `package.json` - [x] `D8.1`: `vscode` (for some reason this one behaves strangely) - [x] `D8.2`: Other packages - [x] `D9`: Auto-import imports from local packages that you depend on, using our preferred syntax (eg `@cursorless/foo`) - [x] `D10`: Auto-import doesn't import from local packages that you don't depend on - [x] `D11`: Auto-import doesn't import from anything other than `index.ts` in another package (eg **no** `@cursorless/foo/bar`) - [x] `D11.1`: When you depend on the package - [x] `D11.2`: When you don't depend on the package ### Other DX - [x] `D12`: Find references across projects when no file from the referencing project is open - [x] `D13`: Rename across projects when no file from the referencing project is open - [x] `D14`: Jump to definition across projects - [ ] `D15`: It is easy to move a file from one package to another - [ ] `D16`: It is easy to create a new package - [ ] `D17`: Breakpoints work in Cursorless extension - [x] `D18`: Breakpoints work on Cursorless root website - [ ] `D19`: Breakpoints work on Cursorless docs website
Fixed the v1 to v2 script to preserve order and not drop any values.
Use normalisation code for updating fixtures in
const outputFixture = {
...fixture,
finalState: undefined,
decorations: undefined,
returnValue: undefined,
thrownError: { name: error.name },
};
await fsp.writeFile(file, serialize(outputFixture));
(filed Make fixture update code more consistent #1168 to follow up on this one)cursorless/src/test/suite/recorded.test.ts
Lines 130 to 138 in a4cee96