Dev server что это за программа

DevServer

webpack-dev-server можно использовать для быстрой разработки приложения. См. Руководство по разработке, чтобы начать работу.

На этой странице описаны параметры, которые влияют на поведение webpack-dev-server (сокращенно: dev-server) версии> = 4.0.0. Руководство по v4 с v3 на v4 можно найти здесь .

warning

webpack-dev-server v4.0.0+ требует node >= v12.13.0 , webpack >= v4.37.0 (но мы рекомендуем использовать webpack >= v5.0.0 ) и webpack-cli >= v4.7.0 .

devServer

Этот набор параметров подбирается webpack-dev-server и может использоваться для изменения его поведения различными способами. Вот простейший пример, который сжимает и обслуживает все из нашего каталога public/ в корне проекта:

webpack.config.js

const path = require(‘path’); module.exports = < //. devServer: < static: < directory: path.join(__dirname, ‘public’), >, compress: true, port: 9000, >, >;

При запуске сервера перед списком разрешенных модулей появится сообщение:

Webpack dev server

[webpack-dev-server] Project is running at: [webpack-dev-server] Loopback: http://localhost:9000/ [webpack-dev-server] On Your Network (IPv4): http://197.158.164.104:9000/ [webpack-dev-server] On Your Network (IPv6): http://[fe80::1]:9000/ [webpack-dev-server] Content not from webpack is served from ‘/path/to/public’ directory

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

Если вы используете dev-сервер через API Node.js, параметры в devServer будут проигнорированы. Вместо этого new WebpackDevServer(<. >, compiler) параметры в качестве первого параметра: new WebpackDevServer (<. >, компилятор) . См. Здесь пример использования webpack-dev-server через API Node.js.

warning

Вы не можете использовать второй аргумент compiler (обратный вызов) при использовании WebpackDevServer .

warning

Имейте в devServer что при экспорте нескольких конфигураций будут учитываться только параметры devServer для первой конфигурации и использоваться для всех конфигураций в массиве.

tip

Если у вас возникли проблемы, /webpack-dev-server по маршруту / webpack-dev-server покажет, где обслуживаются файлы. Например, http://localhost:9000/webpack-dev-server .

tip

Если вы хотите вручную перекомпилировать пакет, перейдя к /invalidate маршрута будет недействительным текущий сборник расслоения и перекомпилировать его для вас через WebPack-DEV-промежуточный слой . В зависимости от вашей конфигурации URL-адрес может выглядеть как http://localhost:9000/invalidate .

tip

Для обслуживания пакета требуется шаблон HTML, обычно это файл index.html . Убедитесь, что ссылки на скрипты добавлены в HTML, webpack-dev-server не вставляет их автоматически.

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

Вы можете вызвать webpack-dev-server через CLI,используя:

npx webpack serve

Список опций интерфейса командной строки для serve доступен здесь.

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

Хотя рекомендуется запускать webpack-dev-server через интерфейс командной строки, вы также можете выбрать запуск сервера через API.

devServer.allowedHosts

‘auto’ | ‘all’ [string]

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

webpack.config.js

module.exports = < //. devServer: < allowedHosts: [ ‘host.com’, ‘subdomain.host.com’, ‘subdomain2.host.com’, ‘host2.com’, ], >, >;

ALLOWED_HOSTS Django , значение, начинающееся с . может использоваться как подстановочный знак поддомена. .host.com будет соответствовать host.com , www.host.com и любому другому поддомену host.com .

webpack.config.js

module.exports = < //. devServer: < // это дает тот же эффект, что и в первом примере // с бонусом в виде отсутствия необходимости обновлять конфигурацию // если новым поддоменам нужен доступ к серверу разработки allowedHosts: [‘.host.com’, ‘host2.com’], >, >;

Использование через CLI:

npx webpack serve —allowed-hosts .host.com —allowed-hosts host2.com

Если установлено значение ‘all’ эта опция обходит проверку хоста. ЭТО НЕ РЕКОМЕНДУЕТСЯ, поскольку приложения, которые не проверяют хост, уязвимы для атак повторного связывания DNS.

webpack.config.js

module.exports = < //. devServer: < allowedHosts: ‘all’, >, >;

Использование через CLI:

npx webpack serve —allowed-hosts all

Если установлено значение ‘auto’ , эта опция всегда разрешает localhost , host и client.webSocketURL.hostname :

webpack.config.js

module.exports = < //. devServer: < allowedHosts: ‘auto’, >, >;

Использование через CLI:

