Creating a Shared Commons Entry =============================== .. caution:: While this method still works, see :doc:`/frontend/encore/split-chunks` for the preferred solution to sharing assets between multiple entry files. Suppose you have multiple entry files and *each* requires ``jquery``. In this case, *each* output file will contain jQuery, slowing down your user's experience. To solve this, you can *extract* the common libraries to a "shared" entry file that's included on every page. Suppose you already have an entry called ``app`` that's included on every page. Update your code to use ``createSharedEntry()``: .. code-block:: diff Encore // ... - .addEntry('app', './assets/js/app.js') + .createSharedEntry('app', './assets/js/app.js') .addEntry('homepage', './assets/js/homepage.js') .addEntry('blog', './assets/js/blog.js') .addEntry('store', './assets/js/store.js') Before making this change, if both ``app.js`` and ``store.js`` require ``jquery``, then ``jquery`` would be packaged into *both* files, which is wasteful. By making ``app.js`` your "shared" entry, *any* code required by ``app.js`` (like jQuery) will *no longer* be packaged into any other files. The same is true for any CSS. Because ``app.js`` contains all the common code that other entry files depend on, its script (and link) tag must be on every page. .. tip:: The ``app.js`` file works best when its contents are changed *rarely* and you're using :ref:`long-term caching `. Why? If ``app.js`` contains application code that *frequently* changes, then (when using versioning), its filename hash will frequently change. This means your users won't enjoy the benefits of long-term caching for this file (which is generally quite large).