Меню Рубрики

Установка babel на сервер

Настройка babel7 и webpack dev server

В этом курсе мы настроим шаблон Webpack 4, подключим babel 7, а также разберемся с webpack dev server. Подключим js библиотеки на примере vue.js и bootstrap, настроим loaders. Ниже более полное видео по Webpack dev server и настройки babel7, в статье мы пробежимся по основным моментам из видео.

  • Сборку мы пишем единожды и далее мы переиспользуем ее из проекта в проект.
  • Вебпак можно использовать как угодно. Например, в верстке сайтов или создании полноценного SPA. Также вебпак (и именно его) используют при сборки приложений для десктопа и мобильных приложений (используя, конечно-же, фреймворки)

Webpack и gulp отличия

Для начала нужно поговорить про отличия gulp и webpack. Во превых в вебпаке есть точка входа в которую мы складируем все наши библиотеки, скрипты, css файлы и так далее. В галпе такого файла нету это не очень удобно.

Как это делается в галпе: когда вы хотите установить или подключить библиотеку нужно останавливать сервер и прописывать библиотеку в общий конфиг в строгой последовательности , далее снова запускать сервер. Может показаться простым, но представьте теперь, что у вас 6 библиотек и вам самим нужно думать в какой последовательности их подключить чтобы они нормально взаимодействовали между собой или, наоборот — никак друг с другом не пересекались. Это уже настоящая боль.

Что в этом плане делает вебпак? Вы все также устанавливаете библиотеку через нпм. Далее вам не нужно останавливать сервер и следовать четкому порядку вебпак сам все подключит и сделает это правильно, раставив в конечном файле app.js все библиотеки в нужном порядке.

Что быстрее webpack или gulp?

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

Исходя из этих отличий выбор очевиден — webpack. Но если вы новичок, которому все выше сказанное показалось белым шумом — лучше начать с галпа. В таком случае, спустя какое-то время, когда вы пересядете на вебпак — вы почувствуете всю его силу и мощь!

Инициализация вебпака

далее нужно следовать тому, что скажет npm либо просто набрать

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

Установка webpack-dev-server

Эта команда установит все необходимые пакеты для дальнейшей работы

После этого в файле package.json появится следующее:

Создание dev и build ярлыков для сборки webpack

Теперь можно создать 2 ярлыка для сборки и дев разработки. В файле package.json описываем эти ярлыки:

Создание файла webpack.config.js

Опишем начальный конфиг в файле webpack.config.js который нужно создать.

В файле index.html также нужно прописать путь к нашему app.js

Создание точки входа

Теперь создадим точку входа, про которую говорили выше. для этого создадим папку src в которой будет файл index.js это и есть наша точка входа (пока что единственная). Подключим в нее сторонний срипт common.js и создадим его в новой папке js.

Файл inxex.js будет выглядить так:

Файл common (который мы импортируем из папки js) будет следующим:

То есть — обычная стрелочная функция, которая в дальнейшем перекомпилируется в ES4 или ES5 (по желанию) и сделаем это для того, чтобы наш код работал даже в старике IE или базовом браузере мозилы.

Установка и настройка bable 7

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

Для установки в консоли пропишем

Обработка файлов js через babel-loader

В конфигурациях вебпака прописываем

В этом регулярном выражении мы обрабатываем все js файлы через. babel-loader при этом исключая папку node_modules

Теперь создаем файл .babelrc в который прописываем

Вот и все, теперь наш js код обрабатывается бейблом и перегоняется в старый, валидный, синтаксис.

источник

Использование Babel и Webpack для настройки React-проекта с нуля

Существует немало инструментов, позволяющих подготовить среду для React-разработки. Например, в наших материалах учебного курса по React используется средство create-react-app, позволяющее создать шаблонный проект, содержащий всё необходимое для разработки React-приложений. Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как самостоятельно настроить окружение для разработки React-проектов с использованием Babel и Webpack. Эти инструменты используются и в проектах, создаваемых средствами create-react-app, и мы полагаем, что всем, кто изучает React-разработку, интересно будет познакомиться с ними и с методикой создания React-проектов на более глубоком уровне. А именно, речь пойдёт о том, как сконфигурировать Webpack таким образом, чтобы это средство использовало бы Babel для компиляции JSX-кода в JavaScript-код, и как настроить сервер, используемый при разработке React-проектов.

Webpack

Webpack используется для компиляции JavaScript-модулей. Этот инструмент часто называют «бандлером» (от bundler) или «сборщиком модулей». После его установки работать с ним можно, используя интерфейс командной строки или его API. Если вы не знакомы с Webpack — рекомендуется почитать об основных принципах его работы и посмотреть его сравнение с другими сборщиками модулей. Вот как, на высоком уровне, выглядит то, что делает Webpack.

Webpack берёт всё, от чего зависит проект, и преобразует это в статические ресурсы, которые могут быть переданы клиенту. Упаковка приложений — это очень важно, так как большинство браузеров ограничивает возможности по одновременной загрузке ресурсов. Кроме того, это позволяет экономить трафик, отправляя клиенту лишь то, что ему нужно. В частности, Webpack использует внутренний кэш, благодаря чему модули загружаются на клиент лишь один раз, что, в итоге, приводит к ускорению загрузки сайтов.

Babel

Babel — это транспилятор, который, в основном, используется для преобразования конструкций, принятых в свежих версиях стандарта ECMAScript, в вид, понятный как современным, так и не самым новым браузерам и другим средам, в которых может выполняться JavaScript. Babel, кроме того, умеет преобразовывать в JavaScript и JSX-код, используя @babel/preset-react.

Именно благодаря Babel мы, при разработке React-приложений, можем пользоваться JSX. Например, вот код, в котором используется JSX:

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

, в котором содержится текст Hello world! , выделенный жирным шрифтом. А вот пример кода, делающего то же самое, в котором JSX не используется:

Преимущества первого примера перед вторым очевидны.

Предварительные требования

Для того чтобы настроить проект React-приложения, нам понадобятся следующие npm-модули.

  • react — библиотека React.
  • react-dom — библиотека, которая поможет нам использовать возможности React в браузере.
  • babel/core — транспиляция JSX в JS.
  • babel/preset-env — создание кода, подходящего для старых браузеров.
  • babel/preset-react — настройка транспилятора для работы с React-кодом.
  • babel-loader — настройка Webpack для работы с Babel.
  • css-loader — настройка Webpack для работы с CSS.
  • webpack — сборка модулей.
  • webpack-cli — работа с Webpack из командной строки.
  • style-loader — загрузка всего используемого CSS-кода в заголовке HTML-файла.
  • webpack-dev-server — настройка сервера разработки.

Теперь создадим, в папке react-scratch , новый проект с помощью npm ( npm init ) и установим некоторые из вышеперечисленных пакетов следующей командой:

Точкой входа в программу будет файл index.js , который содержится в папке src , находящейся в корневой директории проекта. Ниже показана структура этого проекта. Некоторые файлы и папки создаются автоматически, некоторые вам нужно будет создать самостоятельно.

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

Папка component будет содержать компоненты проекта (в нашем случае тут присутствует лишь один компонент). В папке dist , в файле main.js , будет находиться скомпилированный код, а index.html — это, как уже было сказано, главный HTML-файл нашего приложения.

Настройка Webpack

Webpack можно настраивать разными способами. В частности, настройки этого инструмента могут принимать вид аргументов командной строки или присутствовать в проекте в виде конфигурационного файла с именем webpack.config.js . В нём нужно описать и экспортировать объект, содержащий настройки. Мы начнём настройку этого файла с описания объекта, выглядящего так (мы будем рассматривать его по частям, а ниже приведём его полный код):

Свойство entry задаёт главный файл с исходным кодом проекта. Значение свойства mode указывает на тип окружения для компиляции (в нашем случае это окружение разработки — development ) и на то, куда нужно поместить скомпилированный файл.

Работа над проектом

Поместим в файл index.html нашего проекта, расположенный в папке dist , следующий код:

Обратите внимание на тег script , присутствующий в этом файле. Он указывает на файл main.js , который будет получен в ходе компиляции проекта. Элемент

