@@ -142,9 +142,10 @@ to be adjusted if needed:
142142
143143.. tip ::
144144
145- It's recommended to use the `PSR-4 `_ autoload standard: use the namespace as key,
146- and the location of the bundle's main class (relative to ``composer.json ``)
147- as value. As the main class is located in the ``src/ `` directory of the bundle:
145+ It's recommended to use the `PSR-4 `_ autoload standard on your bundle's
146+ ``composer.json `` file. Use the namespace as key, and the location of the
147+ bundle's main class (relative to ``composer.json ``) as value. As the main
148+ class is located in the ``src/ `` directory of the bundle:
148149
149150 .. code-block :: json
150151
@@ -161,6 +162,80 @@ to be adjusted if needed:
161162 }
162163 }
163164
165+ Developing a Reusable Bundle
166+ ----------------------------
167+
168+ Bundles are meant to be reusable pieces of code that live independently from
169+ any particular Symfony application. However, a bundle cannot run on its own: it
170+ must be registered inside an application to execute its code.
171+
172+ This can be a bit challenging during development. When working on a bundle in
173+ its own repository, there's no Symfony application around it, so you need a way
174+ to test your changes inside a real application environment.
175+
176+ There are two common approaches to do this, depending on whether your bundle has
177+ already been published or is still under development.
178+
179+ Using a Local Path Repository
180+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
181+
182+ If your bundle hasn't been published yet (for example, it's not available on
183+ Packagist), you can point Composer to your local bundle directory from any
184+ Symfony application you use for testing.
185+
186+ Edit the ``composer.json `` file of your application and add this:
187+
188+ .. code-block :: json
189+
190+ {
191+ "repositories" : [
192+ {
193+ "type" : " path" ,
194+ "url" : " /path/to/your/AcmeBlogBundle"
195+ }
196+ ],
197+ "require" : {
198+ "acme/blog-bundle" : " *"
199+ }
200+ }
201+
202+ Then, in your application, install the bundle as usual:
203+
204+ .. code-block :: terminal
205+
206+ $ composer require acme/blog-bundle
207+
208+ Composer will create a symbolic link (symlink) to your local bundle directory,
209+ so any change you make in the ``AcmeBlogBundle/ `` directory is immediately
210+ visible in the application. You can now enable the bundle in ``config/bundles.php ``::
211+
212+ return [
213+ // ...
214+ Acme\BlogBundle\AcmeBlogBundle::class => ['all' => true],
215+ ];
216+
217+ This setup is ideal during early development because it allows quick iteration
218+ without publishing or rebuilding archives.
219+
220+ Linking an Already Published Bundle
221+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
222+
223+ If your bundle is already public (for example, it's published on Packagist),
224+ you can still develop it locally while testing it inside a Symfony application.
225+
226+ In your application, replace the installed bundle with a symlink to your local
227+ development copy. For example, if your bundle is installed under
228+ ``vendor/acme/blog-bundle/ `` and your local copy is in ``~/Projects/AcmeBlogBundle/ ``:
229+
230+ .. code-block :: terminal
231+
232+ $ rm -rf vendor/acme/blog-bundle/
233+ $ ln -s ~/Projects/AcmeBlogBundle/ vendor/acme/blog-bundle
234+
235+ Symfony will now use your local bundle directly. You can edit its code, run
236+ tests, and see the changes immediately. When you're done, restore the vendor
237+ folder or reinstall the package with Composer to go back to the published version.
238+
164239Learn more
165240----------
166241
0 commit comments