Skip to content

Commit 0b7af9b

Browse files
committed
Merge branch '7.4' into 8.0
* 7.4: [Bundles] Better explain how to develop reusable bundles locally
2 parents 9995731 + 2df608a commit 0b7af9b

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
@@ -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+
164239
Learn more
165240
----------
166241

0 commit comments

Comments
 (0)