feat: Introduce E2E tests for project-builder-cli#459
Conversation
- Fix error display for initialize serer errors as well
…m external updates
ENG-574 Introduce E2E tests for project creation and saving
We should make sure project-builder-web survives various scenarios involving saving/updating |
🦋 Changeset detectedLatest commit: 7393f29 The changes in this PR will be included in the next version bump. This PR includes changesets to release 8 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughThe changes introduce a new changeset documenting updates across various packages in the project-builder ecosystem. Multiple packages have been patched to support end-to-end testing, with notable modifications made to the CLI, web server, and test configurations. Updates include refactoring server startup logic to use a centralized service manager, revising TypeScript configurations, and enhancing error handling with user‐friendly errors. Additionally, testing workflows, ESLint configuration, and local storage project ID handling in the web client have been updated and expanded. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI
participant serveWebServer
participant BuilderServiceManager
participant WebServer
CLI->>serveWebServer: Invoke serveWebServer(directories, options)
serveWebServer->>BuilderServiceManager: Initialize with directories, CLI version, & plugins
BuilderServiceManager-->>serveWebServer: Return service manager instance
serveWebServer->>WebServer: Call startWebServer(serviceManager, options)
WebServer-->>serveWebServer: Return FastifyInstance
serveWebServer-->>CLI: Return { FastifyInstance, serviceManager }
sequenceDiagram
participant Browser
participant ProjectIDService
participant LocalStorage
participant URL
Browser->>ProjectIDService: Request getLocalStorageProjectId()
ProjectIDService->>LocalStorage: Attempt to retrieve projectId
alt projectId not found in LocalStorage
ProjectIDService->>URL: Check URL query parameters for projectId
URL-->>ProjectIDService: Return projectId (if available)
ProjectIDService->>LocalStorage: setLocalStorageProjectId(value)
end
ProjectIDService-->>Browser: Return projectId (or null)
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
Updated dependencies detected. Learn more about Socket for GitHub ↗︎
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (11)
packages/project-builder-cli/tsconfig.build.json (1)
1-8: Consider specifying arootDir.
If you have source files in a subdirectory, usingrootDirin addition tooutDiravoids potential issues with TypeScript output paths.packages/project-builder-cli/tsconfig.app.json (1)
1-11: Looks good!
Configuration is straightforward. Optionally consider stricter compiler checks ("strict": true) to catch potential issues early.packages/project-builder-server/src/api/projects.ts (1)
17-39: Maintain consistent error handling.Retrieving services via
ctx.serviceManager.getServices()is consistent with the new architecture. However, consider usingUserVisibleErrorfor invalid definitions to maintain uniform error reporting.packages/project-builder-cli/tests/settings.spec.ts (1)
19-38: Good coverage for external modifications.
This test properly ensures that changes to the underlying project definition are reflected in the UI. Consider expanding to test partial modifications or validation errors.packages/project-builder-cli/package.json (1)
33-34: Validate the new scripts.
Introducing"test:e2e": "pnpm playwright test"is a welcome addition for end-to-end testing. Note, however, that"tsc --build tsconfig.json"can produce compiled artifacts during type checks. If your workflow requires noEmit type-checking in CI, consider usingtsc --noEmitor a separate script.packages/project-builder-server/src/server/plugin.ts (1)
25-27: Verbose project logging.
Logging out all loaded projects is handy but could become excessive for large setups. Consider providing a more concise or debug-level log.packages/project-builder-cli/tests/fixtures/server-fixture.test-helper.ts (3)
22-61: Consider using OS-assigned ephemeral ports for better reliability.Currently, the function generates a random port in the range
10000-15000and then retries up to 100 times in case of conflicts. While this may work for test environments, it can still lead to port collisions under heavy parallel testing. To further reduce the risk of conflicts, you might consider letting the OS assign an ephemeral port automatically (typically by passingport: 0to your server starter, depending on your server framework’s capabilities).
28-29: Avoid magic range for ports, or document it clearly.You’re randomly starting at port
10000and scanning upward. This is fine for test environments, but either document the rationale (e.g., to avoid ephemeral port collisions) or consider using the system ephemeral ports by passingport: 0.
224-239: Initialization fixture could use additional validation.
addInitializedProjectautomatically marks the project asisInitialized: true. If your tests need to verify whether initialization logic was properly applied, consider adding a post-creation check or an assertion verifying that the project is truly in a ready state (e.g., required files are present).packages/project-builder-cli/src/server.ts (2)
41-45: Validate existence ofproject-builder-webin all environments.It's good that you throw an error if
projectBuilderWebDiris not found. A friendly user-facing error message or fallback behavior (if feasible) could improve the developer experience, but this is sufficient for most CLI usage.
69-92: Avoid swallowing errors in the CLI command.When using
.action(...), any error withinserveWebServerwill propagate, but re-check how you handle potential upstream errors. If user input leads to an unhandled rejection (e.g., invalid directories), you may want to refine CLI error messages before re-throwing to produce more specific feedback.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
⛔ Files ignored due to path filters (2)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yamltests/simple/pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (38)
.changeset/tired-places-pay.md(1 hunks).github/workflows/test-e2e.yml(1 hunks)package.json(1 hunks)packages/create-project/src/project-creator.ts(0 hunks)packages/project-builder-cli/.gitignore(1 hunks)packages/project-builder-cli/package.json(2 hunks)packages/project-builder-cli/playwright.config.ts(1 hunks)packages/project-builder-cli/src/index.ts(1 hunks)packages/project-builder-cli/src/server.ts(2 hunks)packages/project-builder-cli/src/services/logger.ts(1 hunks)packages/project-builder-cli/src/utils/version.ts(2 hunks)packages/project-builder-cli/tests/fixtures/server-fixture.test-helper.ts(1 hunks)packages/project-builder-cli/tests/initialize-project.spec.ts(1 hunks)packages/project-builder-cli/tests/settings.spec.ts(1 hunks)packages/project-builder-cli/tsconfig.app.json(1 hunks)packages/project-builder-cli/tsconfig.build.json(1 hunks)packages/project-builder-cli/tsconfig.e2e.json(1 hunks)packages/project-builder-cli/tsconfig.json(1 hunks)packages/project-builder-lib/src/migrations/index.ts(1 hunks)packages/project-builder-lib/src/schema/project-definition.ts(1 hunks)packages/project-builder-server/src/api/context.ts(1 hunks)packages/project-builder-server/src/api/projects.ts(1 hunks)packages/project-builder-server/src/api/trpc.ts(1 hunks)packages/project-builder-server/src/api/types.ts(1 hunks)packages/project-builder-server/src/plugins/plugin-discovery.ts(3 hunks)packages/project-builder-server/src/server/builder-service-manager.ts(1 hunks)packages/project-builder-server/src/server/index.ts(3 hunks)packages/project-builder-server/src/server/plugin.ts(6 hunks)packages/project-builder-server/src/server/server.ts(3 hunks)packages/project-builder-server/src/service/builder-service.ts(1 hunks)packages/project-builder-server/src/utils/errors.ts(1 hunks)packages/project-builder-web/src/app/ProjectDefinitionProvider/ProjectDefinitionProvider.tsx(2 hunks)packages/project-builder-web/src/app/ProjectDefinitionProvider/services/parse-project-definition-contents.ts(1 hunks)packages/project-builder-web/src/services/error-formatter.ts(1 hunks)packages/project-builder-web/src/services/project-id.service.ts(1 hunks)packages/tools/eslint.config.node.js(1 hunks)tests/simple/packages/e2e/package.json(1 hunks)turbo.json(2 hunks)
💤 Files with no reviewable changes (1)
- packages/create-project/src/project-creator.ts
🧰 Additional context used
🧬 Code Definitions (11)
packages/project-builder-server/src/api/types.ts (1)
packages/project-builder-server/src/server/builder-service-manager.ts (1) (1)
BuilderServiceManager(7:63)
packages/project-builder-cli/src/index.ts (1)
packages/project-builder-cli/src/server.ts (1) (1)
addServeCommand(69:95)
packages/project-builder-server/src/server/builder-service-manager.ts (1)
packages/project-builder-server/src/service/builder-service.ts (1) (1)
ProjectBuilderService(75:282)
packages/project-builder-server/src/api/trpc.ts (2)
packages/project-builder-server/src/api/context.ts (1) (1)
Context(27:29)packages/project-builder-server/src/utils/errors.ts (1) (1)
UserVisibleError(8:19)
packages/project-builder-cli/src/utils/version.ts (1)
packages/create-project/src/version.ts (1) (1)
getPackageVersion(7:27)
packages/project-builder-server/src/plugins/plugin-discovery.ts (1)
packages/project-builder-server/src/utils/errors.ts (1) (1)
UserVisibleError(8:19)
packages/project-builder-server/src/server/plugin.ts (2)
packages/project-builder-lib/src/feature-flags/flags.ts (1) (1)
FeatureFlag(3:3)packages/project-builder-server/src/server/builder-service-manager.ts (1) (1)
BuilderServiceManager(7:63)
packages/project-builder-cli/tests/settings.spec.ts (1)
packages/project-builder-cli/tests/fixtures/server-fixture.test-helper.ts (1) (1)
test(96:240)
packages/project-builder-server/src/server/server.ts (3)
packages/project-builder-lib/src/feature-flags/flags.ts (1) (1)
FeatureFlag(3:3)packages/project-builder-server/src/server/builder-service-manager.ts (1) (1)
BuilderServiceManager(7:63)packages/project-builder-server/src/server/plugin.ts (1) (1)
baseplatePlugin(18:155)
packages/project-builder-cli/tests/fixtures/server-fixture.test-helper.ts (5)
packages/project-builder-server/src/server/builder-service-manager.ts (1) (1)
BuilderServiceManager(7:63)packages/project-builder-server/src/server/index.ts (1) (1)
BuilderServiceManager(16:16)packages/project-builder-cli/src/server.ts (1) (1)
serveWebServer(25:67)packages/project-builder-cli/src/services/logger.ts (1) (1)
DEFAULT_LOGGER_OPTIONS(3:11)packages/project-builder-lib/src/schema/project-definition.ts (1) (1)
ProjectDefinition(61:61)
packages/project-builder-web/src/app/ProjectDefinitionProvider/ProjectDefinitionProvider.tsx (1)
packages/project-builder-web/src/services/error-formatter.ts (1) (1)
formatError(25:31)
🔇 Additional comments (57)
tests/simple/packages/e2e/package.json (1)
13-13: Check for breaking changes in updated Playwright version.
Upgrading from 1.48.0 to 1.51.0 may include changes in the API or new recommended usage. Ensure your E2E tests still pass as expected.packages/project-builder-lib/src/schema/project-definition.ts (1)
54-54: Ensure existing code sets a numeric schemaVersion.
ChangingschemaVersionto a strictly numeric value may break older definitions. Verify all references and migrations handle this constraint.packages/project-builder-web/src/app/ProjectDefinitionProvider/services/parse-project-definition-contents.ts (1)
23-23: Improved error clarity.
RequiringschemaVersionis consistent with the updated schema. This error message clearly indicates what users must fix.packages/project-builder-server/src/api/context.ts (1)
14-14: Use of serviceManager.getService
Nice refactor for improved readability and maintainability. Ensure all references to the service retrieval logic elsewhere are similarly updated.packages/project-builder-cli/.gitignore (1)
3-9: Added ignore entries for node_modules and Playwright outputs
Great additions to keep build artifacts and test outputs out of source control.packages/project-builder-cli/tsconfig.e2e.json (1)
1-11: E2E TypeScript configuration
Configuration aligns well with E2E test requirements. NoEmit is suitable, baseUrl and paths are properly set. Looks good!turbo.json (1)
3-3: New E2E test task and environment pass-through
Good addition to ensure the E2E tests run after the build and have the right environment variables.Also applies to: 22-24
packages/project-builder-lib/src/migrations/index.ts (1)
46-46: Validate handling ofschemaVersion.
Confirm thatschemaVersionis guaranteed to be defined and numeric. Ifconfigcan lack this property, consider a fallback or validation to avoid potential issues.packages/project-builder-server/src/api/trpc.ts (2)
3-4: Import forUserVisibleErrorlooks correct.
No immediate concerns.
9-20: Enhanced error formatting is well-structured.
ReturningisUserVisibleanddescriptionTextaligns with more user-friendly errors. Consider logging or tracking these details if needed.packages/project-builder-cli/src/index.ts (1)
44-44: Check for dependencies on version parameter.
Dropping the version argument is fine if nothing depends on it. Verify that existing code or scripts don’t rely on passing a version toaddServeCommand.packages/project-builder-cli/playwright.config.ts (1)
1-36: Looks great!
Good configuration for Playwright with parallelization, CI-friendly retries, and multiple browsers defined..github/workflows/test-e2e.yml (1)
36-36: Dependency installation looks correct
Thanks for adding the CLI filter; it ensures all relevant dependencies are installed for E2E tests.packages/project-builder-server/src/api/types.ts (1)
4-8:Details
❓ Verification inconclusive
Refactored service management
Switching from an array to a singleserviceManageraligns the code with the new architecture. Ensure any references to the old structure are updated.
🏁 Script executed:
#!/bin/bash # Checking for obsolete references to "services" property rg -A 3 "services\s*:"Length of output: 2184
Action Required: Verify All Service Management References
The changes in
packages/project-builder-server/src/api/types.ts(using a singleserviceManager) correctly reflect the new architecture. However, our grep search detected remaining references to aservicesarray pattern—most notably in:
- packages/project-builder-server/src/compiler/backend/feature.ts
The propertyservices: buildServicesForFeature(builder, featureId)is still present, which might conflict with the updated design.Additionally, similar patterns appear in Docker configuration and generator files. Please review these cases to confirm they either remain valid for their context or need to be refactored to align with the new service management approach.
.changeset/tired-places-pay.md (1)
1-10: Documentation is clear
The new changeset correctly outlines patches and states the introduction of E2E testing for project-builder-cli.packages/project-builder-cli/tsconfig.json (1)
2-10:Details
✅ Verification successful
Validate references to external tsconfig files.
Ensure that the referenced files (
tsconfig.app.jsonandtsconfig.e2e.json) exist and are correctly configured, especially as they replace the previousextendsapproach.
🏁 Script executed:
#!/bin/bash # Verify existence of tsconfig.app.json and tsconfig.e2e.json in the current package. fd 'tsconfig.app.json' packages/project-builder-cli fd 'tsconfig.e2e.json' packages/project-builder-cliLength of output: 197
External tsconfig References Verified
Both
tsconfig.app.jsonandtsconfig.e2e.jsonexist within thepackages/project-builder-clidirectory, confirming that the references inpackages/project-builder-cli/tsconfig.jsonare valid. No changes are required to the configuration.packages/project-builder-server/src/plugins/plugin-discovery.ts (3)
14-14: Consistent error import.Replacing
InitializeServerErrorwithUserVisibleErroraligns with the new user-friendly error handling strategy.
28-31: Improved error transparency.Throwing a
UserVisibleErrorhere helps users understand the issue when thepackage.jsonis missing. Good enhancement.
42-46: Enhanced JSON read error.Switching to
UserVisibleErrorclarifies file read problems and indicates they are user-facing. This is beneficial for surfacing actionable feedback to end users.packages/project-builder-server/src/service/builder-service.ts (1)
139-145: Confirm name sanitization behavior.Deriving and sanitizing the project name is logical, but confirm it won’t restrict valid use cases where underscores or other characters are expected. If such characters are needed, consider adjusting the regex or adding a fallback mechanism.
packages/project-builder-web/src/services/error-formatter.ts (3)
1-3: Imports look appropriate.
They align well with the newly introduced TRPC error handling mechanism.
8-8: Good introduction of TypedTRPCClientError.
Defining a specialized error type improves type safety for TRPC errors.
11-18: Enhanced TRPC user-visible error handling.
The conditional logic cleanly checks if the error is user-visible and prints a friendlier message.packages/project-builder-cli/tests/initialize-project.spec.ts (1)
1-18: New E2E test verifies project initialization.
The flow from adding a project to confirming the final state looks solid and user-centric.packages/project-builder-web/src/app/ProjectDefinitionProvider/ProjectDefinitionProvider.tsx (2)
57-57: Simplified project state usage.
Removing unused references to currentProjectId reduces complexity in this provider.
170-170: Context override for error formatting.
Passing an empty string omits the default message, ensuring error text is displayed plainly.packages/project-builder-cli/src/services/logger.ts (2)
3-11: Good extraction of default logger options.
Encapsulating config in a constant improves readability and reuse for advanced setups.
13-13: Logger instantiation with extracted options.
This approach allows future customization without scattering config details.packages/project-builder-cli/tests/settings.spec.ts (1)
3-17: Validation of basic settings flow looks thorough.
This test accurately verifies that the updated project name is saved and persists after reloading.packages/tools/eslint.config.node.js (2)
6-21: Flexible Node config generation.
The approach with dynamic extra default project files is clean and extensible.
24-24: Default export usage.
Exporting the config viagenerateNodeConfig()centralizes the logic neatly.packages/project-builder-server/src/server/index.ts (1)
1-1: Enhanced server startup return.
ExposingFastifyInstanceandBuilderServiceManagerfosters more flexible integration and testability.Also applies to: 16-16, 20-20, 50-50
packages/project-builder-web/src/services/project-id.service.ts (2)
1-10: Local storage project ID handling.
Storing/removing the projectId here is clear and aligns with typical browser usage.
12-30: Query param fallback logic.
Auto-updating localStorage when detecting a projectId in the URL is convenient. Verify that it's only used in browser environments whereglobalThis.locationis defined.package.json (1)
25-26: Looks good—just ensure the new references exist.The simplified script references streamline E2E tests. Double-check that the
test:e2eandtest:e2e:affectedsteps are properly defined in your turbo configuration.packages/project-builder-server/src/utils/errors.ts (1)
1-19: User-visible error handling improvement.Replacing the standard Error with TRPCError and including a default error code is a clean way to provide user-friendly error messages.
packages/project-builder-server/src/server/builder-service-manager.ts (1)
1-64: Service management design looks solid.Storing services in a map, generating stable IDs via SHAKE256, and ensuring proper cleanup and initialization all follow best practices.
packages/project-builder-cli/src/utils/version.ts (1)
5-29: Stricter error handling enhances reliability.Switching to always returning a string and throwing if the version is unavailable avoids null-check pitfalls.
packages/project-builder-cli/package.json (3)
25-25: Ensure the new TypeScript build config is valid.
Switching totsconfig.build.jsonis a neat way to separate build outputs. Double-check thattsconfig.build.jsonis kept in sync with project needs, such as correctrootDir,outDir, andincludeentries.
49-49:Details
✅ Verification successful
Check for possible vulnerabilities or upgrades for Playwright.
While pinning@playwright/testto1.51.0can be stable, ensure there are no known security advisories or performance issues.
🏁 Script executed:
#!/bin/bash # Description: Query GitHub's advisory DB for known vulnerabilities in @playwright/test gh api graphql -f query=' { securityVulnerabilities(first: 5, ecosystem: NPM, package: "@playwright/test") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } } 'Length of output: 350
Playwright Security & Upgrade Check Confirmed
The GitHub advisory query returned no known security vulnerabilities for@playwright/testversion1.51.0. It appears that the pinned version does not have any reported issues from the advisory DB. However, it's always a good idea to periodically review for updates, performance improvements, or new advisories as future versions are released.
53-53:Details
✅ Verification successful
Confirm Fastify v5 compatibility and stability.
Upgrading tofastify@5.1.0may introduce breaking changes if you previously used a major version below 5. Confirm any potential migration steps. Additionally, check for security advisories.
🏁 Script executed:
#!/bin/bash # Description: Query GitHub's advisory DB for known vulnerabilities in fastify gh api graphql -f query=' { securityVulnerabilities(first: 5, ecosystem: NPM, package: "fastify") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } } 'Length of output: 1495
Fastify v5.1.0 Verified – Confirm Migration Steps if Needed
The GitHub advisory query confirms that the vulnerabilities reported for Fastify affect only versions prior to v5, and none impact Fastify v5.1.0. Based on this, the upgrade appears secure from a vulnerability standpoint. However, please ensure that any required migration steps—especially changes in configuration or plugin compatibility when moving from earlier major versions—are addressed by consulting the Fastify migration guide.
- Verified that known vulnerabilities target versions below Fastify v5.
- No current security advisories affect Fastify v5.1.0.
- Action Required: Manually review the Fastify migration guide to confirm that all necessary adjustments have been made.
packages/project-builder-server/src/server/server.ts (4)
1-1: No issues with the new import.
ImportingFeatureFlaghere is consistent with your updatedWebServerOptionsinterface.
14-15: Confirm the new dependency usage.
Bringing inBuilderServiceManageraligns with your new centralized service architecture.
24-24: Added serviceManager to WebServerOptions.
Ensure that all callers ofbuildServer()supply a properly configuredserviceManagerinstance.
32-32: serviceManager destructuring looks correct.
The function now has what it needs to manage services properly.packages/project-builder-server/src/server/plugin.ts (7)
1-1: FeatureFlag import.
This import ensures that the plugin can handle feature flags seamlessly.
16-16: New import for BuilderServiceManager.
This aligns the plugin with your centralized service management solution.
21-22: Refined plugin signature for serviceManager.
Replacing array-based service handling with aserviceManagerparameter centralizes control and simplifies the plugin’s interface.
38-38: serviceManager in TRPC context.
InjectingserviceManagerinto the context is a clean approach for consistent service lookups.
59-59: Graceful handling of missing services.
UsingserviceManager.getService(projectId)plus a 404 fallback is correct and user-friendly.
101-101: Same approach for /web route.
This maintains consistent 404 handling if the service doesn’t exist.
153-153: Proper resource cleanup.
serviceManager.removeAllServices()on close helps ensure a clean shutdown.packages/project-builder-cli/tests/fixtures/server-fixture.test-helper.ts (4)
19-21: Robust error handling confirmation.Your logic correctly checks for
'EADDRINUSE'and retries or re-throws other errors. However, confirm whether there are any other transient errors (e.g., permission issues, ephemeral race conditions) that you wish to handle in a similar manner to ensure robust test reliability.Also applies to: 47-57
66-93: Interface definitions promote clear collaboration.The
ProjectPayloadinterface is well-defined, making it straightforward to understand how project data is accessed or mutated. Good job including doc comments to clarify usage.
140-223: Potential concurrency concerns with repeated calls to addProject.Each new call increments
projectIdxand writes to a new directory undertemporaryDirectory. This might break if the test runs concurrently and multiple processes attempt to manage the same base folder. Validate that your test runs in an isolated environment or consider adding a unique identifier (like a UUID) to the folder name.
242-243: Exportingexpectis convenient.Forwarding
expectfrom@playwright/testhere is a neat approach to keep imports tidy in your tests. This is a good pattern to enforce consistent usage of the test library.packages/project-builder-cli/src/server.ts (1)
25-67: Modular approach to server setup is commendable.Extracting the logic into
serveWebServerclarifies responsibilities, makes it easier to test, and fosters reusability. Good practice!
| await server.register(fastifyHelmet, { | ||
| contentSecurityPolicy: { | ||
| directives: { | ||
| // Disable upgrade-insecure-requests to allow insecure requests to localhost | ||
| // This is required for Safari to work (https://github.com/helmetjs/helmet/issues/429) | ||
| upgradeInsecureRequests: null, | ||
| }, | ||
| }, | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Disable upgradeInsecureRequests with caution.
Allowing mixed content in Safari can be helpful during local development, but it may pose security risks in production. Consider conditionally disabling upgradeInsecureRequests only in development environments.
kingston
deleted the
kingston/eng-574-introduce-e2e-tests-for-project-creation-and-saving
branch
1 participant
Summary by CodeRabbit
New Features
Refactor
Tests
Chores