с идентификатором root мы будем использовать для вывода React-приложения.

Теперь установим пакеты react и react-dom:

Внесём в index.js следующий код:

Это — стандартный код для подобных файлов React-приложений. Тут мы подключаем библиотеки, подключаем файл компонента и выводим приложение в тег

Вот код файла app.component.js :

Вот код файла app.component.css :

Настройка Babel

Babel — это транспилятор, обладающий огромными возможностями. В частности, он умеет преобразовывать LESS в CSS, JSX в JS, TypeScript в JS. Мы будем использовать с ним лишь две конфигурации — react и env (их ещё называют «пресетами»). Babel можно настраивать по-разному, в частности, речь идёт о средствах командной строки, о специальном файле с настройками, о стандартном файле package.json . Нас устроит последний вариант. Добавим в package.json следующий раздел:

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

Настройка Webpack на работу с Babel

Тут мы воспользуемся библиотекой babel-loader, которая позволит использовать Babel с Webpack. Фактически, речь идёт о том, что Babel сможет перехватывать и обрабатывать файлы до их обработки Webpack.

▍JS-файлы

Вот правила, касающиеся работы с JS-файлами (этот код пойдёт в файл webpack.config.js ), они представляют собой одно из свойств объекта с настройками, экспортируемого этим файлом:

В свойстве rules представленного здесь объекта хранится массив правил, в соответствии с которыми должен быть обработан файл, заданный регулярным выражением, описанным в свойстве test . В данном случае правило будет применяться ко всем файлам с расширениями .m и .js , при этом файлы из папок node_modules и bower_components мы транспилировать не хотим. Далее, тут мы указываем, что мы хотим пользоваться babel-loader. После этого наши JS-файлы будут сначала обрабатываться средствами Babel, а потом упаковываться с помощью Webpack.

▍CSS-файлы

Добавим в массив rules объекта module настройки для обработки CSS-файлов:

Задачу обработки CSS-файлов мы будем решать средствами style-loader и css-loader. Свойство use может принимать массив объектов или строк. Загрузчики вызываются, начиная с последнего, поэтому наши файлы сначала будут обработаны с помощью css-loader. Мы настроили это средство, записав в свойство modules объекта options значение true . Благодаря этому CSS-стили будут применяться лишь к тем компонентам, в которые они импортированы. Css-loader разрешит команды импорта в CSS-файлах, после чего style-loader добавит то, что получится, в форме тега style , в разделе страницы:

▍Статические ресурсы

Продолжим работу над объектом настроек module , описав в нём правила обработки статических ресурсов:

Если система встретит файл с расширением PNG, SVG, JPG или GIF, то для обработки такого файла будет использован file-loader. Обработка таких файлов важна для правильной подготовки и оптимизации проекта.

Настройка сервера разработки

Теперь, в файле webpack.config.js , настроим сервер разработки:

Свойство contentBase объекта с настройками devServer указывает на папку, в которой расположены наши ресурсы и файл index.html . Свойство port позволяет задать порт, который будет прослушивать сервер. Свойство watchContentBase позволяет реализовать наблюдение за изменениями файлов в папке, задаваемой свойством contentBase .

Вот полный код файла webpack.config.js :

Теперь внесём в package.json , в раздел scripts , команду для запуска сервера разработки и команду для запуска сборки проекта:

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

Если теперь перейти по адресу http://localhost:9000, можно будет увидеть страницу нашего проекта.

Страница проекта в браузере

Для того чтобы собрать проект воспользуйтесь следующей командой:

После этого можно будет открыть файл index.html в браузере и увидеть то же самое, что можно было видеть, запустив сервер разработки и перейдя по адресу http://localhost:9000.

Итоги

В этом материале приведён обзор настройки Webpack и Babel для их использования в React-проектах. На самом деле, на той базе, которую мы сегодня разобрали, можно создавать гораздо более сложные конфигурации. Например, вместо CSS можно воспользоваться LESS, вместо обычного JS писать на TypeScript. При необходимости можно, например, настроить минификацию файлов и многое другое. Конечно, если сегодня состоялось ваше первое знакомство с процессом самостоятельной настройки React-проектов, вам может показаться, что всё это очень сложно и куда легче воспользоваться готовым шаблоном. Однако после того, как вы немного в этом разберётесь, вы поймёте, что некоторое увеличение сложности настроек даёт вам большую свободу, позволяя настраивать свои проекты именно так, как вам это нужно, не полагаясь полностью на некие «стандартные» решения и снизив свою зависимость от них.

Уважаемые читатели! Какой подход вы чаще всего используете при подготовке рабочей среды для React-проектов?

источник

Babel

Итак, мы знаем, что есть спецификация, а есть ее реализация. Знаем, что реализация зачастую отстает от спецификации. Более того, разные реализации по-разному отстают от спецификации. Написав код, мы не можем гарантировать, где он будет запускаться, а где — нет.

Исходя из этого можно сделать вывод, что нужно писать код, придерживаясь старых стандартов. К счастью, есть другой путь: мы можем писать код с использованием всех возможных фич, но перед публикацией автоматически транслировать его (то есть переводить из одного вида в другой) в старую версию. Звучит сложно, но на практике все просто.

Сама природа JS и его способы использования готовят нас к тому, что никогда не настанет светлых времен с современными рантаймами (средами исполнения, интерпретаторами js-кода). Люди использовали и продолжат использовать разные браузеры и разные версии браузеров, разные версии Node.js и так далее. Использование новых синтаксических конструкций в такой ситуации практически невозможно. Запуск кода на платформе, не поддерживающей новый синтаксис приведет к синтаксической ошибке. Закономерным решением этой проблемы стало появление Babel — программы, которая берет указанный код и возвращает тот же код, но транслированный в старую версию JS. Фактически, в современном мире Babel стал неотъемлемой частью JS. Его не используют только в старых проектах, также называемых легаси-проектами. Все новые проекты так или иначе делают с его использованием.

У Babel есть собственный онлайн REPL. Попробуйте вставить туда любой код, который вы писали на Хекслете, и посмотрите, во что он превратится. Такая трансляция называется транспайлингом, а сам Babel называют транспайлером, от transpiler.

Babel состоит из многих частей:

  • Пакет @babel/core содержит код, который выполняет всю работу по трансляции, но не содержит внутри себя правил преобразования. Правила описаны в отдельных пакетах, называемых плагинами (например, babel-plugin-transform-constant-string).
  • @babel/preset-env. Пресет — это группа плагинов, которую можно подключить к Babel целиком. preset-env — основной пресет поддерживаемый командой Babel, который содержит внутри себя плагины, реализующие стандартизированные возможности js.
  • Пакет @babel/cli обеспечивает возможность работы с бабелем через терминал. Предоставляет командную утилиту babel. Ниже рассматривается ее использование.
  • Пакет @babel/node — еще одна утилита командной строки: babel-node. Подробнее далее.

Установка

Настройка

Babel полагается на наличие файла babel.config.js в корне проекта. Именно через него он узнает, как нужно транслировать код.

Этот файл нужно создать самостоятельно. Если вы забудете добавить туда плагин или пресет, то на выходе Babel отдаст тот же код, что был и на входе.

Разные среды исполнения поддерживают (или не поддерживают) разные возможности и синтаксические конструкции языка. В свойстве targets перечисляются конкретные окружения (и их версии), для которых пишете код. Если код предназначен для выполнения на nodejs, то достаточно указать только его. В таком случае babel будет транслировать конструкции, поддерживаемые на nodejs, и ничего лишнего:

Минимально достаточно подключить пресет @babel/preset-env. Он добавляет возможности JS, которые входят в стандарт.

Использование

При появлении в проекте Babel, изменяется файловая структура проекта. Так как код существует в двух состояниях: исходном и транслированном, то удобно создать две директории, под каждый набор исходников. Исходный код, принято хранить в директории src в корне проекта, а код полученный в результате трансляции — в директории dist.

