Osome linter presentation

Почему это важно?

Наши ценности как платформенной команды

Быть рычагом продуктовых команд, а не становиться gate keeper'ами или bottleneck'ом
Тратить время на важное, а не на рутину

Где мы сейчас?

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

🥺 Платформенная команда вручную смотрит каждый пр спек

🥺 Платформенная команда форсирует стайлгайд вручную

🥺 Платформенная команда иногда растягивает ревью спек на 2-3 дня

Погружаемся в данные

Чего хотелось бы добиться в итоге?

Идеальная ситуация в выдуманном мире:

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

Хорошая ситуация:

Человек из продуктовой команды открывает пр, его смотрит платформенная команда, но обсуждения по стилистике неймингу и принципам сведены к нулю

Гипотеза: кажется нам нужно автоматизировать этот процесс, используя линтер

Принципы выбора решения

Текущая реализация языка tinyspec неподдерживаемая и тяжело расширяемая

Tinyspec - one pass compiler

Tinyspec базируется на регулярных выражениях

Такие сложные регулярные выражения приносят в компиляторы не только нерасширяемость, но и недерминистичность синтаксиса. То есть другими словами никто доподлинно сейчас не ответит какую комбинацию символов и newlin'ов тайниспек сможет распарсить а какую нет.

`/industries`:
    $L /industries ?branch?

Обратная совместимость с текущей реализацией*

Breaking changes

Запрещаем теги для эндпоинтов без ``

❌ bad

Kek: 
POST /industies

✅ good

`Kek`: 
POST /industies

Запрещаем inline query

❌ bad

POST /industies?filter=

✅ good

POST /industies?SomeQuery

Запрещаем new:message синтакс для ключей объектов

WSEventsFromServerForAgent {
  messages:new?: WSOnNewMessageForAgent,
  messages:update?: WSOnUpdateMessageForAgent,
}

Запрещаем $CRUDL

@token $CRUDL /conversations/:id/messages

Легкость поддержки любым разработчиком

Нет регулярных выражений
0 зависимостей на уровне языка (peg.js, yak, tree-sitter, bison)

Расширяемость линтера

😍 Возможность писать кастомные правила

😍 Удобный интерфейс (абстракция) для описания правил

Demo time!

Rule typecheck

Возможность постепенной миграции

Потенцаильная возможность для развития и поддержки данной технологии

https://app.codecov.io/gh/frolovdev/anyspec

https://frolovdev.github.io/anyspec/modules.html

Не отставать от современного opensource и идти в ногу со временем

На текущий момент tinyspec не совместим с форматом openapi

Историческая справка

Openapi стал популярен в момент выхода спецификации v2. Примерно в это время появился tinyspec. Tinyspec позиционируется как DSL совместимый с openapi v2

Openapi3 сейчас чаще всего называется Swagger

Сила спецификации в том, что когда ты читаешь спецификацию, можно ожидать от программ имплементирующих данную спецификацию, что они будут работать корректно - в соответствии с данной спецификацией

Действительно ли tinyspec следует openapi2?

Это ложь

AnyOf никогда не был частью openapi v2

Мы застряли в чистилище между двумя спецификациями и придумываем нашу собственную

Почему вообще использовать openapi 2, когда по всему миру шагает openapi 3?

https://apis.guru/awesome-openapi3/

https://awesomeopensource.com/projects/openapi3

https://github.com/DragorWW/awesome-swagger

✨ Текущая реализация языка tinyspec неподдерживаемая и тяжело расширяемая

✨ Обратная совместимость с текущей реализацией*

✨ Легкость поддержки любыми разработчиками

✨ Линтер должен быть легко расширяемым новыми правилами, правило можно писать из вне

✨ Возможность постепенной миграции

✨ Потенцаильная возможность для развития и поддержки данной технологии

✨ Не отставать от современного opensource и идти в ногу со временем

Demo time!

What's next?

🚀 Printer (WIP) - watch an example in slack

🚀 Compiler (WIP)

🚀 Обучение и презентации для продуктовых команд

🚀 Документация

https://www.figma.com/file/D2MQKMxhxflBd2Pxw8di9D/Anyspec?node-id=0%3A1

Roadmap