solascriptura

use - синтаксический сахар времени компиляции и действует в пределах только одного файла.

Почитайте доку для разнообразия.
Неймспейсы и директивы use работают на уровне файлов. То есть use связывает полное имя с кратким/алиасом только в том файле, где его написали.

/path/to/project/ это путь к проекту и данный путь нигде не фигурирует, это та директория из которой запускается основной index.php

Нет. Этот корневая директория проекта. Из нее запускается композер. В ней же обычно лежит DOCUMENT_ROOT каталог, в котором уже и находится точка входа index.php. Также здесь лежат директории vendor (для сторонних пакетов) какой нибудь application/ для ваших файлов.

Давайте попробую объяснить на примере.

Пусть будет такая структура, например.



в vendor - вам ничего самому писать не нужно. Этот папка для композера.
public_html - в ней только index.php и все ваши css, images, js. Это папка на которую указывает DOCUMENT__ROOT в настройках домена вашего сервера. Только эти файлы доступны "по интернету".
application - здесь все ваши самописные php файлы.
(На остальные каталоги не обращаем внимания, в корне проекта можно располагать все что вам удобно, это не будет доступно из web)

Под такую структуру написан подобный composer.sjon

{
  "require": {
    "php": ">=5.5.9",
    "slim/slim": "2.*",
    "twig/twig": "~1.18",
    "slim/views": "^0.1.3",
    "robmorgan/phinx": "^0.4.4",
    "illuminate/database": "^5.1"
  },
  "minimum-stability": "stable",
  "autoload": {
    "psr-4": {
      "MyName\\MyProject\\": "application"
    }
  }
}

Тут вроде бы все просто. В require перечислены используемые пакеты. Поясню только autoload. Автозагрузка по стандарту PSR-4. Указано пространство имен ваших файлов и папка в которой они лежат.
Если ваш класс MyClass лежит в папке application - то у него должно быть пространство имен \MyName\MyProject (полное имя класса получается \MyName\MyProject\MyClass). Если ваш класс MyController лежит в папке application/Mvc/Controllers, то, соответственно \MyName\MyProject\Mvc\Controllers\MyController.

При этом вам не нужно заморачиваться и писать автозагрузчик. Просто выполните команду php composer.phar install (или php composer.phar dumpautoload для пересборки аавтозагрузчика) и подключите файл автозагрузчика в index.php
include '../vendor/autoload.php';

Не использовать композер не имеет смысла, т.к. это очень просто. Просто скачайте файл https://getcomposer.org/composer.phar в корень проекта и пользуйтесь (см выше).

че тут думать-то

.image {
  width:100px;
  height: 100px;
  border-radius: 50%;
  position: relative;
  overflow: hidden;
}
.image > img {
  display: block;
  position: absolute;
  left: 50%;
  top: 50%;
  transform: translate(-50%, -50%);
}

PS
ТОСТЕР, ПРИКРУТИ «EMMET» К РЕДАКТОРУ!!!
И сделай в нем monospace шрифт

Блоки product должны кардинально различаться друг от друга, при том что они имеют одинаковую структуру. Как быть в такой ситуации?

Просто это два разных блока, если между ними ничего общего кроме структуры. В списке будет массив блоков .product-card, на странице товара блок .product, наименования конечно можно любые сделать, по своему вкусу.

С точки зрения БЭМ, корректно будет сделать модификаторы.

.clients__client--client1
.clients__client--client2
.clients__client--client3
.clients__client--client4

nth для единичных случаев лучше не использовать вообще. Только для повторяющихся, логических.
Например, каждое 3, каждое 5 число, первые 4 или более сложная схема, но повторяющаяся.

Если положить картинки внутри элементов, они все равно должны иметь свой класс, не вижу смысла.
Так как по БЭМ, каждый тег должен иметь класс.

Работать сейчас самостоятельно во фриленсе = возьмут легко, быстрые деньги, хорошие деньги для молодого. Но упираешься в росте квалификации в тупик через очень скоро. Рост квалификации крайне медленный. И будет всю жизнь до смерти "джуниором". Я сталкивался с такими людьми - им по 30 лет уже, во фриленсе по 10 лет, а до сих пор способны делать только то, что у меня умеют джуны с двухлетним опытом.

Работать сейчас на фирму = возьмут с трудом, с деньгами намного хуже. Но быстро подтянут в квалификации на очень хороший уровень. Потолка квалификации не будет. Только важно!!!! - нужно выбирать сильную фирму с квалифицированными коллегами и работой В ОФИСЕ, очно, а не на удаленке и не мелкую хренофирмочку со слабыми спецами. Потом можно и на фриленс свалить.

Вариант - пойти во фриленс немного, а потом в фирму - теоретически, возможен. Но на практике не проканает. Ибо порядок денег совсем другой. И вы просто не сможете после фриленса умерить свои финансовые аппетиты настолько чтобы пойти в фирму. Понравится тратить хорошие деньги. Даже если головой будете понимать, что годами занимаетесь примитивнейшей работой и не растете....

Параметр --prefer-dist

Выполняем команду:
composer init

Следуем инструкциям. В результате, получим частично сконфигурированный файл composer.json. Прописываем в этот файл неймспейсы для автозагрузки классов:

{
// Другие опции...
    "autoload": {
        "psr-4": {
            "MySuperApp\\": "src/"
        }
    }
// Другие опции...
}

Это означает, что классы, имеющие неймспейс MySuperApp\ будут находится в папке src. То есть, класс MySuperApp\First должен лежать прямо в папке src, а класс MySuperApp\Test\Second в папке src/Test. Надеюсь, понятно.

Теперь, нам нужно выложить свой проект на гитхаб. Для этого, создаем там репозиторий и пушим файлы проекта.

Далее, переходим на сайт packagist.com, регистрируемся там. В настройках профиля следуем инструкциям и привязываем аккаунт к github'у. Переходим во вкладку submit, вставляем в инпут ссылку на наш github репозиторий, жмем check (В этот момент packagist проверит, что данный репозиторий принадлежит именно нам), затем, снова check, чтобы подтвердить наш выбор. Вот, собственно, и все! Осталось прикрутить автообновление пакета. Информация об этом тоже есть на сайте.

https://github.com/composer/satis

ну а вообще проще указать git репозиторий напрямую:

"repositories": [
    {
      "type": "git",
      "url": "....git"
    }
]

Отвечает за те зависимости, которые необходимы только для dev-окружения.
К примеру, Вы точно знаете, что библиотека phpunit нужна для разработки, а на проде будет лишней, тогда phpunit попадает в require-dev.
Когда выполняется простой

composer install

устанавливаются и dev-зависимости.
Когда выполняется

composer install --no-dev

устанавливаются только те зависимости, что в основном блоке require.

Источник