Definitelytyped: META — Обновление минимальной версии TypeScript

Когда был добавлен unknown ? Со щитом или на щите! Все any в DT, безусловно, являются крупнейшим источником ошибок типа «машинописный текст должен был его поймать» в этих частях.

Когда был добавлен unknown ?

3.0

ты. Итак, 99,9%!

Я согласен, что мы должны это сделать. Давай сделаем это!

Пожалуйста, не могли бы вы вместо этого медленно увеличивать его с течением времени? 2.1 в один месяц, 2.2 в следующий и так далее?

Каждая версия имеет небольшие критические изменения. Будет легче понять, какие проблемы это приносит, если сначала действовать медленно и методично.

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

Да, пожалуйста, типизация node особенно пострадала из-за отсутствия новых функций, и пришлось использовать множество ~хаков~ обходных путей.

Проекты @JoshuaKGoldberg в режиме обслуживания вряд ли будут обновлять версии определений типов месяц за месяцем, да?

@JoshuaKGoldberg помните, что обновление DT не удаляет исторические определения типов, которые уже были опубликованы в npm. Исторические версии @types живут вечно, как Мумм-Ра.

Вы сможете положиться на них независимо от того, куда пойдет DT с точки зрения версий.

Имеет смысл

Привет @RyanCavanaugh ,
Поддерживаю такую ​​идею на 100%. TypeScript v2.0 блокирует лучшую систему типов для многих пакетов, включая node .
Я забочусь о прозрачности и предсказуемости для сообщества и бизнеса . Есть вопросы:

• Когда, по вашему мнению, самое время изменить версию TypeScript с минимальной поддержкой? Во время выпуска TS 3.7?
• Поправьте меня, если я ошибаюсь, но это похоже на конец жизни для версий TypeScript до 2.8?
• Можем ли мы иметь график, аналогичный Node.js ? Такой документ поможет командам разработчиков подтолкнуть бизнес к утверждению ресурсов разработки для обновления.

По какой причине это 2.8, а не другая версия? (Например, 3.0 для unknown .)

2.8, когда были введены условные типы

Сильно за.

Пожалуйста, пока вы этим занимаетесь, рассмотрите возможность создания (полу-)формального расписания, чтобы сообщество могло рассчитывать на предсказуемый рост минимальной версии с течением времени. Что-то вроде: «Каждый год в ноябре мы планируем обновить минимальную версию машинописного текста до версии, выпущенной за 18 месяцев до этого. Пожалуйста, спланируйте это соответствующим образом».

@donaldpipowitch
Среди пользователей до 3.0 мы видели группу людей, все еще использующих 2.8. (И, конечно, условные типы делают 2.8 популярной целью для типов DT, как указывает @IllusionMH .)

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

@галкин
Технически старые версии Typescript вообще не обслуживаются, и это изменение является остановкой обслуживания от Definitely Typed. И, конечно же, старые версии Typescript могут продолжать получать существующие версии пакетов DT. Они просто не будут получать обновления.

Однако это всего лишь техническая особенность. Для нас было бы неплохо составить расписание, подобное LTS. Мы еще ничего подобного не начинали. В этом случае данные были достаточно четкими, чтобы было легко принять постфактумное решение. Я еще не уверен, как предсказать хорошую дату для будущих устареваний.

Re: дата: я все равно должен обновить инфраструктуру DT для 3.7, так что это произойдет в день выпуска 3.7 как часть выпуска.

Для нас было бы неплохо составить расписание, подобное LTS.

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

@johnnyreilly мы ищем прецедент в Microsoft. Тем не менее, нет ничего лучше, чем Definitely Typed!

@RyanCavanaugh , какие-нибудь обновления?

@galkin , если у вас есть предлагаемый график устаревания, опубликуйте его в этой теме, чтобы мы могли обсудить.

@sandersn , вот что я думаю по этому поводу

• Нужен ли нам End-of-life (EOL) для версии TypeScript?
  Да конечно. Поддержка каждой созданной версии TypeScript требует избыточных ресурсов.
• Почему у нас должен быть график EOL?
  _Наилучшая практика — просто быть откровенным и четко сообщать о состоянии своих проектов. Если вы больше не поддерживаете проект или находитесь в процессе его свертывания, сделайте это до боли очевидным для любого, кто наткнется на ваш код_ (c) Джаред Смит.
• Что следует использовать в качестве основы для графика?
  Аналитика? Каждое решение, основанное на аналитике, — компромисс. Каждое такое решение является ответом на вопрос, какую часть сообщества/бизнеса мы будем дразнить. WordPress имеет аналогичную проблему, какую минимальную версию WP/PHP/MySQL они должны поддерживать. Это опасный путь.
  Расписание зависимого инструмента? Визуальный код/Microsoft Azure/Angular/и т. д. Слишком много вариантов и слишком легко начать новую священную войну.
  Процесс TC39? Хороший вариант, но TC39 не вводит и не будет вводить EoL для какой-либо языковой функции.
  Node.js? Node.js — это драйвер для JS-сообщества с графиком выпуска/конечной загрузки. TypeScript использует Node.js. Я вижу это как лучшую основу для графика.
• Как составить расписание?
  Вариант 1. Свяжите версию TypeScript с версией Node.js и объявите аналогичный EOL. Например, 2 года назад Node.js v8 запустил LTS , а TypeScript v2.6 был выпущен , поэтому 2019.12.31 — это EOL.
  Вариант 2 Node.js имеет политику 12 + 18 месяцев до EOL. Мы можем использовать тот же подход, 2,5 года. Это может быть слишком долго, но не менее 2 лет.
  Вариант 3. Проведите встречу с лицами, принимающими решения, и поделитесь с сообществом результатами, как это было

Итак, мое предложение выглядит примерно так:

версия | Выпущен | Конец жизни через 2,5 года | Конец жизни через 2 года
-- | -- | -- | --
2.1 | Декабрь 2016 | Июнь 2019 | декабрь 2018 г.
2.2 | Февраль 2017 | август 2019 | февраль 2019
2.3 | Апрель 2017 | Сентябрь 2019 | апрель 2019 г.
2.4 | Июнь 2017 | Ноябрь 2019 | июнь 2019 г.
2,5 | август 2017 г. | Январь 2020 | август 2019 г.
2,6 | Октябрь 2017 | март 2020 г. | Октябрь 2019
2,7 | Январь 2018 | июль 2020 г. | январь 2020 г.
2,8 | март 2018 г. | август 2020 | февраль 2020 г.
2,9 | май 2018 | Октябрь 2020 | апрель 2020 г.
3 | июль 2018 | декабрь 2020 | июнь 2020 г.
3.1 | Сентябрь 2018 | март 2021 | август 2020 г.
3.2 | Ноябрь 2018 | май 2021 | Октябрь 2020 г.
3.3 | Январь 2019 | июль 2021 | декабрь 2020 г.
3.4 | Март 2019 | август 2021 | февраль 2021 г.
3,5 | Май 2019 | Октябрь 2021 | апрель 2021 г.
3.6 | август 2019 | Январь 2022 | июль 2021 г.
3.7 | Ноябрь 2019 | май 2022 г. | октябрь 2021 г.

Вау, это потрясающе! Спасибо за мысль, которую вы вложили в это.

Пара мелких моментов:

1. Определенно Typed и Typescript — это разные проекты, хотя у них должен быть одинаковый график EOL.
2. Что означает EOL для DT, изложено выше, но не так ясно для TS. Насколько мне известно, мы никогда не создавали версию исправления более чем на одну второстепенную версию. С другой стороны, мы не рекомендовали более новые версии TS людям, кроме как в качестве общей практики или для конкретных обходных путей.
3. Поскольку TS поставляется как часть Visual Studio, платного продукта с контрактами на поддержку, нам, возможно, придется определить специфичное для VS расширение для любого определенного периода поддержки с открытым исходным кодом. Однако это не должно повлиять на сообщество открытого исходного кода.

@DanielRosenwasser , ты не против взглянуть на это, когда у тебя будет время?

2,8 теперь новый минимум. 2.0–2.7 больше не будут тестироваться, а теги ts2.0–ts2.7 больше не будут обновляться в существующих пакетах @types/* . Пользователи до версии 2.8, установившие @types/*@latest , могут получить типы, которые им не подходят.

Я не собираюсь закрывать этот вопрос, так как он продолжается (и кроме того, это метавопрос?).

@sandersn означает ли это, что проверка, которая обычно проверяет, что зависимость имеет большую или равную (например, произвольный пакет (2.x с x> 1, ссылающийся на другой пакет с x = 1) версия, теперь отключена?

Спрашиваю, потому что это основная блокировка продвижения типов узлов вперед.

@SimonSchick нет, это не отключено; это применимо только к заголовкам, которые требуют >=2.8 .

Другими словами, вы не можете обновить @types/node до версии 3.1, потому что существует множество пакетов, в которых указана версия 2.8 или 2.4, которая считается 2.8. Но теперь вы определенно можете потребовать @types/node 2.8. Это означает, что вы можете использовать условные типы, и вы можете предположить, что семантика 2.8+ применяется там, где она отличается от старых версий.

На самом деле по умолчанию стоит 2.8, так что вообще отсутствие требуемой версии в шапке эквивалентно требованию 2.8.

@sandersn , мы можем поговорить о новом обновлении минимальной версии? Я думаю, что это хорошее время, потому что была выпущена версия 3.8.

Мы обсуждали это внутри компании и склоняемся к поддержке 30-месячного графика в стиле узла. Но мне нужно координировать свои действия с командой интеграции Typescript-VS, которая хочет иметь график поддержки для нового-TS-в-старом-VS, поэтому я еще не пытался возобновить обсуждение; если мы закончим с 30-месячным сроком, следующее устаревание будет в августе, так что у нас есть немного времени.

Обновление: я поговорил с командой Typescript-Javascript на VS, и они выбрали график на 2 или 2,5 года. Они собираются собрать некоторые данные об использовании, чтобы помочь им выбрать между ними. Я также получил их сценарий назад - это поддержка старого-TS-в-новом-VS.

Основываясь на наших данных об использовании, собранных ранее [1], я предпочитаю двухлетнее окно просто для того, чтобы уменьшить нагрузку на техническое обслуживание. Это также позволяет важным пакетам начать использовать новые функции на 6 месяцев раньше без необходимости обновления зависимых пакетов. Короткое окно поддержки не имеет практических недостатков, которые я видел до сих пор.

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

[1]
Данные перепечатаны сверху:

• Телеметрия показывает, что 99,9% пользователей VS Code имеют версию 3.0 или новее.
• Телеметрия показывает, что 97% пользователей VS используют версию 3.0 или новее.
• 20% пакетов DT уже выбрали версию 2.8 или новее.

Я предпочитаю более короткое окно; как по причинам снижения нагрузки на обслуживание, так и с учетом данных, которые вы обнаружили @sandersn.

Спасибо за обновления!

Также для более короткого окна.

Длинное окно принесет пользу только тем, кто будет обновлять только часть своих зависимостей, но никогда не будет набирать текст, и это должна быть только очень небольшая группа.
В большинстве случаев люди либо регулярно обновляют все свои зависимости (включая typescript), либо вообще ничего не обновляют.
Или наоборот: большинство разработчиков, которые не удосужились обновить свой TypeScript в течение двух лет, вероятно, вообще не заботятся о свежих пакетах и ​​свежих определениях типов.
Так что это, вероятно, повредит гораздо меньшему количеству людей, чем вы можете подозревать, и это удерживает всю экосистему от развития.

TL;ДР; @sandersn , что ты думаешь о 18 месяцах?

Мои мысли :

я написал

Вариант 2 Node.js имеет политику 12 + 18 месяцев до EOL. Мы можем использовать тот же подход, 2,5 года. Это может быть слишком долго, но не менее 2 лет.

но я не могу вспомнить, почему я думал, что 2 года - это правильный период времени. Я не могу логически обосновать эти 2 года. Сейчас, на свежую голову, мне кажется, что там должно было быть ..., but not less 18 months .

Каждая основная версия, на которую распространяется план LTS, будет активно поддерживаться в течение 12 месяцев с даты перехода на LTS-план. После этих 12 месяцев активной поддержки основная версия перейдет в режим «обслуживания» еще на 18 месяцев. До Node.js 12 активный период составлял 18 месяцев, а период обслуживания — 12 месяцев. (c) План выпуска Node.js

Мотивация : каждая версия TypeScipt сначала выпускается как rc/beta. Таким образом, каждый стабильный выпуск имеет режим обслуживания с первого дня, и 18 месяцев достаточно.

Это логично. Но если мы используем 18 месяцев в качестве окна, мы устарели бы 3.1 в марте 2020 года. Учитывая, что наша телеметрия показала, что значительное количество пользователей VS все еще используют 3.1, я не думаю, что 3.1 следует устареть.

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

Показатели использования 3.1 в VS не снижались так сильно с конца октября. Интересно, что 95% использования приходится на версии 3.9 - 3.4.

Я думаю, что 3.1 все еще используется так часто, потому что VS позволит вам не обновлять машинописный текст при загрузке обновлений, но я не уверен. Несмотря на это, такое поведение, вероятно, сохранится в будущих версиях VS, а также в других IDE, которые обновляются не так часто.

Таким образом, для поддержки 98% пользователей VS нам нужно 2-летнее окно. Чтобы поддерживать 95%, нам нужно окно всего в 1 год! Но нет особого смысла иметь что-то среднее.

Я все еще поддерживаю 2 года на основе этих данных.

Мне кажется, дискуссия здесь свернута. Я собираюсь пойти с 2-летним окном поддержки.

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

У меня есть PR, который добавляет документацию в файл README #42834.

Я перевел изменения документации на русский язык #42881.

Может ли кто-нибудь помочь с изменениями перевода на:

• README.cn.md
• README.es.md
• README.ko.md

@kingwl @armanio123 @saschanaz — самые вовлеченные машинистки, которых я знаю и которые являются носителями этих трех языков.

(Конечно, вы можете игнорировать это, если вы слишком заняты.)

Задача добавляет перевод изменений в #42834?

Я перевел изменения документации на русский язык #42818.

Это #42881 😁

да.

Задача добавляет перевод изменений в #42834?

Я перевел изменения документации на русский язык #42818.

Это #42881 😁

Фиксированный. Извините, я сделал опечатку.

Обновление: одновременно с выпуском 3.9 я просто удалил поддержку 2.8.

Я отложил устаревание по двум причинам.

1 Общая задержка covid-19.

1. Мы находимся в процессе переключения инфраструктуры публикации типов на монорепозиторий, который публикует в пространстве имен @definitelytyped/* . Обновление версии теперь является частью этого монорепозитория. К сожалению, мы все еще ждем, когда офис MS с открытым исходным кодом сделает монорепозиторий с открытым исходным кодом, но это должно произойти в ближайшее время.

Несмотря на то, что релиза 4.0 не будет в мае, я все же удалю поддержку 2.9 в мае, как и планировал. С новой настройкой должно быть немного проще.