Prettier in Rust challenge
Почти месяц назад ESLint анонсировали отказ от правил форматирования , что, безусловно, является правильным решением: правил много и их надо поддерживать, остальные форматтеры покрывают больше кейсов, возникают конфликты между линтером и форматером. В общем, не нужно оно в том виде, в котором существует сейчас.
А 10 дней назад Christopher Chedeau более известный как Vjeux и автор Prettier анонсировал челендж — тот кто портирует prettier на rust, получит $10 000. К нему присоединился Guillermo Rauch (CEO Vercel) — итого $20 000. Основной критерий — 95% тестов преттиера должны выполняться. Так же там по мелочи ($2.5к) дают за компиляцию в WASM и поддежку NAPI-RS.
И, кажется, у этого челенджа есть победитель — Biome (ex Rome, я много писал о них, можете поискать по каналу).
В Biome очень хорошо консолидировались и за полторы недели достигли цели. У них получилось это сделать так быстро, т.к. форматтер и до этого покрывал большое количество тестов, что-то около 92%.
Так же в челендже была замечена команда Oxc — за неделю они успели покрыть 21% кейсов. А создатель SWC решил, что у него нет на это времени.
В целом, я рад за биом — им деньги нужны как никогда. Но я точно не могу назвать преттиер медленным. И у меня возникает вопрос — а этот челендж действительно имеет смысл? Так же думает и Isaac Schlueter, создатель npm и подмечает, что самая быстрый способ — не совершать работу в принципе, кешировать и параллелизировать.
Кстати, у преттиера уже есть кеширование:
Чего преттиеру не хватает, так это параллельности.
Кристофер, как затейник всего челенджа, признаётся, что одна из идей — найти героя, который найдет узкие места в самом преттиере.
К примеру, преттиер резолвит .editorconfig для каждого файла. Кеширование резовла конфига сокращает резолв с 12 секунд до 13 милисекунд при форматировании 20 000 файлов. Ну и вот ишью об этом.
В целом, история с челенджем странная. Мне кажется правильней было бы объявить баунти для самого преттиера… Ну и посмотрим на сколько биом будет быстрее, если, конечно, будет.
Ну и тем временем biome пытаются интегрировать в репозиторий ноды, но консенсуса пока не наблюдается. Один из жирных минусов — 100мб для каждой версии биома в репозитории.
Ну а ESLint не остался в стороне. Anthony Fu, член команды Vue, решил поддерживать правила форматирования и вынес их в проект ESLint Stylistic. Что-что, а это я точно считаю неправильным решением — нам нужно меньше форматеров, а не больше…
Почти месяц назад ESLint анонсировали отказ от правил форматирования , что, безусловно, является правильным решением: правил много и их надо поддерживать, остальные форматтеры покрывают больше кейсов, возникают конфликты между линтером и форматером. В общем, не нужно оно в том виде, в котором существует сейчас.
А 10 дней назад Christopher Chedeau более известный как Vjeux и автор Prettier анонсировал челендж — тот кто портирует prettier на rust, получит $10 000. К нему присоединился Guillermo Rauch (CEO Vercel) — итого $20 000. Основной критерий — 95% тестов преттиера должны выполняться. Так же там по мелочи ($2.5к) дают за компиляцию в WASM и поддежку NAPI-RS.
И, кажется, у этого челенджа есть победитель — Biome (ex Rome, я много писал о них, можете поискать по каналу).
В Biome очень хорошо консолидировались и за полторы недели достигли цели. У них получилось это сделать так быстро, т.к. форматтер и до этого покрывал большое количество тестов, что-то около 92%.
Так же в челендже была замечена команда Oxc — за неделю они успели покрыть 21% кейсов. А создатель SWC решил, что у него нет на это времени.
В целом, я рад за биом — им деньги нужны как никогда. Но я точно не могу назвать преттиер медленным. И у меня возникает вопрос — а этот челендж действительно имеет смысл? Так же думает и Isaac Schlueter, создатель npm и подмечает, что самая быстрый способ — не совершать работу в принципе, кешировать и параллелизировать.
Кстати, у преттиера уже есть кеширование:
yarn prettier --cache --cache-strategy content
Чего преттиеру не хватает, так это параллельности.
Кристофер, как затейник всего челенджа, признаётся, что одна из идей — найти героя, который найдет узкие места в самом преттиере.
К примеру, преттиер резолвит .editorconfig для каждого файла. Кеширование резовла конфига сокращает резолв с 12 секунд до 13 милисекунд при форматировании 20 000 файлов. Ну и вот ишью об этом.
В целом, история с челенджем странная. Мне кажется правильней было бы объявить баунти для самого преттиера… Ну и посмотрим на сколько биом будет быстрее, если, конечно, будет.
Ну и тем временем biome пытаются интегрировать в репозиторий ноды, но консенсуса пока не наблюдается. Один из жирных минусов — 100мб для каждой версии биома в репозитории.
Ну а ESLint не остался в стороне. Anthony Fu, член команды Vue, решил поддерживать правила форматирования и вынес их в проект ESLint Stylistic. Что-что, а это я точно считаю неправильным решением — нам нужно меньше форматеров, а не больше…
👍63❤2👎2
Object.groupBy() и Map.groupBy() достигли stage 4
Новость, как и методы, прекрасная! Боюсь сосчитать сколько раз мне приходилось писать что-то подобное.
Пример использования:
Новость, как и методы, прекрасная! Боюсь сосчитать сколько раз мне приходилось писать что-то подобное.
Пример использования:
const array = [1, 2, 3, 4, 5];
// `Object.groupBy` groups items by arbitrary key.
// In this case, we're grouping by even/odd keys
Object.groupBy(array, (num, index) => {
return num % 2 === 0 ? 'even': 'odd';
});
// => { odd: [1, 3, 5], even: [2, 4] }
// `Map.groupBy` returns items in a Map, and is useful for grouping
// using an object key.
const odd = { odd: true };
const even = { even: true };
Map.groupBy(array, (num, index) => {
return num % 2 === 0 ? even: odd;
});
// => Map { {odd: true}: [1, 3, 5], {even: true}: [2, 4] }
👍115❤10😱6
Валя читает ишью pinned «Т.к. идей для постов у меня сильно больше, чем времени и возможностей писать, то решил сделать отдельный канал с менее подробными разборами, да и в целом с менее значимыми новостями. https://xn--r1a.website/valya_posts_links/5»
This media is not supported in your browser
VIEW IN TELEGRAM
VSCode 1.85: Floating windows
7 лет назад появилось ишью о том, что было бы здорово иметь возможность выносить части редактора в отдельные окна. Особенно это удобно владельцам нескольких мониторов.
Ну что ж, можно поздравить этих самых владельцев нескольких мониторов! Мне же эта штука показалась интересной по двум причинам.
1. Судя по всему реализовать это было не очень просто либо это было совсем неприоритетной задачей.
2. Я пользуюсь внешним терминалом (iTerm), который показывается на любом воркспейсе на пол экрана по хоткею. Но работая с вскодом удобней использовать встроенный, т.к. в нём работает парсинг и всякие ошибки удобно смотреть в панельке «Problems» и перемещаться между ними. Уже какое-то время терминал можно перенести в поле редактора (ну там где файлики открытые) через команду «Move terminal into Editor Area», а теперь его можно будет и вынести в отдельное окно. Far from perfect, но мне определённо нравится куда всё это движется. Может быть когда-нибудь и перепридумаю свой воркфлоу. Хотя я, конечно, хотел бы иметь возможность как-то связывать внешний терминал с вскодом…
На текущий момент этой фиче посвящено 37 ишью, что как бы намекает, что она работает неидеально и будет дорабатываться. Отдельно отмечу возможность вытаскивать панели и вьюшки, а не только редактор: Aux window: allow detaching views and panels.
7 лет назад появилось ишью о том, что было бы здорово иметь возможность выносить части редактора в отдельные окна. Особенно это удобно владельцам нескольких мониторов.
Ну что ж, можно поздравить этих самых владельцев нескольких мониторов! Мне же эта штука показалась интересной по двум причинам.
1. Судя по всему реализовать это было не очень просто либо это было совсем неприоритетной задачей.
2. Я пользуюсь внешним терминалом (iTerm), который показывается на любом воркспейсе на пол экрана по хоткею. Но работая с вскодом удобней использовать встроенный, т.к. в нём работает парсинг и всякие ошибки удобно смотреть в панельке «Problems» и перемещаться между ними. Уже какое-то время терминал можно перенести в поле редактора (ну там где файлики открытые) через команду «Move terminal into Editor Area», а теперь его можно будет и вынести в отдельное окно. Far from perfect, но мне определённо нравится куда всё это движется. Может быть когда-нибудь и перепридумаю свой воркфлоу. Хотя я, конечно, хотел бы иметь возможность как-то связывать внешний терминал с вскодом…
На текущий момент этой фиче посвящено 37 ишью, что как бы намекает, что она работает неидеально и будет дорабатываться. Отдельно отмечу возможность вытаскивать панели и вьюшки, а не только редактор: Aux window: allow detaching views and panels.
👍46❤8🥱3
VSCode 1.85: Multi-file diff editor
Есть одна вещь, которую я ненавижу в ГитХабе — страничка с дифом у пул-реквестов. А ненавижу я её, потому что пользоваться ей невозможно. Я не понимаю, как ключевая часть продукта может быть сделана так плохо. Я понимаю, что это сложная задача, даже Илья Климов пришёл в твиттер со словами «Как человек пытающийся сделать это в гитлабе - это очень сложно :)». Но, однако, к ГитЛабу у меня никаких претензий нет. Ну т.е. можно ли сделать лучше? Ну, да. Но у них хотя бы список файлов не грузится минуту. Обычно к таким постам приходят люди со словами «а ты не пробовал делать пул-реквесты поменьше???». Это, кстати, для меня прям показатель неопытности: не все пул-реквесты реально разбить на части, особенно какие-то миграции на другие подходы и библиотеки. За 3 года в Авиасейлс у меня было множество ПРов на 5000 строк, но дифф сводится к 5 строкам в 1000 файлах. Самое смешное, что после какого-то количества файлов ГитХаб просто не показывает дифф, и приходится тыкать кнопочку «Show diff» на каждом файле. Треш!
Так вот, я какое-то время ходил вокруг да около, пытаясь оптимизировать как-то процесс ревью хотя бы для себя: правило хорошего тона «сначала посмотри сам, потом отдавай на ревью».
1 вариант был открывать дифф в браузере, нужно просто добавить .diff к пру:
github.com/nodejs/node/pull/51124.diff
Но смотреть такое невозможно — просто простыня текста
В качестве 2-го варианта я попробовал официальный CLI ГитХаба:
В общем, последний год я просто вызывал
И вот в VS Code 1.85 появилась экспериментальная фича multi-file diff editor. Это, в общем-то, тот же дифф, что всегда был в вскоде, только в виде простыни из файлов. И знаете, оно работает! Не идеально, но работает!
Я открывал пул-реквест в ноду выше: github.dev/nodejs/node/pull/51124.
Дифф внушительный 1854 файла —+48,035 −17,659 строк. Да, нужно подождать пока оно прогрузится, но я лучше подожду, чем буду постоянно пользоваться лагающим интерфейсом. Да, это не 60fps и даже не 30, но я скролю в любую позицию и сразу же вижу файл и его дифф. И да, могу прям здесь написать комментарий к любой строке. В общем, я в восторге!
Т.к. фича экспериментальная, то её надо принудительно включить:
Такой дифф доступен для локальных и staged изменений, incoming/outgoing изменений при мёрдже и для просмотра пул-реквестов.
Есть одна вещь, которую я ненавижу в ГитХабе — страничка с дифом у пул-реквестов. А ненавижу я её, потому что пользоваться ей невозможно. Я не понимаю, как ключевая часть продукта может быть сделана так плохо. Я понимаю, что это сложная задача, даже Илья Климов пришёл в твиттер со словами «Как человек пытающийся сделать это в гитлабе - это очень сложно :)». Но, однако, к ГитЛабу у меня никаких претензий нет. Ну т.е. можно ли сделать лучше? Ну, да. Но у них хотя бы список файлов не грузится минуту. Обычно к таким постам приходят люди со словами «а ты не пробовал делать пул-реквесты поменьше???». Это, кстати, для меня прям показатель неопытности: не все пул-реквесты реально разбить на части, особенно какие-то миграции на другие подходы и библиотеки. За 3 года в Авиасейлс у меня было множество ПРов на 5000 строк, но дифф сводится к 5 строкам в 1000 файлах. Самое смешное, что после какого-то количества файлов ГитХаб просто не показывает дифф, и приходится тыкать кнопочку «Show diff» на каждом файле. Треш!
Так вот, я какое-то время ходил вокруг да около, пытаясь оптимизировать как-то процесс ревью хотя бы для себя: правило хорошего тона «сначала посмотри сам, потом отдавай на ревью».
1 вариант был открывать дифф в браузере, нужно просто добавить .diff к пру:
github.com/nodejs/node/pull/51124.diff
Но смотреть такое невозможно — просто простыня текста
В качестве 2-го варианта я попробовал официальный CLI ГитХаба:
gh pr diff — отдаёт тот же самый дифф, что и первый способ, но уже с подстветкой. Иногда я запихивал этот дифф в diff2html. Так же я пытался прикрутить delta, чтобы не покидать консоли (это всё таки работает быстрее, чем браузер), но мне не хватило усидчивости его приготовить. В общем, последний год я просто вызывал
gh pr diff и листал вывод. Не могу сказать, что меня устраивал это способ, но работало точно лучше ГитХаба и позволяло оценить нет ли лишних изменений в ПРах.И вот в VS Code 1.85 появилась экспериментальная фича multi-file diff editor. Это, в общем-то, тот же дифф, что всегда был в вскоде, только в виде простыни из файлов. И знаете, оно работает! Не идеально, но работает!
Я открывал пул-реквест в ноду выше: github.dev/nodejs/node/pull/51124.
Дифф внушительный 1854 файла —+48,035 −17,659 строк. Да, нужно подождать пока оно прогрузится, но я лучше подожду, чем буду постоянно пользоваться лагающим интерфейсом. Да, это не 60fps и даже не 30, но я скролю в любую позицию и сразу же вижу файл и его дифф. И да, могу прям здесь написать комментарий к любой строке. В общем, я в восторге!
Т.к. фича экспериментальная, то её надо принудительно включить:
"multiDiffEditor.experimental.enabled": trueТакой дифф доступен для локальных и staged изменений, incoming/outgoing изменений при мёрдже и для просмотра пул-реквестов.
👍75❤11
Vitest: 9 месяцев спустя
Напомню, мы в Авиасейлс переехали с Jest на Vitest и были (ну, я уж точно) не очень довольны результатом. Прошло 9 месяцев, вышла Vitest 1.0 (а актуальная версия уже и 1.2.1) и мы научились с ним как-то жить.
Во-первых, я оказался прав на счёт шардирования. В синтетических тестах (только vitest в пайплайне, это существенно ускоряет тесты) используя 12 тредов, тесты проходили за ~3 минуты. 4 шарда по 3 треда в каждом (с меньшим количеством тредов тесты начинали зависать) мы укладываемся в ~2 минуты. Сайд-эффект шардов — теперь у нас 4 разных отчёта, а не один единый. Неудобно. Команда Vitest открыта к blob репортерам, как в playwright. Их можно склеить после и получить единый отчёт. Осталось написать ишью и реализовать, хех.
Касательно перформанса тредов вот моё ишью — The performance of threads doesn't scale much after 8 threads.
Во-вторых, нам удалось стабилизировать тесты и избавиться от залипаний и случайных падений. С тех пор мы обновились до node v18.19.0 и vitest v1.1.3, удалили любые исключения из poolMatchGlobs и используем threads пул (стандартный и не самый быстрый).
В-третьих, нестабильность витеста породила особенный подход обновлению его самого и ноды. Мы запускаем 100+ пайплайнов по крону, смотрим fail rate и принимаем решение об обновлении или включении каких-то опций. Как я сказал выше, на v1.1.3 нам удалось добиться 100% стабильности, но вот уже с v1.2.1 (latest) один из тестов начинает отваливаться в трети случаев.
В-четвёртых, я был не особо прав, когда сравнивал типы пулов. С тех пор в витесте появился пул vmThreads, который полностью копирует подход из джеста. Он действительно быстрее (в нашем случае срезает ~30 секунд), но менее стабильный и течёт по памяти (как и джест).
В общем, кажется мы научились его готовить, но иногда процесс готовки становится, прямо скажем, неприятным.
Напомню, мы в Авиасейлс переехали с Jest на Vitest и были (ну, я уж точно) не очень довольны результатом. Прошло 9 месяцев, вышла Vitest 1.0 (а актуальная версия уже и 1.2.1) и мы научились с ним как-то жить.
Во-первых, я оказался прав на счёт шардирования. В синтетических тестах (только vitest в пайплайне, это существенно ускоряет тесты) используя 12 тредов, тесты проходили за ~3 минуты. 4 шарда по 3 треда в каждом (с меньшим количеством тредов тесты начинали зависать) мы укладываемся в ~2 минуты. Сайд-эффект шардов — теперь у нас 4 разных отчёта, а не один единый. Неудобно. Команда Vitest открыта к blob репортерам, как в playwright. Их можно склеить после и получить единый отчёт. Осталось написать ишью и реализовать, хех.
Касательно перформанса тредов вот моё ишью — The performance of threads doesn't scale much after 8 threads.
Во-вторых, нам удалось стабилизировать тесты и избавиться от залипаний и случайных падений. С тех пор мы обновились до node v18.19.0 и vitest v1.1.3, удалили любые исключения из poolMatchGlobs и используем threads пул (стандартный и не самый быстрый).
В-третьих, нестабильность витеста породила особенный подход обновлению его самого и ноды. Мы запускаем 100+ пайплайнов по крону, смотрим fail rate и принимаем решение об обновлении или включении каких-то опций. Как я сказал выше, на v1.1.3 нам удалось добиться 100% стабильности, но вот уже с v1.2.1 (latest) один из тестов начинает отваливаться в трети случаев.
В-четвёртых, я был не особо прав, когда сравнивал типы пулов. С тех пор в витесте появился пул vmThreads, который полностью копирует подход из джеста. Он действительно быстрее (в нашем случае срезает ~30 секунд), но менее стабильный и течёт по памяти (как и джест).
В общем, кажется мы научились его готовить, но иногда процесс готовки становится, прямо скажем, неприятным.
❤40👍19
Vitest: шардирование
Т.к. в коментариях были вопросы что это ваще такое, то покажу и расскажу.
В целом шардирование популярная практика. Идея в том, чтобы разделить один процесс на несколько и таким образом достичь параллельности
Вот так мы запускали витест до:
А вот так запускаем теперь (команды запускаются параллельно):
Обратите внимание, что каждый отчёт живёт в отдельной директории и пока что нет способа их склеить.
https://vitest.dev/guide/cli.html#shard
Т.к. в коментариях были вопросы что это ваще такое, то покажу и расскажу.
В целом шардирование популярная практика. Идея в том, чтобы разделить один процесс на несколько и таким образом достичь параллельности
Вот так мы запускали витест до:
VITEST_MIN_THREADS=12 VITEST_MAX_THREADS=12 yarn vitest --reporter=html --reporter=html --outputFile.html=./vitest-reports/01/index.html
А вот так запускаем теперь (команды запускаются параллельно):
VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=1/4 --reporter=html --outputFile.html=./vitest-reports/01/index.html
VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=2/4 --reporter=html --outputFile.html=./vitest-reports/02/index.html
VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=3/4 --reporter=html --outputFile.html=./vitest-reports/03/index.html
VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=4/4 --reporter=html --outputFile.html=./vitest-reports/04/index.html
Обратите внимание, что каждый отчёт живёт в отдельной директории и пока что нет способа их склеить.
https://vitest.dev/guide/cli.html#shard
👍16❤1
Forwarded from mefody.dev
git rerere
Как говорится, чем больше ты знаешь, тем меньше ты знаешь. Сегодня я узнал, что в git есть фича запоминать разрешённые при мердже или ребейзе конфликты.
Например, если вы работаете в какой-то «гигаветке» (долго делаете большую недробимую фичу), постоянно подливая из других веток изменения и разрешая одни и те же мерж-конфликты, то с включённой в конфиге опцией
Насовсем я бы эту опцию не включал, чтобы не искать потом перед срочным релизом, почему git ведёт себя странно. Но для работы над большими фичами в большой команде, кажется, подходит хорошо.
https://git-scm.com/book/en/v2/Git-Tools-Rerere
Как говорится, чем больше ты знаешь, тем меньше ты знаешь. Сегодня я узнал, что в git есть фича запоминать разрешённые при мердже или ребейзе конфликты.
Например, если вы работаете в какой-то «гигаветке» (долго делаете большую недробимую фичу), постоянно подливая из других веток изменения и разрешая одни и те же мерж-конфликты, то с включённой в конфиге опцией
rerere (reuse recorded resolution) вы можете разрешить конфликт всего один раз, а затем git, если увидит, что в файле с таким-то именем уже была ситуация, что у нас такая-то строчка, а снаружи пришла такая-то строчка, то разработчик решал конфликт вот так. И, собственно, не будет спрашивать ещё раз, а решит, как вы решили в первый раз.git config --global rerere.enabled trueНасовсем я бы эту опцию не включал, чтобы не искать потом перед срочным релизом, почему git ведёт себя странно. Но для работы над большими фичами в большой команде, кажется, подходит хорошо.
https://git-scm.com/book/en/v2/Git-Tools-Rerere
❤63👍15
Мне, кстати, кажется это многое говорит о том какой гит "юзер-френдли"...
👍17👎1🥱1
Forwarded from artalog (artalar)
Temporal
Ну и история! 13 мая 2017 появляется первый коммит Temporal Proposal - нового апи для управления датами, вдохновленный moment и luxon.
Ключевые отличия от Date: продуманная работа с часовыми поясами, иммутабельное апи, работа с интервалами (Duration). Схема ключевых сущностей.
В 20 году идет активная работа над полифилом. Игалия вкладывает в него много сил, написано куча тестов, многое сделано типобезопасно и даже в рантайме расставлено куча ассертов - все по лучшим практикам.
Я сам использовал этот полифил в течении года, пока пилил проект на ноде, остался очень доволен! С багами не сталкивался, только сделал ПР с улучшением типов (приятно делать даже небольшой вклад в такие крупные проекты)
Уже в 21 году я считал сам пропосал и полифил к нему самым продуманным и проработанным тулом для работы с датами. И сейчас так считаю, но смущает 200 kB (50 kB gzip), что бы тянуть на фронт. Хотя стоит учитывать, что когда оно появится в браузере вы сможете просто вырезать полифил не меняя сам код, чего не скажешь про остальные либы для дат из NPM.
Но почему это все еще не стандарт?
Ключевая фича нового апи - работа с часовыми поясами, не могла быть реализована из-за недоработки самого стандарта часовых поясов. Ужвал - сотрудник Игалии и основной разработчик Temporal, а так же просто очень крутой чел, внес предложение в стандарт дат всея интернета по расширению формата хранения и передачи времени с возможностью расширять его дополнительной информацией. Например?
По закону на Гаваях время должно быть одно, но все местные живут по другому, кто прав? Это не придуманная ситуация, а реальная проблема с которой столкнулся разработчик у нас в чате. Предложенное расширение стандарта позволяет указать не только часовой пояс, но и конкретный “календарь”, который может иметь свою специфику.
23 октября 2023 предложение апрувнули!
Работа над темпорал продолжается, серьезных блокеров, кажется, больше нет. Текущий статус трекатеся тут: https://github.com/tc39/proposal-temporal/issues/2628
Мне сложно сказать, когда предложение станет стандартом и мы увидем его в браузерах, но вот в V8 реализация Temporal занимает уже больше 2.6% бинарника и вы уже можете использовать его в Deno.
Напоследок, очень порекомендую великолепный доклад Пару календарей назад я был совсем другим Алексея Охрименко, для понимания всей проблематики. А вот доклад конкретно про Temporal: How to Outsmart Time Building Futuristic JavaScript Apps Using Temporal
Ну и история! 13 мая 2017 появляется первый коммит Temporal Proposal - нового апи для управления датами, вдохновленный moment и luxon.
Ключевые отличия от Date: продуманная работа с часовыми поясами, иммутабельное апи, работа с интервалами (Duration). Схема ключевых сущностей.
В 20 году идет активная работа над полифилом. Игалия вкладывает в него много сил, написано куча тестов, многое сделано типобезопасно и даже в рантайме расставлено куча ассертов - все по лучшим практикам.
Я сам использовал этот полифил в течении года, пока пилил проект на ноде, остался очень доволен! С багами не сталкивался, только сделал ПР с улучшением типов (приятно делать даже небольшой вклад в такие крупные проекты)
Уже в 21 году я считал сам пропосал и полифил к нему самым продуманным и проработанным тулом для работы с датами. И сейчас так считаю, но смущает 200 kB (50 kB gzip), что бы тянуть на фронт. Хотя стоит учитывать, что когда оно появится в браузере вы сможете просто вырезать полифил не меняя сам код, чего не скажешь про остальные либы для дат из NPM.
Но почему это все еще не стандарт?
Ключевая фича нового апи - работа с часовыми поясами, не могла быть реализована из-за недоработки самого стандарта часовых поясов. Ужвал - сотрудник Игалии и основной разработчик Temporal, а так же просто очень крутой чел, внес предложение в стандарт дат всея интернета по расширению формата хранения и передачи времени с возможностью расширять его дополнительной информацией. Например?
По закону на Гаваях время должно быть одно, но все местные живут по другому, кто прав? Это не придуманная ситуация, а реальная проблема с которой столкнулся разработчик у нас в чате. Предложенное расширение стандарта позволяет указать не только часовой пояс, но и конкретный “календарь”, который может иметь свою специфику.
23 октября 2023 предложение апрувнули!
Работа над темпорал продолжается, серьезных блокеров, кажется, больше нет. Текущий статус трекатеся тут: https://github.com/tc39/proposal-temporal/issues/2628
Мне сложно сказать, когда предложение станет стандартом и мы увидем его в браузерах, но вот в V8 реализация Temporal занимает уже больше 2.6% бинарника и вы уже можете использовать его в Deno.
Напоследок, очень порекомендую великолепный доклад Пару календарей назад я был совсем другим Алексея Охрименко, для понимания всей проблематики. А вот доклад конкретно про Temporal: How to Outsmart Time Building Futuristic JavaScript Apps Using Temporal
❤40👍21👎2
GitLab copyright strike
4 года назад я работал в Альфа-Банке и был у нас там гитлаб. Хорошая штука: и селфхост, и дифф быстро работает, и CI есть, и регистр пакетов. В общем, не инструмент, а мечта!
Но одна штука меня очень сильно раздражала — перенос строк в логах CI. Особенно сильно бесило это при использовании покрытия кода (coverage) в Jest. Он там рисует достаточно широкую и массивную табличку, и смотреть на всё это в маленьком окошке очень неудобо.
Я немного подумал и за один вечер написал простенькое расширение для браузера: берём лог, делаем сплит по строкам, парсим ANSI, рендерим как виртуальный список. Дешёво и сердито. Контрибьютить в гитлаб мне почему-то тогда не захотелось. Видимо, подумал, что это будет не очень просто.
Спустя год я уволился из Альфы, перестал пользоваться гитлабом и благополучно забыл про экстеншн. Но вот неделю назад мне пришлось вспомнить о нём: на почту пришло сообщение «Unauthorized Use of GitLab Intellectual Property». Меня похвалили за экстеншн (американцы ж без этого не могут, вы знаете), но сказали что я мягко говоря не прав т.к. использую в название «GitLab» и ещё и над логотипом надругался (покрасил в другие цвета). Что ж, справедливо — трейдмарк есть трейдмарк™.
Склонировал репо, попытался установить зависимости и сбилдить — всё сразу же сломалось. Заметка на будущее — сразу коммитить .nvmrc, чтоб потом не вспоминать на какой это версии ноды работало. Переименовал, поменял (я тот ещё дизайнер) лого — моя совесть чиста. Надеюсь ребята из гитлаба так же считают…
А расширение теперь называется gtlb-job-log-viewer, и им даже 500 таких же страдальцев, как я, пользуется.
P.S. Ради интереса посмотрел как гитлаб нынче выглядит. Мож и не нужен мой экстеншн то? Добавили возможность открыть логи во весь экран. Ну, неплохо, но хотелось бы большего…
4 года назад я работал в Альфа-Банке и был у нас там гитлаб. Хорошая штука: и селфхост, и дифф быстро работает, и CI есть, и регистр пакетов. В общем, не инструмент, а мечта!
Но одна штука меня очень сильно раздражала — перенос строк в логах CI. Особенно сильно бесило это при использовании покрытия кода (coverage) в Jest. Он там рисует достаточно широкую и массивную табличку, и смотреть на всё это в маленьком окошке очень неудобо.
Я немного подумал и за один вечер написал простенькое расширение для браузера: берём лог, делаем сплит по строкам, парсим ANSI, рендерим как виртуальный список. Дешёво и сердито. Контрибьютить в гитлаб мне почему-то тогда не захотелось. Видимо, подумал, что это будет не очень просто.
Спустя год я уволился из Альфы, перестал пользоваться гитлабом и благополучно забыл про экстеншн. Но вот неделю назад мне пришлось вспомнить о нём: на почту пришло сообщение «Unauthorized Use of GitLab Intellectual Property». Меня похвалили за экстеншн (американцы ж без этого не могут, вы знаете), но сказали что я мягко говоря не прав т.к. использую в название «GitLab» и ещё и над логотипом надругался (покрасил в другие цвета). Что ж, справедливо — трейдмарк есть трейдмарк™.
Склонировал репо, попытался установить зависимости и сбилдить — всё сразу же сломалось. Заметка на будущее — сразу коммитить .nvmrc, чтоб потом не вспоминать на какой это версии ноды работало. Переименовал, поменял (я тот ещё дизайнер) лого — моя совесть чиста. Надеюсь ребята из гитлаба так же считают…
А расширение теперь называется gtlb-job-log-viewer, и им даже 500 таких же страдальцев, как я, пользуется.
P.S. Ради интереса посмотрел как гитлаб нынче выглядит. Мож и не нужен мой экстеншн то? Добавили возможность открыть логи во весь экран. Ну, неплохо, но хотелось бы большего…
GitHub
GitHub - 7rulnik/gtlb-job-log-viewer: Browser extension for code highlighting raw logs in GitLab CI
Browser extension for code highlighting raw logs in GitLab CI - 7rulnik/gtlb-job-log-viewer
👍57❤8
Как дела, потомки? Узнаёте?
P.S. Увидел в твиттере и аж прослезился, простите.
P.S. Увидел в твиттере и аж прослезился, простите.
❤57😱8
Forwarded from TrySound forked your repository
Начиная с ноды v20 и в браузерах есть встроенный генератор uuid v4
crypto.randomUUID(), доступен глобально.
Это самый частый юзкейс для пакета https://github.com/uuidjs/uuid и если другие версии или валидация не нужна, смело дропайте.
crypto.randomUUID(), доступен глобально.
Это самый частый юзкейс для пакета https://github.com/uuidjs/uuid и если другие версии или валидация не нужна, смело дропайте.
GitHub
GitHub - uuidjs/uuid: Generate RFC-compliant UUIDs in JavaScript
Generate RFC-compliant UUIDs in JavaScript. Contribute to uuidjs/uuid development by creating an account on GitHub.
👍63❤14
fetch() performance parity
Из скриншота всё должно быть понятно.
Вот такая вот дорога от экспериментальной фичи до самого быстрого http клиента в ноде. Ну и вот само ишью.
У Маттео есть даже стрим об этом — Improving Node.js fetch() by 10% - From flamegraph to implementation!
P.S. Мне лично тяжко смотреть такие долгие стримы, но из них обычно можно подчерпнуть какие-то новые привычки и оптимизации воркфлоу.
Из скриншота всё должно быть понятно.
Вот такая вот дорога от экспериментальной фичи до самого быстрого http клиента в ноде. Ну и вот само ишью.
У Маттео есть даже стрим об этом — Improving Node.js fetch() by 10% - From flamegraph to implementation!
P.S. Мне лично тяжко смотреть такие долгие стримы, но из них обычно можно подчерпнуть какие-то новые привычки и оптимизации воркфлоу.
👍39❤4😱1
И в догонку статью про внутренне устройство undici — HTTP Fundamentals: Understanding Undici and its Working Mechanism
❤17👍1
Node.js 22 is now available!
Вышла 22 нода, которая станет LTS в октябре. Важных изменений много!
---------
1. Support require()ing synchronous ESM graphs
Что ж, взяли опыт bun, который, на сколько я понимаю, нарушает спеку. Кажется, что все в восторге, но я думаю радоваться пока рано. Подождём пока фича станет стабильной (сейчас нужно запускать ноду с флагом
Кстати, фичу затащила Joyee Cheung, о которой мы с вами ещё поговорим!
---------
2. Watch Mode (node --watch)
Для простых кейсов, nodemon, получается, больше не нужен
---------
3. glob and globSync
Супер! Я каждый раз мучался в выборе библиотеки для глоба. Забавно, что изначально эту функциональность затащили ради встроенного тест-раннера , а теперь она доступна и в fs модуле.
---------
4. Running package.json scripts
Теперь можно запускать скрипты из package.json в обход пакетного менеджера —
---------
Релиз-пост:
https://nodejs.org/en/blog/announcements/v22-release-announce
Вышла 22 нода, которая станет LTS в октябре. Важных изменений много!
---------
1. Support require()ing synchronous ESM graphs
Что ж, взяли опыт bun, который, на сколько я понимаю, нарушает спеку. Кажется, что все в восторге, но я думаю радоваться пока рано. Подождём пока фича станет стабильной (сейчас нужно запускать ноду с флагом
--experimental-require-module). А там глядишь и проблема миграции на ESM уйдет. Сейчас ситуация катастрофическая.Кстати, фичу затащила Joyee Cheung, о которой мы с вами ещё поговорим!
---------
2. Watch Mode (node --watch)
Для простых кейсов, nodemon, получается, больше не нужен
---------
3. glob and globSync
Супер! Я каждый раз мучался в выборе библиотеки для глоба. Забавно, что изначально эту функциональность затащили ради встроенного тест-раннера , а теперь она доступна и в fs модуле.
---------
4. Running package.json scripts
Теперь можно запускать скрипты из package.json в обход пакетного менеджера —
node --run <script-in-package-json>. Кажется, самая спорная фича. 212 комментариев в пул-реквесте на 352 строки! Нода испытывает большой кризис в области пакетных менеджеров — вновь разгорелась дискуссия на счёт corepack, а этот пр отчётливо показывает, что в команде нет чёткого мнения на счёт того, что должно быть в ноде, а что нет. Но и об этом тоже как-нибудь в отдельном посте.---------
Релиз-пост:
https://nodejs.org/en/blog/announcements/v22-release-announce
👍43❤10
TypeScript 5.5 Beta
Вышла новая бета ТС и самое интересное, если не долгожданное, это Isolated Declarations.
Работа над это штукой началась больше двух лет назад при участии людей из Майкрософта, Блумберга и Гугла.
Тайпскрипт использует d.ts файлы для проверки типов, когда мы используем библиотеки. А чтобы сгенерировать d.ts нужно осуществить полный тайпчек и уже после записать d.ts на диск.
Таким образом в монорепе нельзя начать проверку типов у одного пакета, пока не завершена проверка его зависимостей. Это ограничение становится узким горлышком и не даёт максимизировать параллельность.
Основная идея — не совершать полный тайпчек и генерировать d.ts на основе типов, указанных для возвращаемого значения.
Т.е. вместо
нужно будет явно указывать
Если тип возвращаемого значения можно вычислить на основе только текущего файла, то и указывать его ручками не придётся. Т.е. все файлы обрабатываются изолированно друг от друга, импорты между ними игнорируются.
Чтобы тайпскрипт работал в таком режиме, нужно включить опцию
Готовиться к этому режиму и уже сейчас включать
В целом это отличная оптимизация. Но она не даётся бесплатно — нам придётся писать чуть больше типов, но большинство проблем можно будет исправлять автоматически. Посмотрим, как фича эволюционирует в следующих версиях.
Ну а основной релиз этой версии ТС состоится 18 июня
Релиз-пост:
https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-beta/
Вышла новая бета ТС и самое интересное, если не долгожданное, это Isolated Declarations.
Работа над это штукой началась больше двух лет назад при участии людей из Майкрософта, Блумберга и Гугла.
Тайпскрипт использует d.ts файлы для проверки типов, когда мы используем библиотеки. А чтобы сгенерировать d.ts нужно осуществить полный тайпчек и уже после записать d.ts на диск.
Таким образом в монорепе нельзя начать проверку типов у одного пакета, пока не завершена проверка его зависимостей. Это ограничение становится узким горлышком и не даёт максимизировать параллельность.
Основная идея — не совершать полный тайпчек и генерировать d.ts на основе типов, указанных для возвращаемого значения.
Т.е. вместо
export function foo() {
return x;
}
нужно будет явно указывать
export function foo(): string {
return x;
}
Если тип возвращаемого значения можно вычислить на основе только текущего файла, то и указывать его ручками не придётся. Т.е. все файлы обрабатываются изолированно друг от друга, импорты между ними игнорируются.
Чтобы тайпскрипт работал в таком режиме, нужно включить опцию
isolatedDeclarations. На текущий момент это влияет только на вычисление типов. По сути этот режим является некой валидацией. В будущем скорей всего у tsc появится отдельный режим (или cli) именно для компиляции d.ts. Уже сейчас есть API transpileDeclaration, но использовать его напрямую нет смысла, т.к. пока что всё равно будет происходить полная проверка типов.Готовиться к этому режиму и уже сейчас включать
isolatedDeclarations тоже не стоит, т.к. придётся руками указывать типы для каждой экспортируемой функции. В будущем для большинства (или всех) таких ошибок будут атоматические фиксы В целом это отличная оптимизация. Но она не даётся бесплатно — нам придётся писать чуть больше типов, но большинство проблем можно будет исправлять автоматически. Посмотрим, как фича эволюционирует в следующих версиях.
Ну а основной релиз этой версии ТС состоится 18 июня
Релиз-пост:
https://devblogs.microsoft.com/typescript/announcing-typescript-5-5-beta/
👍45❤2
Forwarded from Стой под стрелой (Nikita Prokopov)
Ну что, кот вылез из мешка (сорян, вы же хотели, чтобы я русский не забывал?), вышел подкаст Бирмана, в котором я рассказываю про Гит. Вообще идите послушайте, а я тут коротенько наброшу.
Я шутил в твиттере, что «люди которые пользуются консольным Гитом, кажется, не слишком хорошо его понимают и это повод копнуть поглубже» что было переделыванием аналогичной фразы про гуевый Гит.
Так вот, я считаю, что консольный Гит это конечно крутое кун-фу, но это сложность ради сложности (смотрите, я собрал корабль в бутылке, причем обе руки были завязаны за спиной), но какого-то особого «глубокого» понимания он не дает. Я офигенно знаю Гит (ну, я так думаю) и пользуюсь исключительно гуем, потому что — ну а нафига страдать?
Беда всех консольных интерфейсов — что они работают в парадигме запрос-ответ, «ты сначала спроси, а мы потом покажем». Это плохая парадигма, хорошая — вот смотри все что есть, если нужно, уточняй.
Вторая беда — они всегда показывают прошлое. То есть я ветку уже удалил, но если на экране есть вывод предыдущей
(мне сейчас скажут, что у них условный oh-my-zsh запрашивает и печатает ветку после каждого нажатия enter, на что я скажу: вы что, ебанутые? ^W^W^W вот мы и начали делать gui колхозными средствами)
Ну и в целом многие вещи исходно требуют графического представления (diff-ы, лог), которое консольному интерфейсу приходится как-то колхозить. Для чего, для кого? Зачем вы страдаете, мистер Андерсон?
Вторая часть моих претензий связана с ебанутостью конкретно git-ового cli.
- Например, команды, которые и не существительные, и не глаголы (`git checkout`/`git branch`).
- Команды, которые полностью меняют свой смысл в зависимости от ключа (`git branch`,
- Команды, которые полностью меняют свой смысл от аргумента (`git checkout`).
- Неконсистентный словарь (staging, index, cache — это все одно и то же).
- Команды, которые очевидно создавались заплаткой поверх других команд. Попробуйте понять логически, что с чем сравнивает команда
- Git status, который пишет «You are up to date», даже не сходив в интернет и ничего не проверив! Распределенная система контроля версий боится ходить в сеть!
- Просто идиосинкразия удаления файла через
- То, что стеш автоматически не стешится (правда, это во многих gui тоже так)
- Отсутствует анду. А это, между прочим, столп вообще любого человеко-компьютерного взаимодействия.
Короче, если ты все это запомнил, то молодец! У тебя большая память, высокий болевой порог и ты любишь хранить бессмыслицу на своем чердаке. Ты наверное и всех американских президентов можешь перечислить по порядку?
В общем, you do you, конечно, но меня раздражает, что эта вот пытка считается чем-то вроде badge of honor, чем-то, чем люди прям гордятся. А на деле самый обычный стокгольмский синдром.
Конечно, это не отменяет того, что какой-то конкретный GUI для гита тоже может быть плохим! Условный VS Code, в котором одна кнопка sync, которая делает и пуш и пулл и черт знает что еще, да, действительно, с такой каши не сваришь.
Но бывают и хорошие ведь! Условный Sublime Merge снимает почти все головняки консоли и при этом не идет против правды и показывает вещи как есть. И это просто хорошо сделанная обертка, даже не переосмысление самой работы с DVCS.
Короче, дискурс «нАдО сИдЕтЬ в КоНсОлЕ» вредит и развитию инструментов, и доступности профессии для новичков. Да и вам самим было бы легче, просто кто-то фильмов про хакеров насмотрелся с зелеными буквами. На терминале свет клином не сошелся, алло!
Я шутил в твиттере, что «люди которые пользуются консольным Гитом, кажется, не слишком хорошо его понимают и это повод копнуть поглубже» что было переделыванием аналогичной фразы про гуевый Гит.
Так вот, я считаю, что консольный Гит это конечно крутое кун-фу, но это сложность ради сложности (смотрите, я собрал корабль в бутылке, причем обе руки были завязаны за спиной), но какого-то особого «глубокого» понимания он не дает. Я офигенно знаю Гит (ну, я так думаю) и пользуюсь исключительно гуем, потому что — ну а нафига страдать?
Беда всех консольных интерфейсов — что они работают в парадигме запрос-ответ, «ты сначала спроси, а мы потом покажем». Это плохая парадигма, хорошая — вот смотри все что есть, если нужно, уточняй.
Вторая беда — они всегда показывают прошлое. То есть я ветку уже удалил, но если на экране есть вывод предыдущей
git branch -a, то он не обновится. Вот ты и сидишь и спрашиваешь постоянно: где я? кто я? какой сейчас статус? Закоммитить не в ту ветку — одна из самых частых ошибок, потому что ветка нигде не написана.(мне сейчас скажут, что у них условный oh-my-zsh запрашивает и печатает ветку после каждого нажатия enter, на что я скажу: вы что, ебанутые? ^W^W^W вот мы и начали делать gui колхозными средствами)
Ну и в целом многие вещи исходно требуют графического представления (diff-ы, лог), которое консольному интерфейсу приходится как-то колхозить. Для чего, для кого? Зачем вы страдаете, мистер Андерсон?
Вторая часть моих претензий связана с ебанутостью конкретно git-ового cli.
- Например, команды, которые и не существительные, и не глаголы (`git checkout`/`git branch`).
- Команды, которые полностью меняют свой смысл в зависимости от ключа (`git branch`,
git branch -l, git branch -d, `git checkout --merge`).- Команды, которые полностью меняют свой смысл от аргумента (`git checkout`).
- Неконсистентный словарь (staging, index, cache — это все одно и то же).
- Команды, которые очевидно создавались заплаткой поверх других команд. Попробуйте понять логически, что с чем сравнивает команда
git diff --cached- Git status, который пишет «You are up to date», даже не сходив в интернет и ничего не проверив! Распределенная система контроля версий боится ходить в сеть!
- Просто идиосинкразия удаления файла через
git add- То, что стеш автоматически не стешится (правда, это во многих gui тоже так)
- Отсутствует анду. А это, между прочим, столп вообще любого человеко-компьютерного взаимодействия.
Короче, если ты все это запомнил, то молодец! У тебя большая память, высокий болевой порог и ты любишь хранить бессмыслицу на своем чердаке. Ты наверное и всех американских президентов можешь перечислить по порядку?
В общем, you do you, конечно, но меня раздражает, что эта вот пытка считается чем-то вроде badge of honor, чем-то, чем люди прям гордятся. А на деле самый обычный стокгольмский синдром.
Конечно, это не отменяет того, что какой-то конкретный GUI для гита тоже может быть плохим! Условный VS Code, в котором одна кнопка sync, которая делает и пуш и пулл и черт знает что еще, да, действительно, с такой каши не сваришь.
Но бывают и хорошие ведь! Условный Sublime Merge снимает почти все головняки консоли и при этом не идет против правды и показывает вещи как есть. И это просто хорошо сделанная обертка, даже не переосмысление самой работы с DVCS.
Короче, дискурс «нАдО сИдЕтЬ в КоНсОлЕ» вредит и развитию инструментов, и доступности профессии для новичков. Да и вам самим было бы легче, просто кто-то фильмов про хакеров насмотрелся с зелеными буквами. На терминале свет клином не сошелся, алло!
👍66👎16🥱5