Pull to refresh

Comments 38

Читаю спокойно, думаю, какой то низкоуровневый пост. "Ааа, так это же из песочницы".

А вот это вообще не смешно, кстати

Опечатка в предложении: "Вебпаку укажем, что используем плагин pug-plugin для файлов с расширением .pug"

Скорее всего, имелось в виду:

"Вебпаку укажем, что используем лоадер pug-loader для файлов с расширением .pug"

Pug plugin - это новый подход к обработке Pug файлов. Он намного облегчает использование Pug в проекте и имеет функциональность плагинов, таких как:

Используя Pug plugin, входной точкой является Pug файл. Все исходные файлы скриптов и стилей подключаются непосредственно в самом Pug файле с помощью require(). Это намного удобнее, чем импортировать стили в JavaScript файле. Pug plugin сам заменяет имена исходных файлов на их хешированные версии.

Взято из  pug-plugin:

Webpack конфиг:

const path = require('path');
const PugPlugin = require('pug-plugin');

module.exports = {
  output: {
    path: path.join(__dirname, 'dist/'),
    // output filename of JS files
    filename: 'assets/js/[name].[contenthash:8].js'
  },

  entry: {
    // define Pug files in entry:
    index: './src/views/index.pug',      // => dist/index.html
    about: './src/views/about/index.pug' // => dist/about.html
    // ...
  },

  plugins: [
    // enable using Pug files as entry point
    new PugPlugin({
       extractCss: {
        // output filename of CSS files
        filename: 'assets/css/[name].[contenthash:8].css'
      },
    })
  ],

  module: {
    rules: [
      {
        test: /\.pug$/,
        loader: PugPlugin.loader, // the Pug loader
      },
      {
        test: /\.(css|sass|scss)$/,
        use: ['css-loader', 'sass-loader']
      },
    ],
  },
};

Pug файл:

html
  head
    link(href=require('./styles.scss') rel='stylesheet')
  body
    h1 Hello Pug!
    script(src=require('./main.js'))

Сгенерированный HTML:

<html>
  <head>
    <link href="/assets/css/styles.f57966f4.css" rel="stylesheet">
  </head>
  <body>
    <h1>Hello Pug!</h1>
    <script src="/assets/js/main.b855d8f4.js"></script>
  </body>
</html>

Pug плагин также имеет Pug лоадер, который содержит встроенные фильтры для подсветки синтаксиса кода и markdown.

Для активации встроенного markdown фильтра с highlighting'ом кода в markdown, нужно добавить опции в Pug лоадер:

{
  test: /.pug$/,
  loader: '@webdiscus/pug-loader',
  options: {
    // enable embedded filters
    embedFilters: {
      // enable :markdown filter
      markdown: {
        // enable highlighting in markdown
        highlight: {
          verbose: true,
          use: 'prismjs',
        },
      },
    },
  },
},

В данный момент, для подсветки синтаксиса в markdown поддерживается PrismJS, который должен быть установлен дополнительно:

npm install -D prismjs

Теперь в Pug темплейте можно :markdown фильтр с блоками кода, например:

h1 Markdown with code blocks

:markdown
  _HTML_
  ```html
  <!-- Comment -->
  <div class="container">
    <p>Paragraph</p>
  </div>
  ```

  _JavaScript_
  ```js
  const arr = [1, 2, 'banana'];
  ```

Примеры использования pug-filters встроенных в pug-loader.

Скажите, этот гайд достаточен чтобы с 0 начать пользоваться вебпаком как фронт ?
До этого пользовался готовой сборкой "Фрилансера по жизни"

Собственно, для этой цели статья и написана. Если выполнять всё по порядку, то настроите рабочую сборку вебпак. Старался ничего не пропустить.

Спасибо, сяду переписывать на днях с 0. А то не по себе пользоваться готовым сборщиком не зная как он устроен под капотом.

О, брат, я тоже этой сборкой пользуюсь)

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

Сборка для реакта подойдет или там по-другому настраивается?

А потом мы просто выкидываем это всё, ставим vite и забываем об этой конфигурационной диче

Я согласен лишь с тем, что vite - это инструмент нового поколения. Однако, огромное количество проектов разрабатывается на webpack. Большинство вакансий требуют знаний webpack. Поэтому, данный сборщик еще очень долго будет актуальным. Посмотрите на jquery. Несмотря на абсолютное доминирование таких инструментов, как React, Vue и т.п., библиотека jquery до сих пор используется на огромном количестве сайтов. А на рынке труда не так редко попадаются вакансии с требованием jquery. Так что, знание и умение работать с вебпаком лишним не будет.

Ну с этой точки зрения согласен.

Но всё же если решили переводить проект на свежую версию вебпака... то возможно тут какая-то проблема с нежеланием использовать как минимум более простой инструмент.

Возможно кто-то распишет примеры, где вебпак делает какие-то супер специфичные штуки, которые не может/не умеет вите - это было бы без иронии интересно.

Просто пока смотрю на это как на yarn2 - все ждали, он вышел, никто не понял зачем и как, и все забили. опять же, может я и ошибаюсь, но на релизе того же yarn2 это было что-то загадочное и непонятно как было пришивать это для проектов на vue том же и т.д. Потом еще полгода пытался найти какие ни будь гайды где люди разобрались - пустота. Хотя концепция вендоринга зависимостей лично мне нравится.

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

Что касаемо того, что умеет или не умеет vite, я не знаю. Где то читал, что он не поддерживает устаревшие браузеры.

"Если терминал по какой-то причине будет закрыт, то нужно открыть новый терминал и выполнить команду: cd my-project."

Серьёзно? Для такого уровня читателей статья?

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

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

Встроенные ассеты работают с файлами как с модулями, например, файл прописан в коде с помощью import/require() и расположен в некоем каталоге. Задача ассетов отправить этот файл либо в выходной каталог, либо встроить в код и соответствующим образом преобразовать import/require() в URL-адрес, по которому браузер найдет этот ресурс.

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

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

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

Проверял с включенным явным кэшированием, и оптимизацией изображений, не через ваш пример.
Условно с 2с ухожу в 10+ с копиплагинами и т.п., на голом проекте. На относительно большом до 3-5 сек. с ассетами. Модулированием css и т.п., в общем можно долго холиварить на этот счет )
В любом случае выражаю респект за проделанную работу :3

Автор, если будет время, посмотрите сборку "под капотом пожалуйста", интересно знать ваше мнение.
https://github.com/iWyse/gulp

Там много полезных плагинов, например перевод изображений в webp формат.
Но меня смущает что сам проект немного "тяжелый" с такой сборкой, автор включает множество функций для оптимизации проекта в браузере(плавная прокрутка и.д). Действительно ли это так необходимо?

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

Я новичек, подскажите плз, почему с этой сборкой если вставляю изображения в html или в css(background-image), путь прописываю верно, но после npm run serve уже в браузере в начале пути "/" заменяется на "\" и изображение не видно.

как это исправить?

Эта сборка настроена на работу с Pug и SCSS. Но если вы используете html и css, то вам нужно html разметку писать в файлах pug, а стили css в файлах scss. Либо настроить сборку под свои инструменты.

Может подскажете как можно решить проблему, если подключен mini-css-extract-plugin то он подставляет не верный путь к картинкам вставленым через scss подставляет не тот слеш, путь выглядит так src/images\img.jpg вместо src/images/img.jpg. Как это можно исправить?

Если этот плагин выключен, тогда все ок. OS windows

И посыпались ошибки на этом пункте:
"Теперь, удалим каталог dist с двумя файлами, а после в терминале запустим команду:

хотя делал всё строго согласно инструкции, а в итоге страница, запущенная в браузере с текстом и ошибками

"

Проект собран на Webpack

Html Webpack Plugin:

  Error: Child compilation failed:
  Module not found: Error: Can't resolve 


Получилось ли победить данный баг?

Отвечу сам себе - в подавляющем большинстве случаев проблема в имени папок (в пути до проекта). В моём случае путь содержал символ "!". Сделав путь правильным, от проблемы избавился.

