<p>@Wally, since DDEV runs on Docker, which is containerised as it's whole. It is meant to not run into dependency sharing or conflicts. Dependencies are saved per project / per container. They will never clash or cause version issues whatsoever.</p>
<p>It's a more modern approach than using MAMP or Valet or the sorts, where you'd be responsible of installing your node version,composer version etc... locally. With DDEV these packages live within the project/container. So if you have one project running on php7.4, another on php8.0, yet another on php8.1 each with node versions 12/14/16 this doesn't matter in a Docker/DDEV environment. This is all being taken care of.</p>

CC BY-SA 4.0
2023-02-09T15:17:11.713Z
Ok cook thanks for the help here - so the DDEV project is contained thanks to Docker - so even the NPM packages are not going to cause issue? Also side note here - does this require you to then be running composer / npm thorugh DDEV i.e. ddev composer <command> or is it enough to be in the same DIR i.e. /<your project folder> and just run the standard npm i or composer install? (thanks)
Wally
CC BY-SA 4.0
2023-02-09T13:19:29.480Z
2023-02-09T13:19:29.480Z
Michael Thomas
<p>So the other day I was queried about Composer dependencies and potential risks for different locally installed packages to clash or cause version issues.</p>
<p>Since then I have done a little bit of digging on the subject but wanted to confirm or if wrong set up some fail safes.</p>
<p>Its worth noting that we are using DDEV for local development when building Craft websites.</p>
<hr />
<p>OK so:</p>
<p>My understanding is that because there is a Composer.lock file that is included with the Craft Build, Craft will not use Dependencies out of the specified version number in that lock file i.e.</p>
<p>Craft Site A
Composer.lock says package X is set to 1.5</p>
<p>Craft site B
Composer.lock says package X is set to 2.5</p>
<p>Locally you have the most up to date version of that package - V7.0 but this will not interfere with either of the Craft sites as they have specific versions set for their build.</p>
<hr />
<p>DDEV and containerising dependencies.</p>
<p>Sorry this is a bit of a broader question and I wanted to check in with other devs to see if this is a must and something that the build tool is already doing or something that should be noted as a issue?</p>
<hr />
<p>Thanks for any help on this subject, sorry again for the slightly broad scope of this question.
W</p>

<composer>
Containerising composer dependencies in DDEV (Generalised question)
# Containerising composer dependencies in DDEV (Generalised question)

(Asked by: username_0 on 2023-02-09)

So the other day I was queried about Composer dependencies and potential risks for different locally installed packages to clash or cause version issues.

Since then I have done a little bit of digging on the subject but wanted to confirm or if wrong set up some fail safes.

Its worth noting that we are using DDEV for local development when building Craft websites.

---

OK so:

My understanding is that because there is a Composer.lock file that is included with the Craft Build, Craft will not use Dependencies out of the specified version number in that lock file i.e.

Craft Site A
Composer.lock says package X is set to 1.5

Craft site B
Composer.lock says package X is set to 2.5

Locally you have the most up to date version of that package - V7.0 but this will not interfere with either of the Craft sites as they have specific versions set for their build.

---

DDEV and containerising dependencies.

Sorry this is a bit of a broader question and I wanted to check in with other devs to see if this is a must and something that the build tool is already doing or something that should be noted as a issue?

---

Thanks for any help on this subject, sorry again for the slightly broad scope of this question.
W

**Tags:** composer

---

## 1 answers

### Answer by username_1 on 2023-02-09. Score: 2 | Accepted answer

@Wally, since DDEV runs on Docker, which is containerised as it's whole. It is meant to not run into dependency sharing or conflicts. Dependencies are saved per project / per container. They will never clash or cause version issues whatsoever.

It's a more modern approach than using MAMP or Valet or the sorts, where you'd be responsible of installing your node version,composer version etc... locally. With DDEV these packages live within the project/container. So if you have one project running on php7.4, another on php8.0, yet another on php8.1 each with node versions 12/14/16 this doesn't matter in a Docker/DDEV environment. This is all being taken care of.

> **Comments:**
> **username_0**: Ok cook thanks for the help here - so the DDEV project is contained thanks to Docker - so even the NPM packages are not going to cause issue? Also side note here - does this require you to then be running composer / npm thorugh DDEV i.e. ddev composer <command> or is it enough to be in the same DIR i.e. /<your project folder> and just run the standard npm i or composer install? (thanks)  

---

