lnked

devDependencies — пакеты, которые нужны для разработки. Всякие галпы-гранты и плагины к ним обычно подпадают в эту категорию.
dependencies — пакеты, от которых ваш пакет зависит непосредственно: как правило — библиотеки.
Ставятся они все в node_modules.
Тут подробнее: https://toster.ru/answer?answer_id=559717#comments...

Если кто-то делает npm install вашему пакету, то npm подсосет те пакеты, которые указаны у него в dependencies, но не в devDependencies.
Если сделать npm install внутри папки, в которой есть package.json, то установятся и те, и другие.

1. Берёте любую понравившуюся CMS. Например, Joomla или Wordpress.
   
2. Разбираетесь какое-то время с архитектурой и основными понятиями - что такое компонент, модуль, плагин. У каждой CMS свой набор понятий, нужно просто привыкнуть.
   
3. Берёте урок по созданию шаблона с нуля с помощью Dummy Template (пример) или без него. И переносите свёрстанный на HTML+JS+CSS сайт в CMS
   

а он есть по тому пути по которому ты его пишешь? для того чтобы он работал он должен лежать в той же папке и что и твой css.

Что-то в этом роде:

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)\.html$ $1.php?%{QUERY_STRING} [L,R=301]

Можно сохранять номер ввиде числа, а при выборке форматировать его на стороне приложения.

В базе лучше всего хранить номера в международном формате, в виде 7XXXXXXXXXX (только цифры) в типе Decimal (если используется mysql). При таком подходе вы сможете сделать вывод номеров в любом месте вашего приложения в едином формате, а так же обеспечить корректный поиск и фильтрацию по номерам.

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

Требуете физического присутствия - признак потребности в компенсации посредством "ореола", это такое когнитивное искажение. Соответственно вы сами не знаете как обеспечить должное качество продукта и как правильно организовать работу, ищите человека который бы смог сделать большую часть работы в этом плане за вас, и обеспечить вас "обещаниями" или иллюзией выполнения каких либо задач. Вас просто будут постоянно кидать с таким отношением ...

В общем не тратьте своё и чужое время - есть слишком много примеров провальных проектов ещё до того как кто-либо начинал их реализовывать.

В списке того, что у вас есть, отсутствует бизнес-план.
С этим надо что-то делать.

Попробуйте использовать after с background-ом и свойство transform: skew
ну а родителю оверфлоу задайте

1. Наложение скриншотов макета и верстки
2. Корректная работа верстки во всех браузерах
3. Читабельный код (в 50% случаев - проверяют)

git chery-pick - ты забираешь комиты из одной ветки в другую, это бывает полезно когда изменения сделаные другим разработчиком в его ветке, прямо сейчас нужны тебе в твоей ветке, и что бы не писать этот код заново, ты забираешь его комит себе в ветку

git rebase master - ты синхронизируешься с главной веткой в которую коммитят все разработчики проекта, это полезно когда кто-то изменил участок кода с которым ты сейчас работаешь в своей ветке, дабы через неделю ты смог без проблем смержиться с master веткой. Обычно делается каждое утро перед началом рабочего дня и в конце когда фича готова.

git merge - обычно используется когда у вас 2 и более master ветки (к примеру master и prototype) в этих ветках очень много комитов (и rebase здесь не подходит) и обчно через пару недель, maintainer репозитория наработки из prototype ветки "сливает" в master ветку по средствам этого самого git merge

P.S. Что бы легче предствить разницу между git merge и git rebase. Представь что merge как собачка на молнии у одежды - "сшивает" комиты по дате их создания.
В то время как git rebase как пожарная лестница - при применении твои коммиты крепится на конец родительской ветки

git merge используйте для мержа фич и фиксов в master ветку (как и делает это Github)
а git rebase используется для своей ветку в которой вы работаете над фичей что бы забрать последние изменения с master ветку (для этого есть очень удобная команда `git pull --rebase origin master`, аналог 3х команд (`git checkout master; git pull origin master; git checkout mybrach; git rebase master`)

Сталкивался.
Только для PHP почти не решимая задача.
Написана была да же простенькая библиотечка, но при работе она намертво выжирала все ресурсы, поэтому переехал на VPS, а на нём уже с помощью ffmpeg делал всё, что нужно.
Как хранить данные - на Ваше усмотрение.

Всю игру оборачиваете в отдельную сущность.
Геттеры: кол-во размерностей игрового поля, размер соответствующей размерности, текущее состояние поля.
Методы: создание новой игры(массив размерностей), применить вектор движения(вектор)

Это всё что вам нужно. В итоге вы получаете не унылую игру в поле 4на4, а абстракцию над ней с возможностью игры в любом кол-ве размерностей.

UPD Ещё наверняка понадобится геттер состояния игры (игра продолжается или игра закончена)

UPD2 Получился банальный пример ответа на вопрос "Зачем линейка/математика программисту" :D

....
 WHERE `date` BETWEEN CURDATE() 
              AND DATE_ADD(CURDATE(), INTERVAL 7-WEEKDAY(CURDATE()) DAY)