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