Skip to content

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

Merged
merged 15 commits into from
Dec 12, 2022

Conversation

SimeonC
Copy link
Contributor

@SimeonC SimeonC commented Sep 8, 2022

Fixed the v1 to v2 script to preserve order and not drop any values.

@SimeonC SimeonC requested a review from pokey as a code owner September 8, 2022 12:20
Copy link
Member

@pokey pokey left a 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

@@ -22,5 +22,6 @@
"pojo",
"subword"
],
"files.eol": "\n"
"files.eol": "\n",
"typescript.tsdk": "node_modules/typescript/lib"
Copy link
Member

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

Copy link
Contributor Author

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!

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Suggested change
"typescript.tsdk": "node_modules/typescript/lib"
"typescript.enablePromptUseWorkspaceTsdk": true,
"typescript.tsdk": "node_modules/typescript/lib"

Copy link
Member

@pokey pokey Sep 12, 2022

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

Copy link
Member

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 😕

Comment on lines 1 to 11
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;
};
Copy link
Member

@pokey pokey Sep 8, 2022

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

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

Copy link
Member

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

SimeonC and others added 2 commits September 9, 2022 10:18
Didn’t upgrade the website as the typegen package requires ts 4.5
Copy link
Member

@auscompgeek auscompgeek left a 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!

@pokey
Copy link
Member

pokey commented Sep 18, 2022

I think we should split this PR into two:

  • one to fix the fixture upgrade scripts, and
  • one to upgrade typescript and refactor type hints in makeGraph.ts

I believe these two pieces are completely orthogonal, and the former is more imperative, while the latter is causing the problems. Make sense?

@SimeonC
Copy link
Contributor Author

SimeonC commented Sep 19, 2022

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.
Sorry I'm taking so long to get round to finishing this - don't mind if someone else who has more time than me picks this up and splits it into 2 PRs.

@pokey pokey added the help wanted Extra attention is needed label Sep 20, 2022
@pokey pokey mentioned this pull request Oct 20, 2022
@pokey
Copy link
Member

pokey commented Dec 9, 2022

ok @SimeonC I factored out the typescript stuff into #1166 and #1167, and made some tweaks. lmk if you have any objections

@SimeonC
Copy link
Contributor Author

SimeonC commented Dec 11, 2022

Thanks for updating and completing it, looks good to me!

@pokey pokey merged commit c9e06d7 into cursorless-dev:main Dec 12, 2022
pokey added a commit that referenced this pull request Mar 21, 2023
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants