

Shuttle — платформа з відкритим кодом для інфраструктури як коду (IaC), орієнтована на Rust, для розгортання застосунків у хмарі. Цього тижня компанія запустила Neptune, нову пропозицію, що пришвидшує розгортання застосунків. Хоча розробники можуть генерувати цілі бекенди за лічені хвилини, розгортання застосунку все одно може вимагати днів налаштувань. Саме тут вступає Neptune, зараз у бета-версії. Neptune — це «інженер платформи на базі штучного інтелекту», повністю мова-незалежний і підключається до будь‑якого репозиторію або інструмента кодування на базі ШІ. У блозі його порівнюють із Docker для бекенд‑інфраструктури. «Це AI‑native інженер платформи, який розуміє ваш код, знає що йому потрібно і забезпечує повний хмарний стек — безпечно, передбачувано та швидко», — компанія заявила у блозі. «Він еволюціонує від помічника з розгортання до справжнього інженера платформи на базі ШІ, який розуміє ваш код, планує розумно і автоматично забезпечує інфраструктуру.» У дописі також зазначено, що Neptune інтегрується з IDE‑копілотами та агентами для повноцінних діалогових розгортувань. Також він не прив’язаний до конкретної хмари та розширюваний: підтримує AWS, GCP та Azure через модель плагінів. Neptune поєднує простоту PaaS із можливістю використати власний хмарний акаунт та пропонує гнучкість IaC, але позбавляє циклу технічного обслуговування, додав допис. «Оскільки ваша інфраструктура є детерміністичною специфікацією, вона завжди відповідає вашому коду — і не відстає від нього», заявила команда. «Це забезпечує майже нуль витрат на обслуговування і зводить до мінімуму розрив між кодом і хмарою.» Neptune працює шляхом з’єднання трьох компонентів у єдину узгоджену систему: детерміністичну специфікацію, керувальну площину Kubernetes‑native та AI‑робочий процес, що ґрунтується на реальних метаданих інфраструктури, йшло у дописі. Разом ці три компоненти перетворюють намір застосунку на готову до продакшну хмарну архітектуру з мінімальними налаштуваннями. Бета Neptune відкрита для ранніх розробників. Виявлено вразливості у React Server Components. Цього тижня дослідники з безпеки виявили ще дві вразливості у React Server Components — одна з яких дозволяє здійснити атаку відмови в обслуговуванні — про що повідомляє блог React. Нові проблеми включають вразливість високої серйозності до відмови в обслуговуванні та середнього рівня серйозності витоку вихідного коду. Команда React рекомендувала розробникам негайно оновитися. Крім того, якщо ви вже оновились через критичну вразливість безпеки минулого тижня, вам потрібно оновитися знову, попередили у команді. «Якщо ви оновилися до 19.0.2, 19.1.3 та 19.2.2, ці оновлення неповні, отже вам потрібно оновитися знову», повідомила команда. Якщо код React у вашому застосунку не використовує сервер, застосунок також не піддається цим вразливостям, додала команда React. Застосунки також не зазнають впливу, якщо вони не використовують фреймворк, збирач або плагін збірника, що підтримує React Server Components. Наступні фреймворки React та збірники піддаються впливу: Next.js, React Router, Waku, @parcel/rsc, @vite/rsc-plugin та rwsdk. Microsoft пропонує оновлення щодо прогресу TypeScript 7.0. Даніель Розенвасер, провідний менеджер продукту TypeScript, нещодавно опублікував оновлення щодо зусиль мови з портування компілятора та сервісу мови до нативного коду. Цей проєкт — під назвою Project Corsa — допоможе використати кращу вихідну продуктивність, більш ефективне використання пам’яті та паралелізм, написав він. Перш за все, він запропонував погляд на переписану підтримку редактора та мовного сервісу. Мовний сервіс — це те, що живить можливості редактора для TypeScript та JavaScript, пояснив він. Хоча команда ще портирує можливості та виправляє незначні помилки, багато з того, що робить існуючий досвід редагування TypeScript, вже на місці й працює, зокрема: кодові підказки (у тому числі автопідстановка імпорту), перехід до визначення, перехід до визначення типу, переходи до реалізації, пошук всіх посилань; Ієрархія викликів; Символи документа. «Ви можете помітити кілька речей, що виділяються від нашого останнього великого оновлення — автопідстановка імпорту, пошук всіх посилань, перейменування тощо», — писав він. «Ми знаємо, що ці можливості були відсутні частиною, що стримувала багато розробників від випробувань нативних попередніх версій. Ми раді сказати, що вони зараз перепроєктовані й готові для повсякденного використання!» Вони також перебудували частини мовного сервісу, щоб підвищити надійність, водночас використовуючи паралелізм спільної пам’яті, додав він. «Нова архітектура більш надійна і повинна впоратися з кодовими базами, як великі, так і маленькі, без проблем», сказав він. «Хоча ще є чим портвати та доопрацьовувати, ваша команда, швидше за все, зрозуміє, що випробування нативних попередніх версій TypeScript варте того. Очікуйте швидшого завантаження, меншого використання пам’яті та більш чутливого/відзивчивого редактора в цілому.» Також є прогрес у компіляторі в нативному порті. Одне з питань, яке він часто отримує, — чи безпечно використовувати TypeScript 7 для валідації збірки; тобто чи надійно воно знаходить ті самі помилки, що й TypeScript 5.9? «Відповідь — безсумнівно так», — написав Розенвасер. «Ви можете впевнено використовувати TypeScript 7 уже сьогодні для перевірки типів вашого проєкту на помилки.» TypeScript 7.0 не підтримуватиме існуючий Strada API, зазначив він. API Corsa все ще в процесі розробки й немає стабільної інструментальної інтеграції для нього; що означає, що будь-які інструменти (такі як лінтери, форматери або розширення IDE), що залежать від Strada API, не працюватимуть з Corsa. «Обхідним шляхом для деяких цих проблем може бути встановлення пакетів typescript та @typescript/native-preview поруч один з одним, використання API ≤6.0 для інструментів, які його потребують, разом із tsgo для перевірки типів», зазначив він.