npx webpack serve —allowed-hosts auto

devServer.bonjour

boolean = false object

Эта опция транслирует сервер через сеть ZeroConf при запуске.

webpack.config.js

module.exports = < //. devServer: < bonjour: true, >, >;

Использование через CLI:

npx webpack serve —bonjour
npx webpack serve —no-bonjour

Вы также можете передать настраиваемые параметры в bonjour, например:

webpack.config.js

module.exports = < //. devServer: < bonjour: < type: ‘http’, protocol: ‘udp’, >, >, >;

devServer.client

logging

‘log’ | ‘info’ | ‘warn’ | ‘error’ | ‘none’ | ‘verbose’

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

webpack.config.js

module.exports = < //. devServer: < client: < logging: ‘info’, >, >, >;

Использование через CLI:

npx webpack serve —client-logging info

overlay

boolean = true object:

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

webpack.config.js

module.exports = < //. devServer: < client: < overlay: true, >, >, >;

Использование через CLI:

npx webpack serve —client-overlay
npx webpack serve —no-client-overlay

Если вы хотите показать только ошибки:

webpack.config.js

module.exports = < //. devServer: < client: < overlay: < errors: true, warnings: false, >, >, >, >;

Использование через CLI:

npx webpack serve —client-overlay-errors —no-client-overlay-warnings

progress

Выводит прогресс компиляции в процентах в браузере.

webpack.config.js

module.exports = < //. devServer: < client: < progress: true, >, >, >;

Использование через CLI:

npx webpack serve —client-progress
npx webpack serve —no-client-progress

reconnect

boolean = true number

Сообщает dev-серверу, сколько раз он должен попытаться переподключить клиента. Когда это true он будет пытаться повторно подключиться неограниченное количество раз.

webpack.config.js

module.exports = < //. devServer: < client: < reconnect: true, >, >, >;

Использование через CLI:

npx webpack serve —client-reconnect

Если установлено значение false , попытка повторного подключения не выполняется.

module.exports = < //. devServer: < client: < reconnect: false, >, >, >;

Использование через CLI:

npx webpack serve —no-client-reconnect

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

module.exports = < //. devServer: < client: < reconnect: 5, >, >, >;

Использование через CLI:

npx webpack serve —client-reconnect 5

webSocketTransport

‘ws’ | ‘sockjs’ string ‘sockjs’

Эта опция позволяет нам либо выбрать текущий транспортный режим devServer для клиентов индивидуально, либо предоставить индивидуальную реализацию клиента. Это позволяет указать, как браузер или другой клиент взаимодействует с devServer .

tip

Предоставление ‘ws’ или ‘sockjs’ для webSocketServer — это ярлык для установки заданного значения как devServer.client.webSocketTransport ,так и devServer.webSocketServer .

webpack.config.js

module.exports = < //. devServer: < client: < webSocketTransport: ‘ws’, >, webSocketServer: ‘ws’, >, >;

Использование через CLI:

npx webpack serve —client-web-socket-transport ws —web-socket-server ws

tip

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

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

Используя путь к CustomClient.js , пользовательской реализации клиента WebSocket, вместе с совместимым сервером ‘ws’ :

webpack.config.js

module.exports = < //. devServer: < client: < webSocketTransport: require.resolve(‘./CustomClient’), >, webSocketServer: ‘ws’, >, >;

Использование пользовательских,совместимых реализаций клиента и сервера WebSocket:

webpack.config.js

module.exports = < //. devServer: < client: < webSocketTransport: require.resolve(‘./CustomClient’), >, webSocketServer: require.resolve(‘./CustomServer’), >, >;

webSocketURL

Эта опция позволяет указать URL сервера веб-сокета (полезно,когда вы проксируете сервер dev и клиентский скрипт не всегда знает,куда подключаться).

webpack.config.js

module.exports = < //. devServer: < client: < webSocketURL: ‘ws://0.0.0.0:8080/ws’, >, >, >;

Использование через CLI:

npx webpack serve —client-web-socket-url ws://0.0.0.0:8080/ws

Вы также можете указать объект со следующими свойствами:

• hostname : сообщает клиентам, подключенным к devServer, использовать предоставленное имя хоста.
• pathname : сообщает клиентам, подключенным к devServer, использовать предоставленный путь для подключения.
• password : сообщает клиентам, подключенным к devServer, использовать предоставленный пароль для аутентификации.
• port : сообщает клиентам, подключенным к devServer, использовать предоставленный порт.
• protocol : сообщает клиентам, подключенным к devServer, использовать предоставленный протокол.
• username : сообщает клиентам, подключенным к devServer, использовать предоставленное имя пользователя для аутентификации.

