You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR shamelessly copies their approach. I've noticed that the Command class-based testing approach takes significant time on Windows in CI - want to see if this approach is better.
While the unit tests take ~2 mins on Ubuntu to complete in CI, they take 5-6 mins on Windows (see e.g. this recent main CI run).
Roughly, the results of this approach (based on a sample size of one!) in CI:
|Environment|Branch|
Locally, on an M4 Macbook Pro, here are a variety of tasks and their results. I wanted to compare individual test files as well as all unit tests, as not all 'unit tests' run in pnpm test:unit are converted to using a mock SanityCommand class (a majority still use the OCLIF test utils that shell out and collect stdout/stderr):
Next steps: Take a moment to review the security alert above. Review
the linked package source code to understand the potential risk. Ensure the
package is not malicious before proceeding. If you're unsure how to proceed,
reach out to your security team or ask the Socket team for help at
support@socket.dev.
Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code.
Mark the package as acceptable risk. To ignore this alert only
in this pull request, reply with the comment
@SocketSecurity ignore npm/@sentry/node-core@10.60.0. You can
also ignore all packages with @SocketSecurity ignore-all.
To ignore an alert for all future pull requests, use Socket's Dashboard to
change the triage state of this alert.
Warn
Obfuscated code: npm es-abstract is 90.0% likely obfuscated
Next steps: Take a moment to review the security alert above. Review
the linked package source code to understand the potential risk. Ensure the
package is not malicious before proceeding. If you're unsure how to proceed,
reach out to your security team or ask the Socket team for help at
support@socket.dev.
Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code.
Mark the package as acceptable risk. To ignore this alert only
in this pull request, reply with the comment
@SocketSecurity ignore npm/es-abstract@1.24.2. You can
also ignore all packages with @SocketSecurity ignore-all.
To ignore an alert for all future pull requests, use Socket's Dashboard to
change the triage state of this alert.
Warn
Obfuscated code: npm eslint-plugin-unicorn is 90.0% likely obfuscated
Next steps: Take a moment to review the security alert above. Review
the linked package source code to understand the potential risk. Ensure the
package is not malicious before proceeding. If you're unsure how to proceed,
reach out to your security team or ask the Socket team for help at
support@socket.dev.
Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code.
Mark the package as acceptable risk. To ignore this alert only
in this pull request, reply with the comment
@SocketSecurity ignore npm/eslint-plugin-unicorn@56.0.1. You can
also ignore all packages with @SocketSecurity ignore-all.
To ignore an alert for all future pull requests, use Socket's Dashboard to
change the triage state of this alert.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Heroku's CLI explicitly exercises the Command classes instead of shelling out. See their code for details: https://github.com/heroku/heroku-cli-test-utils/blob/main/src/run-command.ts
This PR shamelessly copies their approach. I've noticed that the Command class-based testing approach takes significant time on Windows in CI - want to see if this approach is better.
While the unit tests take ~2 mins on Ubuntu to complete in CI, they take 5-6 mins on Windows (see e.g. this recent
mainCI run).Roughly, the results of this approach (based on a sample size of one!) in CI:
|Environment|Branch|
Locally, on an M4 Macbook Pro, here are a variety of tasks and their results. I wanted to compare individual test files as well as all unit tests, as not all 'unit tests' run in
pnpm test:unitare converted to using a mockSanityCommandclass (a majority still use the OCLIF test utils that shell out and collect stdout/stderr):pnpm test:unitpnpm test:unitmainpnpm test:unit packages/@sanity/cli/src/commands/datasets/__tests__/copy.test.tspnpm test:unit packages/@sanity/cli/src/commands/datasets/__tests__/copy.test.tsmain