Добро пожаловать в мой блог! Изначально он не задумывался как блог CRM разработчика, но жизнь сама внесла нужные коррективы. Тут я публикою все свои наблюдения относительно обозначенных в заголовке систем. Если Вы найдете в нем что-то интересное для Вас, как для заказчика, то буду рад сотрудничать с Вами! В моей компетенции 100% задач по MS CRM 3.0/4.0/2011:
![](http://www.axforum.info/forums/blog_attachment.php?attachmentid=80&stc=1&d=1296211379)
![](http://www.axforum.info/forums/blog_attachment.php?attachmentid=100&stc=1&d=1296211379)
MVP 2010, 2011
- Консалтинг
- Проектирование
- Разработка
- Обучение
MVP 2010, 2011
Динозавр осваивает Modern Web - Часть пятая
Запись от Артем Enot Грунин размещена 27.10.2017 в 13:32
Часть пятая - Как работает сборка?
Предыдущая статья серии: Динозавр осваивает Modern Web - Часть четвертая
В прошлой статье мы с вами успешно собрали и разместили в CRM наше первое приложение на React. Теперь осталось понять почему все так сложно и где там был сам реакт. В общем-то это нормальная реакция человека, который только начал во все это погружаться. Непривычные инструменты, новый синтаксис и идеология собьют с толку кого угодно. Но, не все так плохо. Давайте разбираться как все это работает!
Для это вернемся в студию и посмотрим из чего состоит наш проект. Начнем в порядке значимости - с файла package.json. Не путать с packages.config! У них похожи не только названия, но и назначения. packages.config - это список NuGet пакетов, которые используются в решении, а package.json - это, в некотором роде, конфигурация NPM (менеджера пакетов Node):
![Название: 01 explorer.png
Просмотров: 5861
Размер: 23.6 Кб](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=413&d=1509100108)
В корне этого файла описывается информация о нашем пакете на тот случай если мы захотим разместить его в NPM. Это, пожалуй, ключевое отличие от NuGet каждый проект - кандидат сдать утилитой в другом проекте. Далее, идут разделы dependencies, devDependencies и scripts:
![Нажмите на изображение для увеличения
Название: 02 package.png
Просмотров: 348
Размер: 33.7 Кб
ID: 414](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=414&thumb=1&d=1509100108)
Раздел dependencies - аналог Reference в .NET. Тут содержится перечень своих, или сторонних "библиотек", которые нужны для работы нашего приложения. В данном случае, количество зависимостей минимально - это библиотеки react и react-dom, которые всегда идут в паре. Насколько понял, их разделили, чтобы независимо развивать React Native - библиотеку для работы с мобильными приложениями. Здесь же мы видим библиотеку react-scripts-ts, которая, вообще-то инструмент разработки, а не библиотека, которую мы используем в своем решении, но разработчикам должно быть виднее. Видимо какие-то ее части нужны для работы приложения, которое компилируется по этому шаблону.
Раздел devDependencies похож на предыдущий, с той лишь разницей, что он содержит компоненты, которые не войдут в приложение, но используются как инструментарий для его создания. В данном случае мы видим несколько библиотек @types. Зачем они нужны мы разберем чуть позже. Если кратко, это некий аналог h. -(header) файлов в C/C++, но для TypeScript. Они добавляют недостающие описания типов для библиотек которые написаны на чистом JS, чтобы лучше работала подсветка синтаксиса, а компилятор TypeScript мог лучше отлеживать типы данных.
Раздел "scripts" отвечает за ту магию, которая выполняется командами start и build, а также теми, которые мы еще не использовали. Команда start является стандартной, поэтому может использоваться без инструкции run, а остальные должны использоваться с ней. Например:
Обратите внимание, что все команды выполняются при помощи инструмента react-scripts-ts. Именно он делает за нас всю работу по горячей загрузке обновленных файлов во время отладки и сборку готового решения по команде build.
Идем далее. Папка "node modules". Как нетрудно догадаться, сюда будут складываться все пакеты из разделов dependencies и devDependencies. Нужно отметить, что студия имеет встроенную поддержку NPM и сама умеет "читать" изменения в package.json. Если мы добавим какой-то модуль, он автоматически будет скачан и размещен в каталоге node modules. Важный момент! Версия Node, которая входит в состав студии может быть устаревшей. Это может приводить к проблемам при загрузке пакетов, или при запуске команд из окна студии.
Чтобы этого избежать, щелкните правой кнопкой на файле package.json и выберите Configure External Tools:
![Нажмите на изображение для увеличения
Название: 03 configure.png
Просмотров: 432
Размер: 24.2 Кб
ID: 415](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=415&thumb=1&d=1509100117)
В открывшемся окне, нужно переместить PATH на верхнюю строчку:
![Нажмите на изображение для увеличения
Название: 04 path.png
Просмотров: 416
Размер: 38.9 Кб
ID: 416](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=416&thumb=1&d=1509100117)
Теперь студия будет использовать ту же версию Node, которую мы используем в консоли.
Следующие два файла, которые отвечают за конфигурацию решения - это tsconfig.json и tslint.json. Первый из них - файл конфига компилятора TypeScript. Он отсутствует в версии create-react-app c использованием Java Script. Второй - настройки другого специфичного инструмента - линтера. Изначально линт - это программа проверки исходных кодов для языка C на предмет типовых ошибок и корявых конструкций, типа if (a=1). Позже, линтерами стали называть весь класс подобных программ. В большинстве случаев, вы не будете изменять эти конфиги. Оба этих инструмента поддерживаются студией, так что все ошибки компиляции, или варнинги линтера вы увидите в консоли ошибок:
![Название: 05 lint.png
Просмотров: 5789
Размер: 18.0 Кб](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=417&d=1509100128)
Все прочие элементы решения отвечают за его наполнение, а не настройку. Подробно назначение каждого из них описано в документации по create-react-app: https://github.com/facebookincubator...-configuration, так что я расскажу лишь о них лишь кратко. По концепции решения, все исполняемые файлы должны быть расположены в каталоге src. Именно там сборщик будет искать наши TypeScript файлы для компиляции. В папке public должны быть расположены статичные "асеты" проекта, такие как картинки, библиотеки, которые недоступны через NPM и пр. файлы, которые не нужно "компилировать". Так же, тут располагается шаблон стартовой страницы index.html над которым тоже поработает сборщик. В частности, в страницу автоматически будут добавлены ссылки на скомпилированные скрипты.
Давайте теперь посмотрим, как выглядит сам сборщик. Если вы пробовали что-то делать по мануалам из интернета, вы наверняка провели несколько увлекательных минут с настройкой вебпака, который мы пока что совершенно не касались. Что ж, самое время оценить тот колоссальный труд, который проделала команда разработки create-react-app, чтобы избавить нас от необходимости настраивать сборку от проекта к проекту.
Для этого, откроем консоль в корне решения и выполним
Эта операция необратима, о чем нас честно предупредят. Возможно вы захотите сохранить резервную копию проекта до ее выполнения.
В итоге мы увидим, что в наш проект добавилось много всего нового:
![Нажмите на изображение для увеличения
Название: 06 eject.png
Просмотров: 353
Размер: 53.1 Кб
ID: 418](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=418&thumb=1&d=1509100128)
Изменился и package.json. В него добавилось много новых зависимостей, которые заботливо прятал от нас пакет react-scripts-ts. Изменилась и секция со скриптами. Мы по-прежнему можем выполнить build и start, но теперь вместо react-scripts-ts будут выполняться локальные скрипты в каталоге проекта.
Давайте теперь обновим каталог решения в Solution Explorer и перейдем в новый каталог "config" где находится сердце нашего сборщика - файл конфигурации webpack:
![Название: 07 webpack.png
Просмотров: 5855
Размер: 19.0 Кб](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=419&d=1509100135)
В одной из прошлых статей этой серии, мы выяснили, что сборка модерн веб приложений, как правило делается с использованием этого инструмента. Сразу скажу, что конфигурация не обязана быть такой монструозной. Чаще всего достаточно конфига на 5-10 строчек, но тут мы видим высший пилотаж! Почти 300 строк хитрой конфигурации, оптимизации и компоновки решения, на выходе из которой мы и получим наши уродливые имена файлов. Впрочем, теперь мы можем все изменить!
Давайте откроем webpack.config.prod.js и найдем в нем следующий фрагмент:
![Нажмите на изображение для увеличения
Название: 08 loaders.png
Просмотров: 425
Размер: 30.5 Кб
ID: 420](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=420&thumb=1&d=1509100135)
Загрузчики (loaders) - это элемент процесса сборки, который отвечает за выбор инструмента "компиляции" для каждого конкретного файла. Давайте уберем вхождение блока [hash:8] во всех загрузчиках, чтобы убрать хеши из имен файлов. Дополнительно придется поискать по ключевому слову hash, чтобы найти другие места конфига, где они могут использоваться, например:
const cssFilename = 'static/css/[name].[contenthash:8].css';
filename: 'static/js/[name].[chunkhash:8].js',
chunkFilename: 'static/js/[name].[chunkhash:8].chunk.js',
Так же следует закомментировать подключение плагина SWPrecacheWebpackPlugin, так как он, в любом случае не будет работать в CRM.
Если все было сделано правильно, мы получим приемлемый "статичный" билд:
![Название: 09 static.png
Просмотров: 5861
Размер: 14.1 Кб](//axforum.info/forums/blog_attachment.php?s=032f4b02fcaf7024d94e1d9068b6f0c8&attachmentid=421&d=1509100140)
Не забудьте убрать хэши из имен файлов в spkl.json, так как теперь мы в них не нуждаемся.
И вот мы, наконец, разобрались как создать, скомпилировать и опубликовать решение в CRM. Осталось понять кто такие React и TypeScript и чем они могут быть нам полезны. Об этом я расскажу в следующих статьях серии.
Предыдущая статья серии: Динозавр осваивает Modern Web - Часть четвертая
В прошлой статье мы с вами успешно собрали и разместили в CRM наше первое приложение на React. Теперь осталось понять почему все так сложно и где там был сам реакт. В общем-то это нормальная реакция человека, который только начал во все это погружаться. Непривычные инструменты, новый синтаксис и идеология собьют с толку кого угодно. Но, не все так плохо. Давайте разбираться как все это работает!
Для это вернемся в студию и посмотрим из чего состоит наш проект. Начнем в порядке значимости - с файла package.json. Не путать с packages.config! У них похожи не только названия, но и назначения. packages.config - это список NuGet пакетов, которые используются в решении, а package.json - это, в некотором роде, конфигурация NPM (менеджера пакетов Node):
В корне этого файла описывается информация о нашем пакете на тот случай если мы захотим разместить его в NPM. Это, пожалуй, ключевое отличие от NuGet каждый проект - кандидат сдать утилитой в другом проекте. Далее, идут разделы dependencies, devDependencies и scripts:
Раздел dependencies - аналог Reference в .NET. Тут содержится перечень своих, или сторонних "библиотек", которые нужны для работы нашего приложения. В данном случае, количество зависимостей минимально - это библиотеки react и react-dom, которые всегда идут в паре. Насколько понял, их разделили, чтобы независимо развивать React Native - библиотеку для работы с мобильными приложениями. Здесь же мы видим библиотеку react-scripts-ts, которая, вообще-то инструмент разработки, а не библиотека, которую мы используем в своем решении, но разработчикам должно быть виднее. Видимо какие-то ее части нужны для работы приложения, которое компилируется по этому шаблону.
Раздел devDependencies похож на предыдущий, с той лишь разницей, что он содержит компоненты, которые не войдут в приложение, но используются как инструментарий для его создания. В данном случае мы видим несколько библиотек @types. Зачем они нужны мы разберем чуть позже. Если кратко, это некий аналог h. -(header) файлов в C/C++, но для TypeScript. Они добавляют недостающие описания типов для библиотек которые написаны на чистом JS, чтобы лучше работала подсветка синтаксиса, а компилятор TypeScript мог лучше отлеживать типы данных.
Раздел "scripts" отвечает за ту магию, которая выполняется командами start и build, а также теми, которые мы еще не использовали. Команда start является стандартной, поэтому может использоваться без инструкции run, а остальные должны использоваться с ней. Например:
X++:
npm run test
Идем далее. Папка "node modules". Как нетрудно догадаться, сюда будут складываться все пакеты из разделов dependencies и devDependencies. Нужно отметить, что студия имеет встроенную поддержку NPM и сама умеет "читать" изменения в package.json. Если мы добавим какой-то модуль, он автоматически будет скачан и размещен в каталоге node modules. Важный момент! Версия Node, которая входит в состав студии может быть устаревшей. Это может приводить к проблемам при загрузке пакетов, или при запуске команд из окна студии.
Чтобы этого избежать, щелкните правой кнопкой на файле package.json и выберите Configure External Tools:
В открывшемся окне, нужно переместить PATH на верхнюю строчку:
Теперь студия будет использовать ту же версию Node, которую мы используем в консоли.
Следующие два файла, которые отвечают за конфигурацию решения - это tsconfig.json и tslint.json. Первый из них - файл конфига компилятора TypeScript. Он отсутствует в версии create-react-app c использованием Java Script. Второй - настройки другого специфичного инструмента - линтера. Изначально линт - это программа проверки исходных кодов для языка C на предмет типовых ошибок и корявых конструкций, типа if (a=1). Позже, линтерами стали называть весь класс подобных программ. В большинстве случаев, вы не будете изменять эти конфиги. Оба этих инструмента поддерживаются студией, так что все ошибки компиляции, или варнинги линтера вы увидите в консоли ошибок:
Все прочие элементы решения отвечают за его наполнение, а не настройку. Подробно назначение каждого из них описано в документации по create-react-app: https://github.com/facebookincubator...-configuration, так что я расскажу лишь о них лишь кратко. По концепции решения, все исполняемые файлы должны быть расположены в каталоге src. Именно там сборщик будет искать наши TypeScript файлы для компиляции. В папке public должны быть расположены статичные "асеты" проекта, такие как картинки, библиотеки, которые недоступны через NPM и пр. файлы, которые не нужно "компилировать". Так же, тут располагается шаблон стартовой страницы index.html над которым тоже поработает сборщик. В частности, в страницу автоматически будут добавлены ссылки на скомпилированные скрипты.
Давайте теперь посмотрим, как выглядит сам сборщик. Если вы пробовали что-то делать по мануалам из интернета, вы наверняка провели несколько увлекательных минут с настройкой вебпака, который мы пока что совершенно не касались. Что ж, самое время оценить тот колоссальный труд, который проделала команда разработки create-react-app, чтобы избавить нас от необходимости настраивать сборку от проекта к проекту.
Для этого, откроем консоль в корне решения и выполним
X++:
npm run eject
В итоге мы увидим, что в наш проект добавилось много всего нового:
Изменился и package.json. В него добавилось много новых зависимостей, которые заботливо прятал от нас пакет react-scripts-ts. Изменилась и секция со скриптами. Мы по-прежнему можем выполнить build и start, но теперь вместо react-scripts-ts будут выполняться локальные скрипты в каталоге проекта.
Давайте теперь обновим каталог решения в Solution Explorer и перейдем в новый каталог "config" где находится сердце нашего сборщика - файл конфигурации webpack:
В одной из прошлых статей этой серии, мы выяснили, что сборка модерн веб приложений, как правило делается с использованием этого инструмента. Сразу скажу, что конфигурация не обязана быть такой монструозной. Чаще всего достаточно конфига на 5-10 строчек, но тут мы видим высший пилотаж! Почти 300 строк хитрой конфигурации, оптимизации и компоновки решения, на выходе из которой мы и получим наши уродливые имена файлов. Впрочем, теперь мы можем все изменить!
Давайте откроем webpack.config.prod.js и найдем в нем следующий фрагмент:
Загрузчики (loaders) - это элемент процесса сборки, который отвечает за выбор инструмента "компиляции" для каждого конкретного файла. Давайте уберем вхождение блока [hash:8] во всех загрузчиках, чтобы убрать хеши из имен файлов. Дополнительно придется поискать по ключевому слову hash, чтобы найти другие места конфига, где они могут использоваться, например:
const cssFilename = 'static/css/[name].[contenthash:8].css';
filename: 'static/js/[name].[chunkhash:8].js',
chunkFilename: 'static/js/[name].[chunkhash:8].chunk.js',
Так же следует закомментировать подключение плагина SWPrecacheWebpackPlugin, так как он, в любом случае не будет работать в CRM.
Если все было сделано правильно, мы получим приемлемый "статичный" билд:
Не забудьте убрать хэши из имен файлов в spkl.json, так как теперь мы в них не нуждаемся.
И вот мы, наконец, разобрались как создать, скомпилировать и опубликовать решение в CRM. Осталось понять кто такие React и TypeScript и чем они могут быть нам полезны. Об этом я расскажу в следующих статьях серии.
Всего комментариев 0