webpack.config.js

module.exports = < //. devServer: < client: < webSocketURL: < hostname: ‘0.0.0.0’, pathname: ‘/ws’, password: ‘dev-server’, port: 8080, protocol: ‘ws’, username: ‘webpack’, >, >, >, >;

tip

Чтобы получить protocol / hostname / port из браузера, используйте webSocketURL: ‘auto://0.0.0.0:0/ws’ .

• 1
• …
• 39
• 40
• 41
• 42
• 43
• …
• 160
• Next

Источник: runebook.dev

Базовые SEO-настройки DEV- и LIVE-серверов

Также в статье заодно затронули базовые настройки CMS.

Приведенный ниже список можно расширять и дополнять, но его малый объем – как раз большое преимущество. Мы в компании договариваемся, что все разработчики и системные администраторы знают и понимают все эти пункты и учитывают их в своей работе всегда. Задача SEO – чекать, чтобы это все было учтено.

Для DEV

Настройка сервера DEV

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

Главное: все указанные ниже настройки должны работать только на DEV и никоим образом не переноситься на LIVE.

Запуск нового проекта с DEV (сервер и CMS)

Этот чек-лист мы также передаем своим разработчикам. Это святая святых в моменте, когда мы разработали новый веб-сайт и выводим его в лайв (первый запуск).

1. Заменить/проверить домен в rel=canonical на всех страницах на актуальный LIVE домен.
2. Актуализировать robots.txt с SEO-командой (он всегда адресный для каждого сайта). Должен быть доступен по адресу site.ru/robots.txt.
3. Заменить на LIVE тег на всех страницах: с < meta name=»robots» content=»noindex, nofollow» >на
4. Генерация карты сайта: sitemap.xml. Карта должна быть доступна по адресу site.ru/sitemap.xml с актуальными страницами и корректным live доменом в URLs.
5. HomePage доступна только по одному адресу – доменное имя. Никаких сайт.ру/index.php, сайт.ру/home и т.д.
6. Множественные слеши и одиночный слеш после URL редиректят на «без /».
7. Настройка редиректа всех URL с «/» в конце на «без /» в конце домена.
8. Сайт с www редиректит на адрес без www.
9. Сайт работает на https.
10. Http редиректит на https.

Обновление с DEV на LIVE

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

При выкатке обновлений все настройки сервера и контента на запрет индексации должны оставаться только в рамках DEV. Вот что не должно поехать с обновлением на LIVE:

1. robots.txt
3. http-предавторизация

Для LIVE

Теперь непосредственно про LIVE-сервер. Что важно настроить на нем и за чем следить. Это очень базовые моменты – то, что мы требуем от разработчика как знание.

Настройка сервера для LIVE

1. Настройка редиректа всех URLs с «/» в конце на «без /» в конце домена. На самом деле вы можете сделать наоборот, это не принципиально. Важно чекнуть этот момент и не допустить, чтобы работали URL-адреса и со слешем на конце, и без слеша параллельно.
2. Множественные слеши после URL редиректят на БЕЗ слеша.
3. Сайт с www редиректит на без www.
4. Http редиректит на https.

Базовые SEO-настройки CMS

Что надо знать каждому программисту, когда он создает новый веб-сайт.

Список специально сделан кратким, так как мы требуем от разработчиков и сисадминов знания и понимания всех этих пунктов. Важно, чтобы backend и сервер учитывали это при работах.

Если у вас есть вопросы или хотите уточнить информацию, пишите, пожалуйста, в комментариях.

Источник: www.seonews.ru

#5 — Webpack-dev-server

Всем привет! Меня зовут Ковальчук Дмитрий. Вы смотрите Лофтскул. Мы продолжаем изучать Webpack.

Для ещё большего удобства разработчиков, в официальной документации Webpack нам предлагается использовать “webpack-dev-server”. В нём встроен локальный сервер и livereload (“живая перезагрузка браузера”). WDS также порадует вас возможностью гибкой настройки. Отдельно хочется выделить 2 момента:

1. Webpack-dev-server работает “в памяти” (“server running in-memory”) — он не создает в каталоге проекта скомпилированных файлов.

2. “Hot Module Replacement (HMR)” — позволяет обновлять отдельные модули страницы, без её полной перезагрузки. Полную мощь можно ощутить при использовании с React.

1. Установка и запуск webpack-dev-server