Но появилась иная. При использовании локальных шрифтов при F12 инспекции обнаружил что путь до шрифта имеет вид http://..../fontsopensans.... , где "fonts" Это отдельная папка где они хранятся вместе с fonts.scss. при создании билда всё это конфигом помещается в /dist/fonts, но при этом путь именно такой, не хватает слэша.

Не смог понять причину проблемы ((( пришлось временно переключиться на cdn шрифты. Но очень хотелось бы разобраться в проблеме

Да, вы оказались правы. Всё было именно в неправильном прописывании пути имени папок)

Очень мало данных для того, чтобы делать какие-то выводы.

Что именно нужно предоставить?
ОС Ubuntu 20.04. Все операции производил в VSC.

возник вопрос по минимизации изображений. svg и png сжимает вроде как хорошо. но я пытался с этими настройками оптимизировать 2 jpg файла и разница была очень маленькой в размере исходного и минифицированного файла. на входе 1,32Mb (24bit) и 386Kb (24bit) - на выходе 1,09MB (24bit) и 372Kb (24bit) соответственно. если эти же файлы минифицировать в каком нибудь онлайн-минификаторе для картинок, то сжать их получается гораздо лучше примерно раза в 2-3. 427Kb (24bit) и 189Kb (24bit) соответственно.

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

насколько вообще целесообразно обрабатывать вебпаком изображения вместо онлайн оптимизатора или надо использовать оба варианта или я чего тоне понял?

Если вы внимательно читали, то сжатие производит не вебпак, а минификатор imagemin, точнее плагины к нему. Сжатие может быть без потерь качества и с потерями. Все зависит от того, какие установлены плагины и как они настроены. Без потерь качества файлы сжимаются хорошо, если они до этого не подвергались сжатию. С потерями вы можете сжимать сколько душе угодно.

файлы я предварительно не обжимал - просто скачал из инета обои на рабочий стол 1920х1280. без потери качества сжимает метров на 300. а с потерей качества - раза в 3-4, при чем потеря качества визуально почти не видна.

после этого попробовал с png. достал из фигмы картинку png. 243kb(32bit) на входе - 230(32bit) на выходе после сжатия. использовал плагин optipng как у вас в сборке.

не пойму почему с одинаковыми настройками optipng плагина получается разное сжатие у ваших и мои png файлов. у вашего файла получается на выходе 2,28kb(8bit) из 32bit файла. у моего в остается 32bit после оптимизации. биты не меняются и оптимизация мизерная.

разница в файлах? или в чем еще может быть дело? или этот плагин подходит не для любых png файлов?

Подскажите пожалуйста, как настроить режим npm run watch? Пробовал. Изменения кода отслеживает, но теряет стили и изображения.

Не совсем понятно, что вы подразумеваете под режимом watch. Хотя, это неважно. Этот режим не подразумевает сохранения чего бы-то не было. Режим watch предназначен для наблюдения за изменениями. После режима наблюдения вы запускаете режим development или production. Именно эти режимы сохраняют сборку в файлы.

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

А как быть с загрузкой посторонних шрифтов? Если не найден шрифт, ну допустим Monserrat Alternates, которого тут нет https://gwfh.mranftl.com/?
И точно ли путь должен быть указан таким, который вы указали тут:
"В секции Copy CSS: в поле Customize folder prefix (optional): укажем префикс пути ./ и скопируем из серого поля CSS-код в наш файл src/fonts/fonts.scss."

Потому как я пробовал с Roboto прописать как в указанном вами пункте выше, так и в таком ../, но в консоль VSC влетали ошибки:

"ERROR in ./src/fonts/fonts.scss (./src/fonts/fonts.scss.webpack[javascript/auto]!=!./node_modules/css-loader/dist/cjs.js!./node_modules/postcss-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js!./src/fonts/fonts.scss) 5:36-109
Module not found: Error: Can't resolve './fonts/roboto-v30-latin_cyrillic-regular.eot' in '/home/admin-/Документы/и т.д. и т.п/'

спасибо за статью, помогла

сейчас можно использовать '@webdiscus/pug-loader' на замену оригинальному, поддерживает pug 3

Sign up to leave a comment.

Articles