DEV Community: Max Core

SvelteKit 2: Code-based router instead of file-based router now is just a Gist!

Max Core — Sun, 19 Apr 2026 19:57:11 +0000

The idea is simple — just create universal [...path] folder and proxy everything through it specifying patterns in some urls.ts.

So, we have to create minimal and universal +page.js and +page.server.js with load functions, find there 'pattern' in urls.ts by url.pathname we know in load, set some routeStore, containing desired page, and get it in +page.svelte.

It's kinda tricky, so we also need copy router.ts from here:
https://github.com/webentlib/gists/blob/main/router.ts

Further message — just a copy of router.md.

Please, let me know what do u think.
Please share if you use something similar.

Minimal Example:

urls.ts:

const layout = {page: () => import('/src/base.svelte')};
export const patterns = [
    {path: '',                   page: () => import('/src/home.svelte'),        layouts: [layout]},
    {path: 'users',              page: () => import('/src/users/users.svelte'), layouts: [layout]},
    {path: 'users/(<id>[0-9]+)', page: () => import('/src/users/user.svelte'),  layouts: [layout]},
]

users.svelte

<script module>
    export async function load() {
        return {
            users: [...]
        }
    }
</script>
<script>
    let { data } = $props();
    ...
</script>

Installation:

1) Download router.ts to some folder all external gists live, e.g.: /lab/.

2) Move routes/ folder wherever you like, create [...path] folder inside.

3) Create 4 files:

[...path]/+page.ts:

import {Router} from '/lab/router.ts';
export async function load(params) {
    return await Router.route(params)
}

[...path]/+page.server.ts:

import {Router} from '/lab/router.ts';
export async function load(params) {
    return await Router.route(params, true)
}

[...path]/+page.svelte:

<script>
    import { routeStore } from '/lab/router.ts';
    const { data } = $props();
</script>
{#snippet draw(routeStore, index)}
    {@const Layout = routeStore.layouts[index]}
    {@const Page = routeStore.page}
    {#if routeStore.layouts.length && index < routeStore.layouts.length}
        <Layout {data}>
            {@render draw(routeStore, index + 1)}
        </Layout>
    {:else}
        <Page {data}/>
    {/if}
{/snippet}
{@render draw($routeStore, 0)}

+error.svelte (note — must be in routes/, not [...path]):

<script lang="ts">
    import { page } from '$app/state';
    import { Router } from '/lab/router.ts';
</script>
{#await Router.error(page.url.pathname) then Error}
    {#if !Error}
        <h1>{page.error.message}</h1>
    {:else}
        <Error/>
    {/if}
{/await}

4) Create urls in root (same level with package.json):

urls.ts:

const layout = {page: () => import('/src/base.svelte')};
export const patterns = [
    {path: '', page: () => import('/src/home.svelte'), layouts: [layout]},
    // {path: 'users/(<id>[0-9]+)', page: () => import('/src/users/user.svelte'), layouts: [layout]},
]

5) Create sample pages in /src/:

base.svelte:

<script>
    let { children } = $props();
</script>
{@render children?.()}

home.svelte:

Hello, world!

6) Point svelte to routes folder you want it to be in:

svelte.config.ts:

kit: {
    ...
    files: {
        routes: 'routes/',
    },
}

7) Allow vite look files in root:

vite.config.ts:

export default defineConfig({
    ...
    server: {
        fs: {
            allow: ['..'],  // Allow serving files from one level up to the project root
        },
    }
});

Extended Example:

urls.ts:

import type { Pattern, Layout, Error } from '/lab/router.ts';

const error: Error = {page: () => import('/src/error.svelte')};
const layout: Layout = {page: () => import('/src/base.svelte'), error: error};
const account: Layout = {page: () => import('/src/account.svelte')};

export const patterns: Pattern[] = [
    {path: '',                   page: () => import('/src/home.svelte'),          layouts: [layout], title: 'Home', h1: 'Welcome'},
    {path: 'users',              page: () => import('/src/users/users.svelte'),   layouts: [layout], name: 'users'},
    {path: 'users/(<id>[0-9]+)', page: () => import('/src/users/user.svelte'),    layouts: [layout]},
    {path: 'friends',            page: () => import('/src/users/users.svelte'),   layouts: [layout, account], name: 'friends'},
    {path: 'settings',           page: () => import('/src/users/account.svelte'), layouts: [layout, account]},
]

Yes. One can specify:
1) Layout array for any page.
2) For sure multiple patterns can point to same page like users and friends in example in case same template but different data.
3) Custom error for any page or layout.
error.svelte:

<script lang="ts">
    import { page } from '$app/state';
</script>
<h1>{page.status}</h1>
<div>{page.error.message}</div>

4) Pattern and Layout has universal and server properties to point to load function in separate file:

    {path: '', universal: () => import('/src/home.server.js'), server: () => import('/src/home.js'), ...},

5) Add any custom attributes like title, h1, name to be used later in layout/page.
base.svelte:

<script>
    import { routeStore } from '/lab/router.ts';
    let { children } = $props();
</script>

{#if $routeStore.pattern.h1}
    <h1>{$routeStore.pattern.h1}</h1>
{/if}

{@render children?.()}

If one prefer both server and universal to be in <script module>:

user.svelte:

<script module>
    import { get } from 'svelte/store';
    import { routeStore } from '/lab/router.ts';
    export async function server() {  // in <script module> could be named only server
        const user_id = get(routeStore).slugs.id;
        ...
    }
    export async function universal() {  // could be named load
        const user_id = get(routeStore).slugs.id;
        ...
    }
</script>

Downsides:

1) Both +page.server.js and +page.js runs on every rote. No way to say 'call only +page.js'.

2) export const snapshot = {...} not working.

3) No pragmatic way to specify options like export let ssr = true; probably one can do it like (not tested):
urls.ts:

{path: '', ..., options: { ssr: true }},

+page.server.ts:

import {Router} from '/lab/router.ts';

export let prerender = false;
export let entries = () => [];
export let ssr = true;
export let csr = true;
export let trailingSlash = 'never';
export let config = {};

export async function load(params) {
    const pattern = Router.findPattern(params.url.pathname);
    for (const [k, v] of Object.entries(pattern?.options || {})) {
        eval(`${k} = ${v}`);
    }
    return await Router.route(params, true)
}

Same for +page.ts but return await Router.route(params, true) must be return await Router.route(params) there.

P.S.

That router is TS only, and was written with next tsconfig:

tsconfig.json:

"rewriteRelativeImportExtensions": false,
"allowImportingTsExtensions": true,
"paths": {
    "/*": ["*"]
},
"noImplicitAny": false,

Svelte: Best practice to combine $derived and $state

Max Core — Sat, 04 Oct 2025 12:33:06 +0000

First approximation:

let { data } = $props();
let posts = $derived.by(() => {
    let posts = $state(data.posts);
    return posts;
});

It is not documented, and me personally obtained it here:
https://discord.com/channels/457912077277855764/1406193849423888415/1406241130726690837
From mjadobson, approved by Patrick.

Others advice, for semantics and linters, that let better be const:

let posts = $derived.by(() => {
    const posts = $state(data.posts);
    return posts;
});

Performance may depend on an engine.

Another way to make it one line:

let posts = $derived.by(() => { const _ = $state(data.posts); return _ });

And now, while copy-paste, there are 2 places left to change, not 4.

For sure, it COULD NOT be:

let posts = $derived.by(() => $state(data.posts));

Since:

$state(...) can only be used as a variable declaration initializer, a class field declaration, or the first assignment to a class field at the top level of the constructor.

Probably it'll be nice to have $reactive rune one day, combining both or something

If one have more elegant solution — please share
Thx

Базовый ультимативный гайд по Nginx

Max Core — Sat, 30 Dec 2023 17:24:34 +0000

Ниже — две части.

База — её можно быстро пролистать.
Боевая имплементация — там то, что мы хотим на практике.

Важно учесть, что настройка Nginx — не только для "наших" задач.
Все наши фреймворки, их middleware и т.д. — тоже рассчитывают на достоверные заголовки. Для корректной работы их autoban и т.д.

База. Зачем нужен Nginx. Логика `X-Forwarded-For`.

Тестировать будем на starlette.

Создадим простой main.py, который просто рисует http-мету:

from starlette.applications import Starlette
from starlette.responses import HTMLResponse
from starlette.routing import Route

async def home(request):
    return HTMLResponse(f"""<pre>
        url: {str(request.url)}
        client:
            host: {request.client.host}
            port: {request.client.port}
        headers:
            {('<br>' + '&nbsp' * 12).join(k + ': ' + v for k, v in request.headers.items())}
    </pre>""")

app = Starlette(debug=True, routes=[Route('/', home),])

Его можно запустить на сервере:

uvicorn main:app --host=0.0.0.0 --port=2100

И, если DNS настроены:

Его уже можно открыть в браузере по http://myproject.org:2100
Он уже будет знать:
- IP-пользователя в request.client.host вида 'xxx.xxx.xxx.xxx'.
- Host-Cервера в request.headers.host вида 'myproject.org:2100'.
Даже ssl/https можно прикрутить.

И если обращаться к серверу прям так — http://myproject.org:2100 — без прокси, без VPN-ов — как минимум с заголовками — всё будет нормально.

Но:

Возможно — нам бы хотелось иметь возможность как-то знать о прокси/VPN-ах.
Возможно — нам также хотелось бы — мапить/перемапливать урлы (чтобы по 'myproject.org/api/' открывалось 'api.org/take/some/api/dude/'); эффективней обслуживать статику (не приложением); контролировать — таймауты, размеры файловых аплоудов, размеры текстовых аплоудов; иметь возможность показать пользователю хоть что-то, пока сервер лежит/перезапускается; клёвое логирование и т.д. и т.п.

А главное что нам хотелось бы — делать всё это через одну привычную технологию, на чём бы мы не писали наше приложение.

Nginx

Сэмулируем проксирование самих себя (может это мы сами для наших нужд):

server {
    listen 2200;
    location / {
        proxy_pass http://myproject.org:2100;
    }
}

Открываем браузер по http://myproject.org:2200.
В request.client.host лежит уже не IP-Пользователя, а IP-Cервера, который к нам обратился.
Скажем сразу — если доступа к этому конфигу у нас нет — многого мы не сделаем.

Но, можем отловить "чуть более верхнего инициатора запроса" добавив "подконтрольный" нам конфиг:

server {
    listen 2100;
    location / {
        proxy_pass http://myproject.org:2000;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Запускаемся (но уже с портом 2000):

uvicorn main:app --host=0.0.0.0 --port=2000

Открываем браузер также по http://myproject.org:2200.
Теперь наш сервис дополнительно отображает нам некий request.headers['x-real-ip'] с IP отличающимся от request.client.host.
И если в request.client.host у нас IP-Сервера, то в request.headers['x-real-ip'] похоже IP-Роутера-Сервера. (Но это не важно).

А вот если бы тот первый конфиг был нам подконтролен (или просто настроен хорошо), то мы могли бы в обоих случаях добавить:

server {
    listen 2200;
    location / {
        proxy_pass http://myproject.org:2100;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # +
        proxy_set_header Host $http_host;  # +
    }
}

server {
    listen 2100;
    location / {
        proxy_pass http://myproject.org:2000;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # +
        proxy_set_header Host $http_host;  # +
    }
}

И теперь, в http://myproject.org:2200 мы получим:

В request.headers.host лежит всё как надо — 'myproject.com:2200'.
В request.client.host всё также лежит IP-Сервера.
В request.headers['x-real-ip'] лежит всё тот же IP-Роутера-Сервера.
Но, появился ещё request.headers['x-forwarded-for'], и это — цепочка IP-шников! Потерянный IP-Пользователя и IP-Роутера-Сервера.

Т.е., самый достоверный IP-пользователя — это всегда — request.headers['x-forwarded-for'][0].

Боевая имплементация

Нам конечно не нужны такие двойные конфиги.
Просто только так можно было понять 'X-Forwarded-For'.
Что и в какой степени достоверно.

И вот перед нами просто "голый" конфиг:

server {
    listen 2200;
    location / {
        proxy_pass http://headhall.com:2000;
    }
}

По http://myproject.org:2200 мы получим:
Который показывает:

В request.headers.host лежит 'myproject.org:2000', хотя браузер открыт с ':2200'.
В request.client.host — IP-Сервера, а не IP-Пользователя.
request.headers['x-real-ip'] вообще нет.
request.headers['x-forwarded-for'] также нет.

Приводим конфиг в боевое состояние:

server {
    listen 2200;
    location / {
        # Чтобы показывал :2200
        proxy_set_header Host $http_host;

        # Пытаемся получить IP-Пользователя (и получим, если без прокси)
        proxy_set_header X-Real-IP $remote_addr;

        # Ещё пытаемся получить IP-Пользователя (и получим, если прокси наше или "нормальное")
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass http://headhall.com:2000;
    }
}

(Вместо $http_host конечно можно — и $host (без порта), и $server_name (если хочется) и т.д. Просто $http_host самый полный и универсальный.).
(К слову, все эти proxy_* можно указать и на уровне server).

Закрепим, что мы получим в http://myproject.org:2200:

В request.headers.host лежит гарантированный 'myproject.org:2200'.
В request.client.host — IP-Сервера, а не IP-Пользователя, как можно было ожидать — всегда НЕ надёжный ориентир.
request.headers['x-real-ip'] — IP-Пользователя, но, всё же — тоже НЕ надёжный ориентир.
request.headers['x-forwarded-for'][0] — IP-Пользователя, как — наиболее надёжный ориентир.

А вот теперь можно уже к — таймаутам, лимиту аплоудов и т.д.

В помощь по всему что выше:
Alphabetical index of variables: https://nginx.org/en/docs/varindex.html
Злой, но золотой комментарий на SO: https://stackoverflow.com/a/72586833/4117781

Удачи, авантюрист!

Базовый ультимативный гайд по событиям в JavaScript (на примере SvelteKit)

Max Core — Tue, 14 Nov 2023 19:10:21 +0000

addEventListener? removeEventListener? useCapture? capture?
click? mousedown? mouseup? touchstart? touchend?
touchcancel? dragleave?
stopPropogation? bubbling? capturing?
mouseenter? mouseleave? mouseover? mouseout?

Был такой случай

Выхожу из подъезда, передо мной бабушка.
Делает шаг в сторону со словами: «Молодым везде дорога!».
Я поблагодарил и вышел первым.
Думаю — «Ну наконец-то — хоть одно нормальное правило.» :D

Забавно, что, по-умолчанию — именно так и работают события в JavaScript.

По умолчанию — все действия Прогрессивные — сначала проходит Потомок, потом Родитель.

<div on:click={() => alert('Родитель проходит вторым')}>
    <button on:click={() => alert('Потомок проходит первым')}>
        Молодым везде дорога
    </button>
    <div>Да, согласна — молодым везде дорога</div>
</div>

Есть только 1 способ начать пропускать старших:

Родитель должен высказать Консервативное мнение (capture):

<div on:click|capture={() => alert('Родитель проходит первым')}>
    <div>Нам — старикам — почёт в любом случае.</div>
    <button on:click={() => alert('Потомок проходит вторым')}>
        Молодым везде дорога же, не?
    </button>
</div>

Если Родитель высказал Консервативное мнение — никакое Мнение Потомка не интересно.
В этом вся логика.

Логика событий

Браузер всегда проводит 2 слушания по определённому событию (click в нашем случае): Сначала — все Консервативные мнения (capturing, события с capture). Потом — все Прогрессивные (bubbling, обычные события без capture).
И, в каждом слушании начинает с мнения Родителя.

И, если Родитель высказал Консервативное мнение,
вот такое Консервативное мнение Потомка — не имеет смысла:

<div on:click|capture={() => alert('Родитель проходит первым')}>
    <div>Нам — старикам — почёт в любом случае.</div>
    <button on:click|capture={() => alert('Потомок проходит вторым')}>
        Да, согласен — старикам у нас почёт
    </button>
</div>

Также, не имеет смысла Потомку высказывать Консервативное мнение если Родитель другого мнения:

<div on:click={() => alert('Родитель проходит вторым')}>
    <button on:click|capture={() => alert('Потомок проходит первым')}>
        Старикам у нас почёт
    </button>
    <div>Ты поучи жену щи варить, я принял Прогрессивное решение</div>
</div>

Потому что, если Потомок выскажет Консервативное мнение — в этом также не будет смысла,
потому что у Родителя — нет Консервативного мнения.
Значит — он не хочет идти вперёд.

JavaScript это не жизнь. Здесь возможны 2-е параллельные вселенные:

<div on:click|capture={() => alert('C1')} on:click={() => alert('4')}>
    <button on:click|capture={() => alert('2')} on:click={() => alert('3')}>
        Кнопка
    </button>
</div>

Именно поэтому, когда мы навешиваем:
addEventListener(process)
То удаляем мы его вот так:
removeEventListener(process)
А когда мы навешиваем:
addEventListener(process, true)
То и удаляем мы его вот так:
removeEventListener(process, true)

И, без разницы где и как именно указывать — true или {capture: true}.
К слову removeEventListener не будет работать, если событие навешено через html-атрибут (onclick="..."), даже если «перенавесить» через addEventListener.

Но, у нас есть не только `click`, есть и `mousedown`, `mouseup` и т.д.

Они тоже имеют свой порядок.
Сначала отработают вообще все mousedown на странице, потом mouseup, и только потом click.

<div
    on:mousedown|capture={() => console.log('D1')} on:mousedown={() => console.log('D4')}
    on:mouseup|capture={() => console.log('U1')} on:mouseup={() => console.log('U4')}
    on:click|capture={() => console.log('C1')} on:click={() => console.log('C4')}
>
    <button
        on:mousedown|capture={() => console.log('D2')} on:mousedown={() => console.log('D3')}
        on:mouseup|capture={() => console.log('U2')} on:mouseup={() => console.log('U3')}
        on:click|capture={() => console.log('C2')} on:click={() => console.log('C3')}
    >
        Кнопка
    </button>
</div>

Выведет:
> D1, D2, D3, D4, U1, U2, U3, U4, C1, C2, C3, C4

Где посмотреть достоверный список приоритетов — не знаю.

`e.stopPropagation`

Без него можно обойтись.
В «моём кодстайле» его использовать запрещено в пользу игры с переменными is_el_doing_smth.
Но, во имя науки:

(П — Прогрессивное; К — Консервативное)

<div on:mouseup|capture={() => console.log('К1')}
     on:mouseup={() => console.log('П3')}>
    <div on:mouseup|capture|stopPropagation={() => console.log('К2')}
         on:mouseup|stopPropagation={() => console.log('П2')}>
        <div on:mouseup|capture={() => console.log('К3')}
             on:mouseup={() => console.log('П1')}>
            Поехали
        </div>
    </div>
</div>

Выведет:

K1, K2

Т.е. stopPropagation навешанный на событие с capture заблокировало все будущие mouseup — и с capture и без него.
Таким образом, что stopPropagation, навешанный на событие без capture уже не имеет смысла.
Однако, это никак не повлияет, если на эти же элементы навесить событие, которое вызывается позже, к примеру click.

Если убрать все stopPropagation, выведет:

К1, К2, К3, П1, П2, П3

`e.preventDefault`

Про него вы всё сами знаете, но, есть один момент:

<button
    on:touchstart={(e) => e.preventDefault()}
    on:click={() => alert('Алерт, который НЕ отработает на телефоне')}
>
    Кнопка 1
</button>

<button
    on:touchmove={(e) => e.preventDefault()}
    on:click={() => alert('Алерт, который отработает везде')}
>
    Кнопка 2
</button>

Подробнее:
https://developer.mozilla.org/en-US/docs/Web/API/Touch_events

Чем отличаются `mousedown`, `mouseup` и `click`?

mousedown — нам не важно где был курсор когда мы нажали мышку, важно что отпустили его мы именно на этом элементе.
mouseup — нам не важно где мы отпустим мышку, главное, что нажата она была именно тут.
click — нажали, поводили хоть по всему экрану, вернулись на элемент, отпустили — и вот тогда это клик.

Т.е. click — мы могли бы реализовать сами.
Что, кстати, бывает очень нужно для реализации некого click-outside (будет в другой статье).
Потому что — пусть click — это mousedown и mouseup внутри одного элемента, он при этом не понимаем на каком именно элементе мы нажали, а на каком отпустили.
Есть конечно всякие e.target, e.currentTarget, e.relatedTarget, e.originalTarget и т.д.
Но, половина из них не работает для click, а вторая половина не везде поддерживается (всё это без меня).

Из того, что работает одинаково для всех событий:
e.currentTarget — это элемент на котором висит само событие, а
e.target — это первый самый далёко-вложенных Потомок внутри этого элемента.

click работает и на компе и на телефоне, т.е. никакого события touch на телефоне не существует.

Но, на телефоне:
mousedown — это — touchstart
mouseup — это — touchend
К слову:
mousemove — это — touchmove

Есть ещё mouseleave, когда курсор покидает элемент.
Но на телефоне — нет курсора.
Однако, на телефоне, мы можем нажать и вести, и тогда mouseleave мог бы пригодиться.
Но, это событие решили не реализовывать.
Вместо этого, сделали так, что когда мы ведём пальцем за пределы экрана (не браузера) — выбрасывается touchend.
Но, если хочется выбрасывать событие, когда мы вышли за пределы элемента, то можно это сделать так:

<script>
    let el;
</script>
<div style="height:100px;background:#f00;"
     on:touchstart={(e) => el = e.currentTarget}
     on:touchmove={(e) => {
         const {pageX, pageY} = e.touches[0];
         const realElement = document.elementFromPoint(pageX, pageY)
         if (realElement !== el) {
             alert('touchleave')
         }
     }}>
</div>

Есть ещё touchcancel, призванный обработать конфликты нажатия несколькими пальцами, но не работает в Safari, пэтому не используем.
Есть ещё dragleave, но это не ведение пальце, а именно перетаскивание элемента (картинки).

К слову, чем отличается mouseenter+mouseleave от mouseover+mouseout:

<div data-name="Дом" style="height:100px;background:#f00;"
     on:mouseenter={(e) => {console.log('вОшли Дом')}}
     on:mouseleave={(e) => {console.log('вЫшли Дома')}}
     on:mouseover={(e) => {console.log('перешли В Дом или Комнату')}}
     on:mouseout={(e) => {console.log('перешли ИЗ Дома или Комнаты')}}
>
    Каждый раз когда мы заходим в Дом — вызывается `mouseenter`.<br>
    Каждый раз когда мы выходим из Дома — вызывается `mouseleave`.
    <pre data-name="Комната" style="height:100px;width:50%;margin-left:50%;background:#000;">
        Каждый раз когда курсор пересекает границу этой Комнаты внутри Дома:<br>
            вызываются и mouseout и mouseover (именно в таком порядке).
    </pre>
</div>

Иии, внииимаааниииеее...

Спасибо, за внимание.

Базовый ультимативный гайд по Node.js (на примере SvelteKit)

Max Core — Sat, 11 Nov 2023 09:56:38 +0000

dependencies? devDependencies? peerDependencies?
npm install? npm i? npm ci?
--save? --save-dev? --save-prod? -g?
package.json? package-lock.json? .npmrc?
"module": "^1.0.0"?
"module": "~1.0.0"?
"module": "1.0.0"?
Что из этого можно править руками?
Что из этого в Гит?
Какой командой в итоге билдить?

Актуально для: node -v — v20.5.0 и npm -v — 10.2.3

Что предлагает Svelte на старте?

(После npm create svelte@latest my-app)

В package-lock.json только devDependencies (без prod-dependencies):

И все эти зависимости «из коробки» НЕ строгие, т.е. с ^:

```
"devDependencies": {
    "@sveltejs/adapter-auto": "^2.0.0",
    "@sveltejs/kit": "^1.20.4",
    "svelte": "^4.0.5",
    "vite": "^4.4.2"
}, 
```

.npmrc (NPM Run Command) с единственной строкой engine-strict=true.

P.S. package-lock.json нет вообще (и не надо).

Что рекомендуют разработчики Svelte?

Определиться с адаптером, вместо adapter-auto.

It's recommended to install the appropriate adapter to your devDependencies once you've settled on a target environment, since this will add the adapter to your lockfile and slightly improve install times on CI.
https://kit.svelte.dev/docs/adapter-auto

Мы люди простые, — возьмём универсальный adapter-node.
Итак,

Как установить новый модуль?

https://docs.npmjs.com/cli/v10/commands/npm-install

По умолчанию, npm install @sveltejs/adapter-node — запишет в prod-dependencies.
Потом, можно перекинуть в devDependencies путём:
npm install @sveltejs/adapter-auto --save-dev.
Но, снова вернуть в «prod» той же командой:
npm install @sveltejs/adapter-auto уже не получится.
Чтобы форсануть обратно в «prod»:
npm install @sveltejs/adapter-auto --save-prod

npm install @sveltejs/adapter-auto --save — такого просто нет (как минимум в npm v10)
Но нода не ругается на несуществующие параметры.
Более того, ей без разницы — что так: npm install module-name --param, что так: npm install --param module-name.
А вообще можно и просто npm i module-name.
Можно и npm i module_name -g, если модуль нужен не для проекта, а как консольная утилита для чего-нибудь.

Но это не то, что нам нужно.
Мы знаем, чем оборачивается «НЕ строгая версия».

Как установить строгую версию?

Есть 4 способа:

npm config set save-exact true

Сомнительно, т.к. делает запись где-то глобально, и только на локальной машине.

P.S.
Создаётся на самом деле 2-е переменные в npm config list:
save-exact = true
save-prefix = ""

Если вернуть обратно (npm config set save-exact true), будет:
save-exact = false
save-prefix = "^"
npm install @sveltejs/adapter-auto --save-exact

Делает свою работу, но нам нужна защита от дурака, на всю команду.
Добавить в .npmrc >> save-exact=true.

Т.е., теперь, когда мы делаем npm i module-name он автоматически будет устанавливать строгую версию, без ^.
(Тут, никаких save-prefix = "" не надо, это была внутренняя штука для глобального конфига.)

Можно руками постирать все ^, но — тогда у нас окажутся устаревшие пакеты :D.

То, что было вначале пришло в devDependencies — не совсем свежее.
Но, пока мы ещё ничего не установили, у нас нет ни node_modules/, ни package-lock.json — нам ничего не мешает действительно всё прописать руками.

Итого:

Идём по П.3. — добавляем в .npmrc >> save-exact=true.
Для всего, что видим в devDependencies — заного поочерёдно делаем npm i module-name. (Они перелетят из devDependencies в prod-dependencies. Пока, тут это нам и нужно.)
Ну и наконец-то устанавливаем наш adapter-auto:

npm i @sveltejs/adapter-auto.

P.S. Устанавливая один модуль — установятся все dependencies, как если бы мы делали всё это одним npm i.

А @sveltejs/adapter-auto можно удалить, чтоб не мешался.

Как удалить модуль?

https://docs.npmjs.com/cli/v10/commands/npm-uninstall

npm uninstall @sveltejs/adapter-auto — удалит в каких бы *Dependencies они не находились.

Раньше нужно было дописывать --save-dev и т.д., иначе удалится из node_modules/, но не из package.json и т.д.
Сейчас этого нет. Только если прописать в .npmrc >> save=false, тогда нужно будет --save.
Но не вижу во всём этом смысла для общих случаев.
Можно удалить строку "@sveltejs/adapter-auto": "^2.0.0", руками.

При этом удалить node_modules/ и package-lock.json.
И сделать npm i всего проекта заново.
Но, так делать не стоит, когда всё уже в бою.
Это может навредить и серверной сборке, и коллегам, но об этом позже.

Как не захламить prod-`dependencies`?

Понятно, что в процессе разработки мы пробуем много разных модулей, которые чаще всего не пойдут на прод.
И, не хотелось бы, чтобы всё ложилось в prod-dependencies.

Тут выясняется, что возможен ещё какой-то peerDependencies,
где вообще — у каждого разработчика появляется свой личный блок с модулями:
npm i node_module --save-peer (--save-peer не задокументирован, но работает. https://stackoverflow.com/a/74549787/4117781)

Пропустил я эту команду, и получил что-то новое — звёздочку! в devDependencies:

"devDependencies": {
    "@sveltejs/adapter-auto": "*",
},
"peerDependencies": {
    "@sveltejs/adapter-auto": "2.1.1"
}

Испугался, и решил не использовать.
Давайте лучше дружно хламить devDependencies, но уж лучше без этого.
Там ещё как-то должен был прописаться мой личный скоуп, на основе имени компа, но и этого автоматически не произошло.
Валим из этой идеи короче :D
Как минимум в этой статье.

Не будем тянуть.
Чтобы все модули по-умолчанию сваливались в devDependencies:
.npmrc >> save-dev=true

Теперь, чтобы вогнать что-то в prod-dependencies нужно будет npm i module-name --save-prod.
Такое делается не каждый день. Но — это ответственно.
Потому, вероятно — это должен делать кто-то один из команды.

Зачем нужен `package-lock.json`?

У модулей, которые у нас в зависимостях, — есть свои зависимости.
Каждая мажорная версия (1.0.0 —> 2.0.0) по конвенции допускает нарушение обратной совместимости.
https://docs.npmjs.com/about-semantic-versioning

Зафиксируем:
^1.0.0 — тут разработчик модуля говорит, что версия зависимости сойдёт вплоть до 2.0.0.
~1.0.0 — тут разработчик модуля говорит, что версия зависимости сойдёт вплоть до 1.1.0.

И — наши зависимости, зависимости модулей — могут между собой пересекаться.
А сама конечная зависимость — может быть только одна.
И, делая npm i — каждый новый раз — нода может выкачивать из своих репозиториев чутка разные набор зависимостей, более оптимальные на текущий момент, удовлетворяя при этом всем настройкам выше — и в наших зависимостях, и в зависимостях зависимостей.
Поэтому, несмотря на то, что package-lock.json такой страшный — к сожалению, его лучше всё же класть в git.
Чтобы не попасть в ситуацию, когда набор зависимостей на локале и на проде разный, а ты не можешь понять в чём ошибка.
А ошибка может быть в любой даже минорной версии с баг-фиксом в любой из зависимостей.
Хотя, это и бывает редко. Но бьёт больно.

Чтобы package-lock.json так не раздражал в git-e, парни предлагают:
.gitattributes —> package-lock.json binary
https://stackoverflow.com/a/50982431/4117781

Итого в `.npmrc`

https://docs.npmjs.com/cli/v10/configuring-npm/npmrc

engine-strict=true <— добрая рекомендация от Svelte
save-exact=true
save-dev=true

Что ещё интересного в `package.json`?

1. "private": true,
Consider also setting "private": true to prevent accidental publication.
https://docs.npmjs.com/cli/v10/configuring-npm/package-json
Не знаю как это возможно, но, если «accidental», то убирать не будем.

2. "type": module,
Это то, что позволяет нам делать модные import a from '/b.js, вместо старых a = require('b') и т.д.

3. Авторская рекомендация
Т.к. у нас кроме ноды есть строгое API со всякими проверками на всякие хосты, порты и заголовки,
стоит гарантировать на каком хосте/порте будет открываться dev-версия.
Заменить:
"dev": "vite dev",
На:
"dev": "vite dev --host 127.0.0.1 --port 3000",
А ещё добавить:
"host": "vite dev --host --port 3000",
чтобы просто npm run host, и проект можно посмотреть хоть на телефоне (если подключен к тому же wi-fi)

Во имя науки

Можно руками закинуть модуль и в «prod» и в «dev». И даже ничего не сломается, но — не знаю зачем. При попытке обновить/форсировать установку ещё раз — одна из записей сотрётся, в зависимости от куда --save-x и т.д.
optionalDependencies — когда допускаем, что модуль может не установиться, а он нам и не очень-то и нужен.
bundleDependencies — когда пилим свой модуль.
Постоянно встречаются упоминания npm-shrinkwrap.json — Это «freeze» package-lock.json для тех случаев когда это внезапно нужно:
- Ноддерживает старые версии ноды (когда package-lock.json только с v5),
- Необходим для публикации в качестве npm-модуля,
- А также, если встряли с версиями зависимостей. Тут npm-shrinkwrap.json позволит управлять версиями вручную (https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/). В общем, не думая об этом — мы ничего не упускаем. Просто будем знать на всякий случай.

Как делать `install` на проде?

Принято делать вот так:

npm ci --[ТОЛЬКО PROD-DEPENDENCIES]

[ТОЛЬКО PROD-DEPENDENCIES]

Можно встретить много рекомендаций, обещающих один и тот же результат:
--omit=dev, --include=prod, --only=prod, --production

По всей видимости это из-за долгой эволюции ноды.
Для последней 10-й версии в документации есть только --include=prod (https://docs.npmjs.com/cli/v10/commands/npm-ci).
Но, так — у меня устанавливаются всё — и «prod» и «dev».
В итоге, делаю так:
npm ci --omit=dev
Множественное «опущение» делается так:
npm ci --omit=dev --omit=peer

Что за ci? https://docs.npmjs.com/cli/v10/commands/npm-ci

Собственно, это то, что выкачивает node_modules/ на основе package-lock.json, в обход package.json, гарантируя то, что на проде будет так, как было на локале.

Иии, внииимаааниииеее...

Спасибо, за внимание.

DEV Community: Max Core

SvelteKit 2: Code-based router instead of file-based router now is just a Gist!

Minimal Example:

Installation:

Extended Example:

Downsides:

P.S.

Svelte: Best practice to combine $derived and $state

Базовый ультимативный гайд по Nginx

База. Зачем нужен Nginx. Логика X-Forwarded-For.

Nginx

Боевая имплементация

Базовый ультимативный гайд по событиям в JavaScript (на примере SvelteKit)

Был такой случай

По умолчанию — все действия Прогрессивные — сначала проходит Потомок, потом Родитель.

Есть только 1 способ начать пропускать старших:

Логика событий

JavaScript это не жизнь. Здесь возможны 2-е параллельные вселенные:

Но, у нас есть не только click, есть и mousedown, mouseup и т.д.

e.stopPropagation

e.preventDefault

Чем отличаются mousedown, mouseup и click?

Иии, внииимаааниииеее...

Базовый ультимативный гайд по Node.js (на примере SvelteKit)

Что предлагает Svelte на старте?

Что рекомендуют разработчики Svelte?

Как установить новый модуль?

Как установить строгую версию?

Как удалить модуль?

Как не захламить prod-dependencies?

Зачем нужен package-lock.json?

Итого в .npmrc

Что ещё интересного в package.json?

Во имя науки

Как делать install на проде?

Иии, внииимаааниииеее...

База. Зачем нужен Nginx. Логика `X-Forwarded-For`.

Но, у нас есть не только `click`, есть и `mousedown`, `mouseup` и т.д.

`e.stopPropagation`

`e.preventDefault`

Чем отличаются `mousedown`, `mouseup` и `click`?

Как не захламить prod-`dependencies`?

Зачем нужен `package-lock.json`?

Итого в `.npmrc`

Что ещё интересного в `package.json`?

Как делать `install` на проде?