Установим webpack-dev-server и сохраним его в package.json.

yarn add webpack-dev-server -D

Чтобы интегрировать webpack-dev-server в наш проект, мы должны определить новый npm-скрипт (в package.json файле).

Мы назовём его «start». А скрипт, который запускает Webpack со слежкой заменим на простой запуск Webpack без слежки. Его задача — просто собирать проект, и название ему дадим соответствующее — «build».

«serv»: «static build»

Теперь, когда мы будем запускать WDS

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

Project is running at http://localhost:8080/

Так и поступим. В браузере мы увидим наш сайт, подобно тому, как это было со статическим сервером.

Однако теперь в нашем арсенале появился livereload. Попробуем внести изменения в шаблоны или в js-файлы.

Удалите папку build и ещё раз убедитесь — в каталоге вашего проекта нет скомпилированных файлов, т.е. WDS “собирает” проект прямо в память.

WDS не рекомендуется использовать для продакшена, поэтому проверять собранную при помощи Webpack сборку мы можем, как и раньше, при помощи «node-static».

2. Базовая настройка webpack-dev-server

У WDS, как было сказано ранее, есть огромное количество настроек. Все эти настройки необходимо помещать в объект “devServer”, который является свойством модуля, экспортируемого конфигом Webpack. Для нашего примера достаточно будет рассмотреть одно свойство “stats”. Присвоим ему значение ‘errors-only’. Теперь, при запуске webpack-dev-server, в консоли мы увидим гораздо меньше информации (а именно “только ошибки”).

и проверим терминал — сообщений стало ощутимо меньше.

На этом закончится пятый видеоурок курса по изучению Webpack 2.

Приятного всем просмотра! Учитесь с удовольствием!

ツПолезные ссылки к видеоуроку:

✔ Подписывайтесь на канал, новые видео выходят каждую неделю.

Источник: loftschool.com

Что такое webpack dev server?

С этой штукой Ты сможешь разрабатывать приложения с высокой скоростью и комфортом.
Webpack Dev Server позволяет тебе запускать локальный сервер (на твоем ПК) и следить за изменениями всех, необходимых для разработки файлов, автоматически. То есть, тебе не придется перезапускать проект, чтобы обновить изменения.

в консоль пишешь:
npm i webpack-dev-server

в package.json в поле scripts добавляешь вот такие вот команды:

«scripts»:

Где commandName название твоей команды.

devServer: < port: 8888, // определяет порт overlay: < // показывает ошибки или предупреждения при разработке warnings: boolean, errors: boolean >, open: true, // открывает окно браузера >

Источник: qna.habr.com

Отладка на локальных устройствах приложений под webpack-dev-server

Почти каждый разработчик использовавший webpack-dev-server сталкивался с проблемой отладки локального приложения на мобильных или прочих устройствах находящимися под NAT. На гугл-просторах каждый вторит о дополнительном параметре —host 0.0.0.0 или localhost для запуска webpack-dev-server и то, что после этого приложение будет доступно по локалной сети. Но увы, лично у меня данный метод не работает, причем отказывается работать даже на простейших тестовых проектах, приложеных к решениям.

Сработал следующий метод, который нигде не был описан и наткнулся на это решение чисто случайно:

1. Узнаем текущий IP

Узнать IP машины можно следующими командами ipconfig (Windows) или ifconfig (Linux).

2. Запускаем webpack-dev-server

Запускаем webpack-dev-server на этот IP. К примеру, если имеем конфигурацию следующего вида:

devServer: hot: true, contentBase: resolve(__dirname, ‘dist’), publicPath: ‘/’, host: ‘localhost’, port: 7373, proxy: ‘/api/**’: target: ‘localhost:8000’, secure: false, changeOrigin: true, > >, >,
devServer: hot: true, contentBase: resolve(__dirname, ‘dist’), publicPath: ‘/’, host: ‘192.168.3.186’ port: 7373, proxy: ‘/api/**’: target: ‘192.168.3.186:8000’, secure: false, changeOrigin: true, > >, >,

3. Отключаем Firewall

Отключаем Public Firewall в Windows Defender или лю другой, если используется сторонний.

4. Готово.

Можно использовать на других устройствах, обращаясь по адресу машины на котором запущен dev-server, не забывая указывать нужный порт. В данном случае 192.168.3.186:7373 .

Очень надеюсь, что мой метод кому-то сохранит время. Удачного дебага!

Ах да, чуть ниже можно подписаться на новости блога.

Источник: blog.zverit.com