Ivan Bogachev

Из описания вопроса не совсем понятно, какую именно логику следования стрелки за мышкой вы хотите получить (можно придумать разные варианты), но скорее всего вам нужно отталкиваться от логики вроде такой:

// Тут, конечно, лучше какие-нибудь id сделать для однозначности
const circle = document.querySelector('.circle');
const arrow = document.querySelector('.arrow');

document.addEventListener('mousemove', (e) => {    
    const circleRect = circle.getBoundingClientRect();
    const circleCenterX = circleRect.left + circle.offsetWidth / 2;
    const circleCenterY = circleRect.top + circle.offsetHeight / 2;
    const deltaX = e.clientX - circleCenterX;
    const deltaY = e.clientY - circleCenterY;
    const angleInRadians = Math.atan2(deltaY, deltaX) - Math.PI / 2;
    const angleInDegrees = 180 * angleInRadians / Math.PI;
    const angleFrom0To360 = (angleInDegrees + 360) % 360;
    const shouldEffectBeApplied = deltaY < 0;
    
    if (shouldEffectBeApplied) {
        arrow.style.transform = `rotate(${angleFrom0To360}deg)`;
    }
});

И еще в таких штуках всегда хорошо добавить какой-нибудь transition в CSS:

.arrow {
    transition: transform .1s linear;
}

У code review должна быть цель. В моей практике обычно проекты небольшие и там нет отдельных тестировщиков. Получается, что code review отвечает на три вопроса:

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

Получается что-то такое:

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

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

Имеете в виду что-то такое?

Что это за фреймворк?

Да не нужны там фреймворки. Нужна копипаста стилей для кучи почти одинаковых объектов (ее, наверное, можно сократить каким-нибудь хитрым миксином, но суть не поменяется):

Его заблокировали что ли?

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

В светлом будущем для решения этой задачи у нас будет :has. Но пока что о кроссбраузерности там речи не идет. В текущем состоянии CSS нет селектора, который бы позволил сделать тот же эффект. Но в контексте вашей задачи никто не мешает самим item сделать классы-модификаторы.

вписать изображения большего размера, что бы разметка не ломалась

Можно что-то такое сделать:

.inv-cell {
    position: relative;
}

img {
    position: absolute;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

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

console.log(new Number(1) + new Number(2)); // выводится 3 и typeof полученного значения number
То есть всё в порядке, это то же самое, как если бы мы сделали:
console.log(1 + 2);

Число - это Primitive. У примитивов есть эквивалентные объектные аналоги (кроме null и undefined). Поэтому да, это "то же самое" в каком-то смысле (у примитива нет методов, в отличии от эквивалентного объекта, они не могут быть изменены, и.т.д., но в таких простых расчетах мы не обращаем на это внимания). А штуки вроде упомянутых промисов, дат и что там еще бывает - это будут уже не примитивные типы данных, там такой двойственности уже нет.

В остальном - там есть немного синтаксического сахара, связанного с функциями и объектами. Например Object может быть создан разными способами, хотя фактически они приводят к одному результату, а не как у примитивов и их объектных оберток-аналогов.

На MDN говорят, что это вопрос безопасности (там только про Gecko, но можно предположить, что везде так). Если SVG используется как картинка, то в ней уже нельзя подгрузить другие внешние ресурсы. Как вариант можно использовать тег embed вместо img, и все будет работать без таких ограничений.

Смешались в кучу кони, люди, GSAP, React, Three.js... Стоит немного систематизировать инструменты хотя бы по задачам, которые они решают. Не привязываясь к конкретным фреймворкам из большой троицы, у нас есть несколько классов инструментов в теме креативных сайтов:

• Про готовые CSS-анимации - animate.css, Wow.js, и.т.д. Там много динозавров из времен jQuery. Такие штуки часто бывают не в тему дизайна, но стоит посмотреть и забыть. Хотя для сайтов в духе дизайнерской дичи, вроде той, что успешно делают в студии Артемия Лебедева - может быть и ок.
  
• Про интерполяцию всего и вся. Тут обычно выбирают между GSAP и Anime.js. Первый вариант - более замороченный, есть полезные плагины, второй - попроще, но тоже хорош, в некоторых кругах даже более популярен. Для совсем простых задач - можно свой инструмент написать.
  
• Про скролл, в основном в контексте CSS-анимаций. Тут Locomotive Scroll рулит.
  
• Про переходы между экранами. Грубо говоря прокаченный роутер. Самый популярный - Barba.js. Раньше еще был Highway.js, но в последне время что-то про него мало говорят.
  
• Про экспорт готовых анимаций из софта для анимаций. Тут нужно отталкиваться от софта. Обычно вопрос возникает в контексте AE и простых мультиков - тут Lottie, говорят, неплох. Но нужно дизайнера заранее консультировать по теме, чтобы лишнего не намалевал.
  
• Про визуализацию данных. Тут полезно знать про d3.js, в основном ради готовых примеров.
  
• Про трехмерный WebGL, чтобы не писать все руками. Самый популярный вариант - Three.js, в основном за счет экосистемы и горы готовых решений, но есть и альтернативы на любой кус и цвет. Для 2D -эффектов вообще ничего не нужно в большинстве случаев.
  
• Плюс не стоит забывать про всякие вспомогательные штуки вроде WebFontLoader, Hammer.js, LeaderLine, и.т.д. К анимациям они не относятся, но в работе могут быть полезны, чтобы не писать все самому.
  

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

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

Пытаюсь установить tailwind... при компиляции получается файл, в котором нет всех стилей tailwind... делаю всё четко по инструкции...

Если ошибок при сборке никаких нет (вы про них ничего не говорите), и вы делаете все по инструкции, то возможно стоит ее еще раз прочитать. Эта самая инструкция начинается со слов:

Tailwind CSS works by scanning all of your HTML files, JavaScript components, and any other templates for class names, generating the corresponding styles and then writing them to a static CSS file.

Если вы все делаете по ней, то по идее вы как раз и должны получать минимальный файл, в котором будут только те стили, которые у вас в проекте нужны, а не вообще все, что там в теории могут быть сгенерированы. По вопросу кажется, что все работает именно так, как и должно.

Нужно чтобы форма была по центру

Тогда может быть align-self: center; должно быть у самой формы?