Эта команда берет весь код из файлов в директории src и создает его транслированную версию в директории dist. Запускается он точно так же, как и любой другой код, и фактически именно этот код нужно доставить в NPM-репозиторий. Другими словами, пользователи вашего пакета запускают код из директории dist, а не src, хотя сами об этом не знают. Сама директория dist добавляется в .gitignore , так как сгенерированный код нужен только в момент публикации пакета для упаковки в архив, который уходит в NPM-репозиторий. В процессе разработки пакета, запуск сборки не требуется.

Есть только один маленький нюанс. Изначально я сказал, что NPM никак не интегрирован с Git, но это не совсем правда. По умолчанию NPM смотрит в файл .gitignore . Все, что там перечислено, не попадет в NPM-репозиторий при публикации пакета. В нашем случае такой директорией является dist, но именно ее мы и хотим опубликовать. Выходов из этой ситуации несколько. Один связан с файлом .npmignore и описан в документации, про другой я скажу подробнее. NPM позволяет указать список файлов и папок, которые нужно опубликовать. Достаточно добавить секцию files в package.json. Содержимое files — массив директорий и файлов:

Существует два способа подготовки пакета к публикации. Первый подход заключается в том, чтобы перед выполнением npm publish вручную сгенерировать каталог dist , используя скрипты: npx babel src —out-dir dist . Подход рабочий, но сопряжён с постоянными ошибками в стиле «ой, забыл собрать новый код». К тому же, это действие может быть автоматизировано — именно эту идею и реализует второй подход. NPM содержит множество предопределённых скриптов, которые выполняются автоматически в определённые этапы работы. Например, prepublishOnly запускается перед непосредственным выполнением публикации. То, что нам и требуется.

Если у вас Windows, вам понадобится утилита cross-env.

В примере выше используется небольшой трюк. В prepublishOnly вызывается другой скрипт — build . Этот приём используется широко, и он действительно удобен. Бывают ситуации, когда все же нужно запускать сборку руками. Поэтому удобно иметь отдельную команду только для генерации. Скрипт build как раз и призван решить эту задачу.

Подчеркну еще раз: каталог dist не должен храниться в git-репозитории, и вы не найдете его на Гитхабе. Посмотрите lodash. Он генерируется только в момент публикации пакета и заливается в npm-репозиторий. Каждая новая публикация должна генерировать этот каталог заново. Только в этом случае обновится код в пакете.

Подведём итог. В git-репозитории хранится исходный код, ещё не обработанный babel. Это значит, что вы всегда можете найти библиотеку и изучить её содержимое на github. А вот пакет, установленный к вам в систему содержит обработанный код, предназначенный для запуска, а не для чтения. Этот код не хранится в git-репозитории. Он попадает в NPM-репозиторий в момент публикации новой версии пакета за счет выполнения команды prepublishOnly (в которую вы сами должны прописать вызов трансляции).

Babel-node

При использовании новых возможностей js, запуск кода на выполнение node file.js , упадет с ошибкой, потому что внутри файла используется синтаксис, который нода не понимает. Для запуска кода после каждого изменения, необходимо выполнять трансляцию. Этот процесс выглядит так:

  1. Делаем изменение.
  2. Транслируем код с помощью Babel.
  3. Запускаем на выполнение.

Разработчики Babel предусмотрели эту ситуацию. В этом случае можно установить пакет @babel/node. Теперь код можно вызывать так: npx babel-node src/index.js . Команда babel-node делает одновременно две вещи. Транслирует код и сразу же запускает его на выполнение. В отличие от команды babel, babel-node не сохраняет результат трансляции. Все происходит во время работы в памяти. Обратите внимание на то, что вам все равно понадобится правильно настроенный файл babel.config.js в корне проекта иначе babel-node не сможет произвести трансляцию и так же завершится с ошибкой синтаксиса на момент запуска.

Самостоятельная работа

Попробуйте выполнить скрипт build в пакете nodejs-package. Изучите результаты его работы в директории dist . Вы должны увидеть, что содержимое файлов внутри dist отличается от содержимого тех же файлов внутри src . Вместо const использован var , вместо import — require . В целом код остается читаем, хотя и выглядит странновато.

источник

Читайте также:  Установка датчика коленвала на уаз

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