Skip to content
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

feat(launchpad): open in IDE modal and feature #18975

Merged
merged 22 commits into from
Nov 24, 2021

Conversation

lmiller1990
Copy link
Contributor

@lmiller1990 lmiller1990 commented Nov 18, 2021

Features

  • Configure preferred IDE from launchpad and app if one isn't configured
  • Open file in preferred IDE
  • Open project directory in preferred IDE
  • Open project directory in finder

Testing

See videos - they show the feature, where it is, how it works. Be good to get someone else to give it a test, too. I also added a bunch of e2e tests.

More Info

I changed up how reporter communicates w/ event manager and the back end when opening files. Reporter is now less smart - it just emits an event, and the runner will handle the request to open a file via GraphQL. This made the React -> Vue -> event manager interop much more simple and avoided a bunch of hacks, as well as made the types better, and allowed for better e2e tests.

Prevously, the front-end passed the preferred editor with the "open in file" request, which I don't think is ideal. We should only have one source of truth for the preferred editor, and that should be on the server, not in the front-end.

I left in the existing "open in file" functionality since removing or changing it breaks a lot of system tests.

Demos

Demo: set IDE and open from app

app-open-demo.mov

Demo: set IDE and open from launchpad

launchpad-open-demo.mov

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Nov 18, 2021

Thanks for taking the time to open a PR!

@cypress
Copy link

cypress bot commented Nov 18, 2021



Test summary

18698 1 204 0Flakiness 3


Run details

Project cypress
Status Failed
Commit 0a57c91
Started Nov 24, 2021 12:48 AM
Ended Nov 24, 2021 1:00 AM
Duration 12:05 💡
OS Linux Debian - 10.10
Browser Multiple

View run in Cypress Dashboard ➡️


Failures

cypress/integration/commands/net_stubbing_spec.ts Failed
1 network stubbing > intercepting request > should delay the same amount on every response

Flakiness

commands/net_stubbing_spec.ts Flakiness
1 network stubbing > waiting and aliasing > can timeout waiting on a single request using "alias.request"
2 network stubbing > waiting and aliasing > can timeout waiting on a single request using "alias.request"
cypress/proxy-logging-spec.ts Flakiness
1 ... > works with forceNetworkError

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@lmiller1990 lmiller1990 marked this pull request as ready for review November 19, 2021 07:39
@lmiller1990 lmiller1990 requested a review from a team as a code owner November 19, 2021 07:39
@lmiller1990 lmiller1990 requested review from jennifer-shehane, a team and tgriesser and removed request for a team and jennifer-shehane November 19, 2021 07:39
}
`

const query = useQuery({ query: SpecPageContainerDocument })

export type GqlWithCurrentProject = SpecPageContainerQuery & {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels hacky, @tgriesser can we sync on this? Also notified in slack

Copy link
Contributor

@elevatebart elevatebart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it was intended but when testing this feature, I found an issue.

If you set your editor in the settings page using the drop-down, wait a second and then refresh the page, the value is empty again.

It looks like GQL is not aware of the mutation and does not invalidate the needed query's cache.

@tgriesser @estrada9166 maybe you can help with this cache issue?

If it is already investigated and solved somewhere else, I withdraw my comment. but it is annoying.

Comment on lines 75 to 81
import VSCode from '~icons/logos/visual-studio-code'
import Atom from '~icons/logos/atom-icon'
import Webstorm from '~icons/logos/webstorm'
import Vim from '~icons/logos/vim'
import Sublime from '~icons/logos/sublimetext-icon'
import Emacs from '~icons/logos/emacs'
import IconTerminal from '~icons/mdi/terminal'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are those icons not part of the env-editors.ts ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get it, because they are not available there.

Maybe we could use import meta to import a glob of logos and only reference logos by name on the server...
https://vitejs.dev/guide/features.html#glob-import

This is an architecture concern though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we at least add one icon corresponding to computer for the open in file system choice.

And use the terminal icon from cypress instead of MDI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done and done for icons, let's consider the Vite globbing, too, at some point...

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

love it

@lmiller1990
Copy link
Contributor Author

@elevatebart

I wonder if it was intended but when testing this feature, I found an issue.

I made a change in a commit and looks like I didn't test it - setting an editor on that page was completely not working as it should have been. Huge oversight on my end, extended the e2e test to make sure it does not regress: 4ec6bbf

elevatebart
elevatebart previously approved these changes Nov 22, 2021
Copy link
Contributor

@elevatebart elevatebart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for some icons not aligned it works

Comment on lines 75 to 81
import VSCode from '~icons/logos/visual-studio-code'
import Atom from '~icons/logos/atom-icon'
import Webstorm from '~icons/logos/webstorm'
import Vim from '~icons/logos/vim'
import Sublime from '~icons/logos/sublimetext-icon'
import Emacs from '~icons/logos/emacs'
import IconTerminal from '~icons/mdi/terminal'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

love it

@@ -65,6 +65,7 @@ export const e2eProjectDirs = [
'screen-size',
'shadow-dom-global-inclusion',
'spec-generation',
'spec-name-special-characters',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this file updated?
@tgriesser should we gitignore it?

ZachJW34
ZachJW34 previously approved these changes Nov 23, 2021
Copy link
Contributor

@ZachJW34 ZachJW34 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested, looks good. I'm curious about the comment you made about the hacky GraphQL types. Can we not just use the normal fragment types here? Might require some refactoring of the fragments though

Comment on lines +44 to +62
if (!binary || !absolute) {
this.ctx.debug('cannot open file without binary')

return
}

if (binary === 'computer') {
try {
this.ctx.electronApi.showItemInFolder(absolute)
} catch (err) {
this.ctx.debug('error opening file: %s', (err as Error).stack)
}

return
}

launchEditor(`${absolute}:${line}:${column}`, `"${binary}"`, (__: unknown, errMsg: string) => {
this.ctx.debug('error opening file: %s', errMsg)
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think this implementation should be done here or could it be done in another file?

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 guess, why? Where?

@lmiller1990
Copy link
Contributor Author

lmiller1990 commented Nov 24, 2021

@ZachJW34 I summed up about the types here: https://cypressio.slack.com/archives/C027U3ZEJ6Q/p1637307934004600 basically in GraphQL currentProject is nullable, but on this page it will never be null - I want some way to express that.

For now I reverted the hack and just added some null checks. Long term we will wait for the ! operator on fields to land in urql: urql-graphql/urql#2018

Then we can do

query Q {
  currentProject!
}

... represents that the client expects currentProject not to be null.

@lmiller1990 lmiller1990 merged commit 168600b into 10.0-release Nov 24, 2021
@lmiller1990 lmiller1990 deleted the lmiller1990/open-in-ide-UNIFY-593 branch November 24, 2021 01:00
tgriesser added a commit that referenced this pull request Nov 29, 2021
* 10.0-release:
  refactor: remove @packages/desktop-gui (#19127)
  feat: switch browser runner (#19048)
  fix: bump resource class for tests that require node_modules install (#19079)
  fix(unify): reporter styles (#19034)
  fix test
  feat(unify): add number of matches to specs search (#19076)
  feat(launchpad): open in IDE modal and feature (#18975)
  fix: 10.0 appveyor updateyaml (#19074)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants