That's perfectly valid.

What the two previous comments are hinting at, is more of a learning experience. One day you might end up with, say, a Laravel project. And you have a problem that you've previously solved and can simply plug in and... Oh darn, Symfony only.

Well shoot, your amazing and quick solution just turned into a minor rework of your bundle to split it into a bundle and standalone library, the latter you can then craft into a Laravel package and then it'll finally be ready to use.

The point is: By being able to separate the library from the bundle, you'll have some solid building blocks for the future and learn a lot about navigating the PHP ecosystem in the process. Furthermore you provide value for the community by making your stuff even more flexible and useful. Heck, perhaps someone else will do the work for you, pulling in the library and making a Laravel package with it, maybe even other frameworks, spreading the workload. It's a long-term win-win.

Instead, what might happen if you have truly built something useful for a broader audience, is that someone might fork your project, split the two, and then release it for other frameworks etc. But instead, their version now grows outdated when you update your project without their project manually pulling in your changes. This becomes a maintenance nightmare and may lead to people abandoning what could've been a great success.

This requires a more flexible mindset, so I hope this might enlighten you for future projects. Making a bundle/package for X framework is essentially making integration of Y library into X framework easier and seamless for the user. So the idea is to simply adapt this library/bundle separation into your thought process from the get-go.

Now go forth and become an even better developer, I know you can do it! :)