Давайте исправим старую добрую командную строку

1656658820 davajte ispravim staruyu dobruyu komandnuyu stroku

Мануэль Вилла

NwMQt4ad-SbG67ijjjaymWKVKL6hgtt-Jvyg

Хотя у нас есть хороший графический интерфейс пользователя, кажется, что мы используем все больше и больше инструментов командной строки. И хотя многие из них действительно хороши, я думаю, что они могли бы быть еще лучше, если бы базировались на более современной основе.

Чтобы показать проблему, я рассмотрю две основные характеристики: возможность настройки и удобство использования. И, рассматривая некоторые из наиболее популярных инструментов, я покажу, насколько трудно добиться обеих характеристик одновременно.

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

Создать приложение React

Create React App иллюстрирует случай инструмента, который очень прост в использовании, но не слишком настраивается. Он объединяет набор инструментов, приёмов и лучших практик, чтобы мгновенно запустить современную веб-программу.

В этом плане он чрезвычайно ценен, но реализован как черный ящик. Трудно что-либо изменить внутри. Да есть eject но я не думаю, что это реальное решение. Это замена одной характеристики другой. Инструмент становится более настраиваемым, но становится непростым в использовании.

скрипты npm и конкретный код

Здесь мы имеем самый высокий уровень настраиваемости, но удобство использования низкое. Составляя сценарии npm и специальный код, можно создавать любые конструкторы, развертыватели и т.д. Но это не для всех, и это достаточно трудоемкая задача. Собирать набор инструментов с помощью сценариев npm (т.е. Bash) не совсем удобно для пользователя, а написание кода в JavaScript для настройки и управления инструментами через модули npm несколько громоздко.

webpack, gulp, Serverless Framework и т.д.

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

Проблема в том, что каждый раз, когда инструмент предлагает систему плагинов, он создает новую экосистему. В результате вместо того, чтобы иметь глобальную экосистему инструментов, мы получаем распространение экосистем, функционирующих изолированно. Следовательно, многие плагины делают то же, но для разных экосистем (например, awesome-typescript-loader, gulp-typescript, serverless-plugin-typescriptтому подобное). Какая трата времени.

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

bknkJrgYXw8sDcmt4QdpnNeRsPTm5Rq078t0

*nix, Bash и т.д.

Не поймите меня неправильно. Все инструменты, которые я упомянул раньше, фантастические. Учитывая основы, на которых они базируются, у них это отлично получается. Я имею в виду, что им приходится бороться с Unix-подобными системами и оболочками, такими как Bash. Можете ли вы поверить, что все наши современные инструменты базируются на фундаменте, почти не изменившемся почти за полвека?

Как правило, когда мы работаем над проектом, мы используем несколько инструментов, таких как (в случае современного веб-проекта), менеджер зависимостей, транспиллер, бандлер и так далее. Следовательно, нам необходим способ установить, настроить и создать все эти вещи. К сожалению, наша старая добрая командная строка не очень хорошо справляется с этим.

Мы используем файлы конфигурации на основе многих различных форматов для настройки наших инструментов. Мы общаемся с ними через массив строк (argv). Для их создания существует, ну, Bash… Наконец, поскольку типичные оболочки не могут работать с несколькими версиями одного инструмента, управление нашей средой разработки болезненно, когда нам приходится иметь дело со многими проектами.

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

Привет, «ресурсы»

Я целый год работал полный рабочий день, пытаясь решить эту проблему, и в результате получил то, что называю «ресурсом». Кроме того, как доказательство концепции, я создал Run, среду выполнения ресурсов.

Итак, для чего нужен ресурс? По сути ресурс добавляет к инструментам объектно-ориентированный интерфейс, что облегчает их использование как из командной строки, так и программно с других инструментов.

Если вы создаете инструмент, вы можете объединить его в ресурс, чтобы улучшить его удобство в использовании и сэкономить много времени на разработку. Во-первых, поскольку Run автоматически устанавливает инструменты, проблема установки исчезает. Тогда, учитывая, что пользователи настраивают инструменты с помощью ресурсов, вам не нужно управлять конфигурационными файлами. Наконец вам больше не нужно внедрять интерфейс командной строки. Run предоставляет это вам.

Если вы конечный разработчик и работаете над программой, веб-сайтом, серверной частью и т.д., вы можете воспользоваться ресурсом, чтобы получить ссылки на инструменты, необходимые вашему проекту, и указать их конфигурацию. Тогда, поскольку ваша среда разработки определена в одном файле, ваш проект очень легко транспортировать и делиться. Просто возьмите ресурс и все готово. Кроме того, поскольку ваш ресурс использует инструменты, которые сами являются ресурсами, все становится очень легко настроить, создать и использовать.

На что это похоже?

Ресурс – это документ JSON или YAML, в котором можно указать следующее:

  • Инструменты, которые используют ресурс (наследуя или создавая их)
  • Набор атрибутов (для настройки инструментов)
  • Набор методов (для добавления настраиваемого поведения)

Например, чтобы создать веб-сайт, вы можете начать с чего-то следующего:

{  "@import": "aws/s3-hosted-website#^0.1.0"}

Затем, вызвав Run без аргументов:

run

Вы получаете автоматически сформированную справку, отображающую содержимое вашего ресурса:

f1pzp0tOzgb4CAuXr60GlBWOg9wo3FJ-uTED

Ибо ресурс импортирует "aws/s3-hosted-website", он наследует ряд атрибутов и методов Давайте укажем некоторые атрибуты:

{  "@import": "aws/s3-hosted-website#^0.1.0",  "domainName": "www.example.com",  "contentDirectory": "./content"}

Наконец, давайте вызовем deploy метод:

run deploy

Вуаль! Ваш веб-сайт онлайн. Как что до этого "aws/s3-hosted-website#^0.1.0" вещь? Это ссылка на ресурс, реализующий инструмент для управления статическими веб-сайтами, размещенными на AWS. И чтобы облегчить использование, он хранится в каталоге ресурсов.

Я достаточно интенсивно работал с ресурсами в течение многих месяцев, и действительно кажется, что дилемма настраиваемости и удобства использования решена. К примеру, вот ресурс для более реалистичного веб-сайта, включая зависимости npm (без package.json файл!) и a build метод, запускающий транспиллер, бандлер и копировщик файлов:

{  "@import": ["aws/s3-hosted-website#^0.1.0", "js/resource#^0.1.0"],  "domainName": "www.example.com",  "contentDirectory": "./build",  "dependencies": {    "color": "^3.0.0",    "lodash": "^4.17.4"  },  "build": {    "@type": "method",    "@run": ["transpiler run", "bundler run", "copier run"]  },  "transpiler": {    "@import": "js/transpiler#^0.1.0",    "source": "./src",    "destination": "./dist",    "targets": {"chrome": "41", "safari": "10", "firefox": "50"},    "format": "esm"  },  "bundler": {    "@import": "js/bundler#^0.1.0",    "entry": "./dist/index.js",    "output": "./build/bundle.js",    "target": "browser",    "format": "iife"  },  "copier": {    "@import": "tool/file-copier#^0.1.0",    "sourceDirectory": "./",    "destinationDirectory": "./build",    "files": ["./index.html", "./images"]  }}

Достаточно легко, вам не кажется? Если вы заблудились, автоматически сгенерированная справка Run станет вашим советчиком. Например, чтобы узнать больше о бандлере, просто вызовите:

run bundler

Вы должны увидеть что-то вроде этого:

LHZGwRocjigwamqLwwv7RiJFLpA618ONAv1v

Вывод

Я не говорю, что концепция ресурса – это Святой Грааль, но это лучшее, что я нашел сейчас, и работа над ней продолжается. Технические характеристики еще не стабильны; все может поменяться, даже заглавие «ресурс» может поменяться.

Чтобы узнать больше о текущем состоянии Run и ресурсов, вы можете просмотреть документацию и репозиторий GitHub.

Итак, что вы думаете? Это только у меня проблема с командной строчкой? Или это нужно что-то исправить? И если да, считаете ли вы, что эта концепция ресурса является шагом в правильном направлении?

Добавить комментарий

Ваш адрес email не будет опубликован.