Skip to content

Conversation

@Olyno
Copy link
Contributor

@Olyno Olyno commented Aug 10, 2025

Description

This pull request keeps the same path as the imported project, instead of duplicating it into dyad-apps folder.

Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

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

cubic analysis

No issues found across 2 files. Review in cubic

@wwwillchen
Copy link
Contributor

I think this change makes sense, but there's a bunch of E2E test failing. if you want to try and fix them that'll be very helpful, otherwise, I can look at this later.

@wwwillchen wwwillchen changed the title chore: use imported directory as project path use imported directory as project path Aug 13, 2025
@Olyno
Copy link
Contributor Author

Olyno commented Aug 13, 2025

I would be happy to help! Unfortunately, Github CI shows empty logs.

@antont
Copy link
Contributor

antont commented Aug 26, 2025

I would be happy to help! Unfortunately, Github CI shows empty logs.

The logs don't seem to be empty now, there are errors like this in the run here

- /Users/runner/work/dyad/dyad/node_modules/playwright/lib/common/process.js

   at helpers/test_helper.ts:1

> 1 | import { test as base, Page, expect } from "@playwright/test";
    | ^
  2 | import * as eph from "electron-playwright-helpers";
  3 | import { ElectronApplication, _electron as electron } from "playwright";
  4 | import fs from "fs";
    at Object.<anonymous> (/Users/runner/work/dyad/dyad/e2e-tests/helpers/test_helper.ts:1:1)
    at Object.<anonymous> (/Users/runner/work/dyad/dyad/e2e-tests/version_integrity.spec.ts:1:1)

Retry #2 ───────────────────────────────────────────────────────────────────────────────────────

Error: Cannot find module '@playwright/test'
Require stack:
- /Users/runner/work/dyad/dyad/e2e-tests/helpers/test_helper.ts
- /Users/runner/work/dyad/dyad/e2e-tests/version_integrity.spec.ts
- /Users/runner/work/dyad/dyad/node_modules/playwright/lib/transform/transform.js
- /Users/runner/work/dyad/dyad/node_modules/playwright/lib/common/esmLoaderHost.js
- /Users/runner/work/dyad/dyad/node_modules/playwright/lib/common/process.js

   at helpers/test_helper.ts:1

> 1 | import { test as base, Page, expect } from "@playwright/test";
    | ^
  2 | import * as eph from "electron-playwright-helpers";
  3 | import { ElectronApplication, _electron as electron } from "playwright";
  4 | import fs from "fs";
    at Object.<anonymous> (/Users/runner/work/dyad/dyad/e2e-tests/helpers/test_helper.ts:1:1)
    at Object.<anonymous> (/Users/runner/work/dyad/dyad/e2e-tests/version_integrity.spec.ts:1:1)

Comment on lines 47 to 51
handle("check-app-name", async (_, { appName }: { appName: string }) => {
// Check filesystem
const appPath = getDyadAppPath(appName);
try {
await fs.access(appPath);
return { exists: true };
} catch {
// Path doesn't exist, continue checking database
}

// Check database
// Only check the database since we no longer copy to a fixed path
const existingApp = await db.query.apps.findFirst({
where: eq(apps.name, appName),
});
Copy link
Contributor

Choose a reason for hiding this comment

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

The check-app-name handler currently only validates if the app name exists in the database, but it should also verify if the provided source path already exists in any app record. Since the implementation now uses the original path instead of copying to a fixed location, a user could receive misleading feedback where the name check passes but the subsequent import operation fails due to a path conflict. Consider adding path uniqueness validation to this handler to provide more accurate feedback earlier in the process.

Spotted by Diamond

Fix in Graphite


Is this helpful? React 👍 or 👎 to let us know.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would you like me to do that?

@Olyno
Copy link
Contributor Author

Olyno commented Oct 23, 2025

Sorry for the delay! The error you see doesn't seem to come from the PR itself, except if i misunderstood something. @antont

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.

3 participants