Максим Морев

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

Если у вас внешний пакет (иначе непонятно, причём тут `main` в `package.json`), и вам нужно сделать экспорт конкретного файла по "короткому" пути, то следует оформить так:

// package.json вашего пакета, допустим, "mypackage"

{
  "name": "mypackage",
  "exports": {
    ".": "./dist/index.js",
    "./whatever/": "./dist/whatever/non-index.js"
  } 
}

Важно: это минимальная версия, там есть тонкости относительно разного экспорта ESM, CJS и d.ts файлов, но тут такой вопрос не стоит.

Если у вас есть такой пакет, то в другом пакете, в который вы установили его как зависимость, вы можете импортировать по "короткому" пути:

// "Короткий" импорт, без него пришлось бы делать что-то вот такое:
// import { whatever } from 'mypackage/dist/whatever/non-index.js';

import { whatever } from 'mypackage/whatever';

---

Если речь идёт о том, чтобы использовать алиасы внутри одного проекта, то следует сконфигурировать алиасы в `vite.config.ts`, документация вот здесь, выглядеть будет примерно так:

// vite.config.ts

import { fileURLToPath, URL } from 'node:url';

export default defineConfig({
  resolve: {
    alias: [
      { find: '~components', replacement: fileURLToPath(new URL('./src/components', import.meta.url)) },
    ],
}),

И в `(js|ts)config.json`, при наличии, добавить:

{
  "compilerOptions": {
    "paths": {
      "~components/*": ["./src/components/*"]
    }
  }
}

Нарисовать надо по пиксельной сетке, иллюстрирую:


Если дизайнер изначально об этом не думал, когда рисовал (точки поставлены наобум, либо используется не целочисленная величина обводки) - вы с этим ничего не сделаете.

На экранах повышенной плотности, к слову, эффект менее заметен (что не особо радует всех остальных).

Вот здесь отвечал на аналогичный вопрос, проблема та же. :)

Не вижу в репозитории какой-то сборки, поэтому подсвечу на картинке:



Вам нужно сконфигурировать сборку таким образом, чтобы либо для подключения файлов использовались относительные пути, либо нужно добавить к путям префикс с названием репозитория, либо, в крайнем случае, воспользоваться тегом <base href="..." /> (не очень помню, влияет ли он на абсолютные урлы, но если влияет, то это поможет).

Автор Pinia вот в этом issue отвечал на вопрос, с тех пор ничего не изменилось :)

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

Наиболее близкая демка:
https://tympanus.net/Development/webGLImageTransit...

Сама статья:
https://tympanus.net/codrops/2019/11/05/creative-w...

Вам не нужна интерполяция при математических операциях внутри SASS:
transform: rotate($i * 6deg); и всё будет работать.

Интерполяция будет нужна, если вы будете работать с CSS функциями, например, с calc():
left: calc(#{$i}px + 10%);

Фреймворк за счёт внутренних оптимизаций может работать быстрее, чем плохо написанный ванильный код.
Хотя даже это по большей части работает на синтетических примерах.

Самый наивный из них:
Например, вам надо добавить 10 000 узлов в DOM.
Плохо написанный код будет выглядеть как цикл, на каждой итерации которого вы будете обращаться к DOM API, добавляя элемент.
Хорошо написанный код (как и код, который сгенерирует фреймворк, вероятнее всего) в цикле соберёт всё необходимое и по окончании одним запросом к DOM API вставит на страницу.

Задача на текущий момент не решается на чистом CSS.
Можете вот это решение попробовать, либо попробовать нагуглить что-то другое по запросу "affix sidebar".

^(.*?)[-| ]\d

Жму руку дизайнеру, молодец, не как у всех.

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

Изначально я не обратил внимания, что нижний край строго горизонтальный, и накидал такое как стартовую точку



Но когда заметил - понял, что так в принципе не выйдет сделать, на CSS нельзя "зафиксировать от трансформации" две стороны сразу.

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

Делать лень, это нетрудно :)

Тут нужна преамбула:

Stable он стал исключительно потому, что это событие надо было приурочить к конференции "Nuxt Nation" (в общем-то, с этого коммита они начали конференцию), потому что, во-первых, это красиво и всего раз в году, а во-вторых, это важно с точки зрения маркетинга - Эван Ю, например, получил возможность этим фактом бравировать.

По факту же, последний Release Candidate в шапке описания содержит сообщение "1 or 2 additional release candidates are expected before the final 3.0.0 version" (причём в моей памяти оно отложилось как "few more release candidates" - может, отредактировано, а может, я неправильно запомнил).
Как бы то ни было, планировалось 2 релиза до стабильной версии. Но через 2 недели случился Nuxt Nation. Осталось два релиза до стабильной версии :)

С начала декабря висит черновик MR с релизом 3.1.0, в котором было написано, что он будет готов в декабре. Сейчас там написано, что он будет готов в январе (в подтверждение того, что описания таки редактируются).
Это всё к тому, что релизный цикл ненадёжный и скорее ситуативный. Вот ишью, в котором вопрос поднимается. С учётом того, что и публичную бету отложили на полгода, и стабильный релиз на тот же срок (и ещё больше), а также потому, что на момент релиза было 400 ишью, сейчас - почти 600, я укрепляюсь во мнении, что они замахнулись на слишком многое сразу, имея команду в 3 человека. Причём приоритетность задач... Ну, я особо не сталкерил за контрибьюторами, но осталось ощущение, что в первую очередь делается то, что интересно, а не то, что у людей больше всего болит.
И тем не менее, они фанаты и многое успевают :)

---

К сути вопроса - если вы делаете что-то с нуля, то можно попробовать. Даже нужно, ибо год спустя большая часть проблем решится, а цикл разработки он примерно такой и есть. Главное - помечать костыли и подпорки :)

У меня в продакшене проектов на Nuxt 3 нет, но есть пара в активной разработке.
Вы помучаетесь с настройкой прокси для запросов (потому что встроенной функциональности ждём уже почти год) (но там можно подпереть и заработает). Там будут ещё проблемы, особенно под Windows и если вам нужны свои модули, но это запомнилось больше всего. Но ничего нерешаемого пока нет.

Если же вы хотите мигрировать существующий проект...
По моим ощущениям, у Nuxt 3 большие проблемы с определением места, где что-то пошло не так.
Вам, скорее всего, придётся мигрировать довольно маленькими кусочками и проверять, не сломалось ли чего, потому что если сломалось где-то в большом куске кода, вы почти наверняка получите ошибку в духе "500. Что-то не работает, а где - не покажу".
Короче, это будет "написание с нуля, копируя кусочки из предыдущего релиза на Nuxt 2".

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

В целом, после перехода удобство разработки значительно повысилось, во многом из-за TS без костылей (ну, почти, я очень надеюсь что в обозримом будущем вот это закроется. Хотя Эван обещал это релизить в ноябре... Все факапят сроки :) ).
Сборка побыстрее примерно вдвое, hot reload весьма значительно быстрее (почти мгновенно до сих пор, хотя видна тенденция к замедлению. В любом случае 20-30x прирост по сравнение с Nuxt 2).
Клиентский перфоманс, кстати, опираясь на попугаи PageSpeed, возрастает примерно так, что там, где на Nuxt 2 было 60, тут станет 80. Я не копал пока глубоко в клиентскую оптимизацию на Nuxt 3, наверняка там можно что-то выдумать, но по первым впечатлениям вот так - побыстрее, но чуда не случилось, фреймворк всё ещё имеет существенный оверхэд по сравнению с чем-то более нативным.

Скорее всего, не указан ключ base в конфигурации и ресурсы пытаются загрузиться с адреса username.github.io/assets/... вместо username.github.io/package-name/assets/....

Вот тут пример того, как правильно.
Или поможет это, или давайте ссылку на репозиторий :)

const str = '111,222;333 444';
[...str.matchAll(/\d+/g)].map(i => i[0]);