<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Fsd on Kirill's homepage</title><link>https://kkucherenkov.github.io/tags/fsd/</link><description>Recent content in Fsd on Kirill's homepage</description><generator>Hugo</generator><language>ru</language><copyright>&lt;a href="https://creativecommons.org/licenses/by-nc/4.0/" target="_blank" rel="noopener"&gt;CC BY-NC 4.0&lt;/a&gt;</copyright><lastBuildDate>Tue, 14 Jul 2026 01:36:16 +0400</lastBuildDate><atom:link href="https://kkucherenkov.github.io/tags/fsd/index.xml" rel="self" type="application/rss+xml"/><item><title>Внедряем FSD в Nuxt 3: ручная конфигурация против nuxt-fsd</title><link>https://kkucherenkov.github.io/posts/fsd_nuxt3_migration/</link><pubDate>Tue, 14 Jul 2026 01:36:16 +0400</pubDate><guid>https://kkucherenkov.github.io/posts/fsd_nuxt3_migration/</guid><description>&lt;p&gt;В &lt;a href="https://kkucherenkov.github.io/posts/fsd_nuxt3_conflicts/"&gt;прошлом посте&lt;/a&gt; мы разобрали, почему Feature-Sliced Design конфликтует с конвенциями Nuxt 3 и как эти конфликты разрешаются конфигурацией. Остался главный практический вопрос: &lt;strong&gt;чем охранять архитектуру?&lt;/strong&gt; Правила, которые не проверяются автоматически, умирают за квартал — какой-нибудь спешный хотфикс импортнёт стор напрямую из внутренностей слайса, за ним второй, и через полгода от FSD останутся только названия папок.&lt;/p&gt;
&lt;p&gt;Инструмента два: &lt;strong&gt;ручная конфигурация + линтер Steiger&lt;/strong&gt; и &lt;strong&gt;Nuxt-модуль nuxt-fsd&lt;/strong&gt;. Я сравнил их по десяти критериям на реальном production-проекте на Nuxt 3 (Apollo/GraphQL, Pinia, Storybook, сотня с лишним компонентов). Спойлер: выиграла ручная конфигурация, но не всухую — и проигравшие критерии не менее интересны, чем выигранные.&lt;/p&gt;</description></item><item><title>Feature-Sliced Design и Nuxt 3: почему они конфликтуют</title><link>https://kkucherenkov.github.io/posts/fsd_nuxt3_conflicts/</link><pubDate>Tue, 14 Jul 2026 01:31:48 +0400</pubDate><guid>https://kkucherenkov.github.io/posts/fsd_nuxt3_conflicts/</guid><description>&lt;p&gt;Представьте фронтенд-проект на Nuxt 3, которому несколько лет: 58 composables в одной папке, 33 стора, 12 middleware и под сотню компонентов в &lt;code&gt;components/blocks/&lt;/code&gt;. Плоский список без семантической организации. Чтобы понять, куда положить новый composable, нужно сначала прочитать все существующие — иначе рискуешь продублировать. Новичок в команде обязан держать весь корень проекта в голове; вход растягивается на недели.&lt;/p&gt;
&lt;p&gt;Классический ответ на эту боль — &lt;strong&gt;Feature-Sliced Design (FSD)&lt;/strong&gt;: методология, которая режет фронтенд на слои и изолированные слайсы с явными публичными контрактами. Проблема в том, что Nuxt 3 построен на противоположной философии — и при попытке натянуть FSD на Nuxt они начинают конфликтовать в совершенно конкретных местах. В этом посте разберём, что FSD обещает, где именно Nuxt его ломает и как эти конфликты разрешаются. В следующем — сравним два способа внедрения: ручную конфигурацию с линтером Steiger и модуль nuxt-fsd.&lt;/p&gt;</description></item></channel></rss>