-
Notifications
You must be signed in to change notification settings - Fork 3.3k
chore: Migrate @packages/electron to TS #32417
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
- **ES Modules**: Alternative build for modern Node.js applications | ||
- **Output**: Compiled JavaScript in `dist/cjs/`, and a binary in `dist/Cypress`. | ||
|
||
## Building |
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.
@cacieprins Should this link to the BUILD.md? Or are those instructions no longer needed?
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.
Redundant - I'll remove build.md
# Install/build Electron binary for current platform | ||
./bin/cypress-electron --install |
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.
Where are these commands actually defined? Is it in the code somewhere to reference so these instructions don't go out of date?
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.
The cli()
fn in lib/electron.ts
is what parses out the commands. I'd really like to use something like commander
for our cli tools so it's more obvious, but it's pretty simple to trace from bin/cypress-electron
to lib/electron.ts#cli
. I'll add some docs.
@cacieprins Something about this PR is still failing |
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.
might be good to run the esm
compile with a --noEmit
just so we know there aren't regressions in this package as people add to it (though that's likely seldom).
Weird we have almost no tests. Might have some dead code as well because some of the functions from the main entry I can't find in the build.ts
or the server.
packages/electron/lib/electron.ts
Outdated
debugElectron('dest path %s', dest) | ||
|
||
try { | ||
await fs.stat(appPath) |
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.
previously this was access
. I am guessing we mostly just care for existence and this is fine and actually more appropriate
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.
no, access is the right thing - the debug had me mixed up (and that fs-extra's remove fails silently if the fd does not exist).
return _install.check() | ||
} | ||
|
||
export function install (...args: Parameters<typeof _install.packageAndExit>) { |
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.
dumb question, but where exactly is this used? I'm guessing it's a part of the CLI but I can't find the invocation. That would mean the process.exit()
cursor is complaining about is erroneous
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.
hence the help command, right?
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.
But that uses installIfNeeded
. I'm thinking this is dead code because it's not used in the build.ts
script.
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 doesn't need to be addressed in this PR. Mostly curious if this function is even used
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.
post-install runs yarn workspace @packages/electron build-binary
, which execs node ./bin/cypress-electron --install
, which runs this fn. This is also how our tests launch cypress when invoked via scripts/cypress.js
cypress
|
Project |
cypress
|
Branch Review |
migrate-electron-lib-ts
|
Run status |
|
Run duration | 19m 28s |
Commit |
|
Committer | Cacie Prins |
View all properties for this run ↗︎ |
Test results | |
---|---|
|
0
|
|
11
|
|
1102
|
|
0
|
|
26661
|
View all changes introduced in this branch ↗︎ |
UI Coverage
45.27%
|
|
---|---|
|
186
|
|
158
|
Accessibility
97.71%
|
|
---|---|
|
4 critical
8 serious
2 moderate
2 minor
|
|
110
|
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.
Changes look good
Co-authored-by: Bill Glesias <bglesias@gmail.com>
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Additional details
@packages/server
This is in preparation for setting up vitest, so we can properly test the conditional logic for enabling or disabling stderr filtering.
Steps to test
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?