Skip to content

Commit 3b1053f

Browse files
committed
[Bundles] Better explain how to develop reusable bundles locally
1 parent dd39eab commit 3b1053f

File tree

1 file changed

+78
-3
lines changed

1 file changed

+78
-3
lines changed

bundles.rst

Lines changed: 78 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -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+
165240
Learn more
166241
----------
167242

0 commit comments

Comments
 (0)