Import to an existing project

[Anonym69]

Is your feature request related to a problem? Please describe.
These days it is possible to import an app into a new project, and that is fine and dandy, but I would also like to see that it is possible to import a project into an EXISTING project

Describe the solution you'd like
Being able to import a project into an existing project (and then after that be able to do a new import) would be a savior which would also be very good for the modularity when doing the actual development.

Describe alternatives you've considered
The only alternative as I know, is to rewrite the code using a reference to the project I want to rewrite ( @Old-Project ). The thing is that every rewrite comes with the risk that the AI mess things up. Importing a project would not have to result in rewriting anything.

Additional context
(there are no images of this. It's enough described above)

[github-actions[bot]]

This issue might be a duplicate of existing issues. Please check:

• Support import existing project #163: Contains nearly identical title 'Support import existing project' and requests same core functionality (confidence: high)
• Saving and reusing created code as components or similar #1004: Requests saving and reusing code/features across projects for modularity, addressing same underlying need (confidence: medium)
• Support Smart Context for cross-app references #1381: Requests combining features from one app into another using cross-app references (confidence: medium)

Feel free to ignore if none of these address your specific case.

[Anonym69]

This , #163 , is not the same. That is about importing an existing project. Mine is also about importing, but importing an existing project into another existing project.

[wwwillchen]

i don't really know how you would be able to import a project into an existing project without merging them together with AI (essentially what the cross-app reference feature you mentioned)

we'd love to support more modular development for dyad, but it's pretty tricky and still not sure what's the best way to do this. i'll go ahead turn this into a discussion so more people can chime in.

[Anonym69]

When asking dyad to re-write / convert an app using @ , it has to be super specific to work, for backend parts this might work, for UIs it is very likely to mess things up.

If everything is in a monolith then all ok, but that is not what I would label as modern web development and certainly not scalable development. My app's backend is split up in microservices and an orchestrator which handles requests from the client app to the microservices that performs most of what I want to do, the core part of the functionality. I am using HAproxy to be able to fire up "unlimited" instances of the microservices to reach "unlimited" horizontal scaling on whatever servers using a very simple round robin algorithm.

The backend is separated and works. It's coded with Node.js, Express.js , TS and JS and is implemented with several layers of security.

Now over to the frontend and this is where the problems are. I have split up my frontend in several core parts because I know the high risk that the AI will break the code and UI: the website, several components that deals with other ways of working with what is generated in the microservices backend. At the moment I have 4 such parts, which are based on Next.js (and some are React.js). The website just keeps track of the user account, subscriptions etc, but doesn't provide any heavier functionality, except making requests to the orchestrator, but there is a need for more client related functionality. This is where I have these three other components for. They have to be included into the web client app and right now there is no other way than doing it with @ but this also means that I will lose stuff in the way and when it comes to UIs, we all know that the AI WILL mess things up. So I have to be able to import the other three components into the webapp (just like the initial post: Import a project into an existing project). This should be possible to do fairly easy. They don't have to share the same code base, although it's preferable, but they have to be able to communicate with each other.

Creating apps as React.js monoliths is hardly any modular development, so this requires something else. Importing these components/functionalities into an existing project, the client web app., one project at a time.

It's not just for me that this is important. It is also important for Dyad, as I see it. The way I see it, this very ambitious project has every chance to be the "proof" that Dyad is well suitable for serious development also for far more advanced apps than what you very with Lovable, Replit, Bolt etc tools that just produces monoliths, usually cute websites

[Anonym69]

Today I tried three ways of solving this. None of them were any good.

I tried a few times with cloning the functions, datastructures, hooks, components etc etc using @ . (Yes, it is possible, just set the mode to Dyad ask). This failed twice. It went crazy!

The other way I tested was to copy the files from the source app to the the target app and then ask Dyad to import the files into the project. That didn't work either.

Right now I am rewriting the whole thing. A total waste of time of the work I have already put in (and the AI go totally nuts too often) and it shouldn't have to work this way. This could work, but isn't a solution to the real problem, the inability to merge two projects into one project.

[Anonym69]

@wwwillchen

I came to think of something... Would it be possible to, from the source project, create some sort of "manifest" with what code is needed to make the functionality work on a new system/app? In such a manifest, it would be good if there was mentioned what is the main function/component etc and in where the source files where. Then on the target system (the app where the old app would be merged into) the files could be placed in another directory temporarily and ask Dyad for importing the functionality using the manifest and in to the target systems code base? Since this would mean that the relative path would change, it would be crucial for the manifest to use path mapping, but just locally so that the tsconfig.json file would not be affected. Such a manifest should include a textfile with all the files and paths.

This would simulate what I have already done when using the @ , but since when I do it like that it will overwrite the files already there. If there instead was a manifest that would express what functions, data structures, components, hooks etc, then maybe it would be easier to import the assets then.

[Anonym69]

Phew! I have now spent hours to try to rewrite one part to get it in to the client app, but I have to give up! It worked perfectly in its first version, which was a parallel project (and I had to do it like that to not break the code of the other modules, I thought it would work to use the @ to make it work. It didn't. Now, rewriting it is also a complete failure. Nothing is even close to how it was before and it looked soooooo good before, now it's not possible to even use it. If you want to, Will, we can have a video call about this so I can share my screen. I will be happy to show you and see if we can find a way to solve this.