>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2477789. --> Reported by: [xano](https://www.drupal.org/user/62965) >>> <p>Postponed: Waiting on <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/1612910" title="Status: Closed (fixed)">#1612910: [policy, no patch] Switch to Semantic Versioning for Drupal contrib extensions (modules, themes, etc)</a></span>.</p> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Last week, at Drupal Dev Days Montpellier, we (@klausi, @fago, @derhasi, @fubhy, @bojanz, @mariancalinro, and @Xano) had a long and fruitful discussion about managing Composer dependencies for modules in Drupal 8. We learned a lot, but also discovered that allowing modules to be placed into applications the 'old' way (putting a package in a <code>modules</code> folder) will inevitably lead to critical failures (fatal errors if required classes do not exist) if those modules require Composer packages.</p> <p>As <a href="https://www.drupal.org/project/composer_manager">Composer Manager</a> is only a temporary solution (I will yield the floor to @bojanz here, as he can explain its limitations much better than I can), we realized that Composer-driven development is possibly the only solution that prevents people's sites from breaking badly because of missing dependencies. This means that Drupal applications can no longer be built by putting contributed modules in a <code>modules</code> folder, but that the application requires one primary Composer file that manages all dependencies, including Drupal core and contributed modules.</p> <p>There are several reasons why we should allow modules to specify dependencies through Composer:</p> <ul> <li><a href="http://www.garfieldtech.com/blog/off-the-island-2013">Getting off the island</a> (better integration with other PHP systems)</li> <li>Reducing maintainers' workloads by allowing them to reuse much more existing code than they've been able to use before. This reduces development time, increased quality, and could go a long way to prevent burnouts.</li> </ul> <p>This proposal leaves the functionality to enable and uninstall modules through the module handler (and therefore the administrative UI) intact. It only covers the approach we use to assemble the code base.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>Remove the update manager (<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-5"><a href="https://www.drupal.org/project/drupal/issues/2352637" title="Status: Closed (won't fix)">#2352637: Remove the UI for installing/updating modules from update module if it is not fixed in time for release</a></span>).</li> <li><del>Make <a href="http://packagist.drupal-composer.org/">http://packagist.drupal-composer.org/</a> an official Drupal Packagist repository (and document it is).</del> We now have the D.O Composer fa&ccedil;ade: <a href="https://www.drupal.org/drupalorg/blog/drupalorgs-composer-endpoints-are-out-of-beta">https://www.drupal.org/drupalorg/blog/drupalorgs-composer-endpoints-are-out-of-beta</a></li> <li>In order to help non-coders, develop a browser plugin or drupal.org functionality that lets people 'shop' for contributed projects and assemble a <code>composer.json</code> file using point-and-click actions.</li> <li>Document that to build a Drupal site, people will now be able to run Composer (and therefore PHP) on any computer/server they have access to, so the Composer dependencies can be pulled in. Update: The Composer-for-Drupal guide landing page is here: <a href="https://www.drupal.org/docs/develop/using-composer">https://www.drupal.org/docs/develop/using-composer</a></li> <li>Remove packaged modules with Drupal 8 compatibility from drupal.org and replace them with Composer instructions.</li> </ul> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <p>To be determined.</p> <h3 id="summary-ui-changes">User interface changes</h3> <ul> <li><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-5"><a href="https://www.drupal.org/project/drupal/issues/2352637" title="Status: Closed (won't fix)">#2352637: Remove the UI for installing/updating modules from update module if it is not fixed in time for release</a></span></li> <li>drupal.org will no longer feature file downloads for Drupal 8 modules, but instructions on how to build Composer files instead.</li> </ul> <h3 id="summary-api-changes">API changes</h3> <p>Modules can no longer simply be downloaded and placed in a <code>modules</code> directory, but have to be placed within a Drupal application to Composer.</p> > Related issue: [Issue #2352637](https://www.drupal.org/node/2352637) > Related issue: [Issue #2538090](https://www.drupal.org/node/2538090) > Related issue: [Issue #2551607](https://www.drupal.org/node/2551607) > Related issue: [Issue #2494073](https://www.drupal.org/node/2494073) > Related issue: [Issue #2830880](https://www.drupal.org/node/2830880) > Related issue: [Issue #2867757](https://www.drupal.org/node/2867757) > Related issue: [Issue #2306013](https://www.drupal.org/node/2306013) > Related issue: [Issue #2910136](https://www.drupal.org/node/2910136) > Related issue: [Issue #3012129](https://www.drupal.org/node/3012129) > Related issue: [Issue #2002304](https://www.drupal.org/node/2002304)