Refactor to be bundle or stand-alone application

[tacman]

I'm running into issues where I'm fixing outdated code in the symfony demo, rather than in the libraries here.

So I'm wondering if perhaps this tool should be refactored, to either a stand-alone page (symfony-bundle-generator), or a bundle itself (BundleGeneratorBundle, or BundleMakerBundle).

I'm inclined toward the latter. The workflow would then be to create a new symfony project (or use an existing one), add this as a bundle as a --dev dependency, generate the new bundle, add entities and configuration, etc. I can envision a "how to refactor your code to a reusable bundle" tutorial.

Class "Eat your own dog food" -- we'd use this skeleton to create the generator bundle, then refactor it.

Thoughts? I've followed many tutorials on how to create a bundle, but this is the best tool I've found for doing so, I'd love to leverage it and make it even more useful.

Since it's such a drastic change, I'm also fine with doing the able and creating a new repo, and credit this repo as the original work, since you mentioned you weren't doing much development on it anymore.

[msalsas]

As you may know, this project was originally forked from this demo.

I think that the easiest way to update this project would be to merge the original project changes and then make the needed changes to make it work. What do you think?

I'm running into issues where I'm fixing outdated code in the symfony demo, rather than in the libraries here.

So should we revert the last merged PR and discard the not merged one?

[tacman]

But why the demo as the base? Symfony provides a nice way to create a skeleton, the demo obviously has a lot more overhead.

My train of thought was then if we're going to that, we should be able to install the generator as a bundle itself. Then the application could decide how to implement the bundle generation. For example, a web-based interface would be slick. That is, separate the core logic of the bundle creation from the application.

So the workflow would be:

• Create a Symfony project (or use an existing one). symfony new my_domain_bundle_creator --full
• composer require bundle-maker-bundle
• configure bundle_maker.yaml (optional, domain, author, etc.)
• Open a bundle form page to create a new bundle.
• OR run the CLI
• If the bundle needs to be customized, do so by overwriting services and templates.

[tacman]

I'm running into issues where I'm fixing outdated code in the symfony demo, rather than in the libraries here.

I was trying to add tests, but I discovered that I was testing the symfony demo code, when I wanted to test the bundle generation code. Which also suggests moving this to a bundle or a very simple stand-alone app / microservice.

[msalsas]

I was refering to the easiest way. If you want to do that refactor I'm ok with it, but you'll have to do a lot of work. It could be a great project though.

I suggest to begin with a CLI instead of GUI. It would be easier and faster to refactor. Then you could improve it with a GUI.

I'm fine with doing it in this repo as well if you want.

I was trying to add tests, but I discovered that I was testing the symfony demo code, when I wanted to test the bundle generation code. Which also suggests moving this to a bundle or a very simple stand-alone app / microservice.

Yes, I didn't add any tests for it. They are from the demo project.
Then I understand I can keep that PR and accept the last one, right?

[tacman]

Then I understand I can keep that PR and accept the last one, right?

Yes

…

On Sun, Nov 14, 2021 at 8:39 AM Manolo Salsas ***@***.***> wrote: I was refering to the *easiest* way. If you want to do that refactor I'm ok with it, but you'll have to do a lot of work. It could be a great project though. I suggest to begin with a CLI instead of GUI. It would be easier and faster to refactor. Then you could improve it with a GUI. I'm fine with doing it in this repo as well if you want. *I was trying to add tests, but I discovered that I was testing the symfony demo code, when I wanted to test the bundle generation code. Which also suggests moving this to a bundle or a very simple stand-alone app / microservice.* Yes, I didn't add any tests for it. They are from the demo project. Then I understand I can keep that PR and accept the last one, right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEXIQKI2QJWYSUO4B3RQO3UL63ZZANCNFSM5H6X5HXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.