✅ WEB і WordPress новини, теми, плагіни. Тут ми ділимося порадами і кращими рішеннями для сайтів.

Повний посібник із налаштування середовища розробки для Gutenberg

18

Цей посібник призначений для тих, хто хоче написати код для Gutenberg із синтаксисом ES6, ESNext і JSX і потребує налаштування webpack і babel для перетворення їх у файли, які можна використовувати в редакторі Gutenberg. Ми розглянемо, що вам потрібно зробити, чому та як ми можемо використовувати та розширити стандартні параметри WordPress і налаштувати їх відповідно до наших потреб.

Якщо ви вперше знайомі з концепціями npm, webpcak і Babel, вам слід прочитати наступний розділ, який має на меті пояснити основи роботи цих інструментів і їх використання. Однак якщо ви робили це раніше і знайомі з процесом, можливо, розробляючи за допомогою React, перейдіть до наступного розділу, де ми фактично налаштуємо все.

Для початківців: npm, webpack і babel

Якщо ви не впевнені, навіщо нам все це потрібно робити для написання Javascript для Gutenberg, я рекомендую вам прочитати мою публікацію, яка досліджує основи розробки для Gutenberg, де я пояснюю різницю між версіями Javascript і чому це варте зусиль.

Якщо ви ніколи раніше цього не робили, спочатку потрібно встановити Node.js на свій комп’ютер. Перейдіть за посиланням, завантажте та встановіть його. У Node.js ви отримаєте інструмент, який ми використовуватимемо для налаштування більшості конфігурацій. Це інструмент npm, який дозволяє встановлювати бібліотеки Javascript і запускати сценарії через командний рядок/термінал. Ви також можете використовувати yarn, якщо хочете, але для цього посібника ми використовуватимемо npm.

npm

Цей посібник не вдаватиметься в подробиці про всі речі, які ви можете робити з npm, але він пояснює основну концепцію цього та речі, які стосуються наших цілей. Ми будемо використовувати npmдля двох речей; для встановлення необхідних бібліотек у наш проект і для запуску команд для створення (компіляції) наших файлів Javascript.

За допомогою npmви можете інсталювати будь-які публічні пакети Javascript з відкритим кодом. Якщо б ми розробляли за допомогою React (поза WordPress), нам потрібно було б встановити бібліотеки React і бібліотеки webpack. WordPress пропонує цілий ряд бібліотек (головним чином для Gutenberg), які ви можете встановити, але насправді нас цікавить лише одна: @wordpress/scripts– яка допомагає нам спростити нашу конфігурацію.

Кожного разу, коли ви встановлюєте бібліотеку, npmбуде створено вкладену папку «node_modules», де зберігаються встановлені бібліотеки. Вам ніколи не потрібно буде входити в цю папку чи щось змінювати тут, але майте на увазі, що ця папка легко містить (буквально!) десятки тисяч файли. Це папка, яку ви ніколи не повинні передавати git або включати в будь-яку готову тему чи плагін. Бібліотеки потрібні лише під час розробки.

Коли ваше середовище налаштовано, ви можете використовувати npmдля запуску сценаріїв, визначених у вашому package.jsonфайлі. Залежно від проекту ви зазвичай маєте принаймні два сценарії; один для створення сценаріїв і один для запуску «режиму перегляду». У «режимі спостереження» npmзапускає процес у терміналі, який очікує та прослуховує зміни, внесені в будь-який файл, і компілює їх під час виконання кожного разу, коли ви натискаєте «Зберегти». Ви можете бути знайомі з цією концепцією, якщо раніше користувалися програмами-компіляторами SCSS або LESS. Набагато ефективніше запускати сценарій «перегляду» у фоновому режимі, який перекомпілюється кожного разу, коли ви зберігаєте, замість того, щоб переходити в термінал і запускати команду збірки після кожної зміни.

webpack і babel

Ви можете отримати, розробляючи для Gutenberg, не виконуючи жодних конфігурацій webpack або babel. Оскільки ми використовуємо бібліотеки WordPress, вони впораються з цим за нас. Однак у цього є один недолік – за замовчуванням фіксоване розташування та ім’я файлу для вихідних і вихідних файлів. Усю вашу розробку на Javascript потрібно записати в одному файлі, у project-folder/src/index.js, і збірка завжди закінчуватиметься у project-folder/build/index.js. Якщо вас це влаштовує, ви можете пропустити всю частину про налаштування webpack. Однак, якщо ви розробляєте тему чи плагін із декількома функціями Gutenberg (настроювані блоки, фільтри тощо), вам може знадобитися принаймні інша назва вихідного файлу та розташування, а також дозволити кілька файлів.

Якщо ви використовуєте пакет WordPress для налаштування (@wordpress/scripts), Babel уже налаштовано. Але ви повинні знати, що пакет WordPress може не включати плагіни, які ви можете використовувати. Існує, наприклад, пакет, який дозволяє використовувати нові так звані «функції зі стрілками» (myFunction = (param) => { }) для визначення функцій без необхідності прив’язувати this. Якщо ви дійсно хочете використовувати ці функції ESNext, вам потрібно буде самостійно налаштувати Babel замість використання стандартних параметрів WordPress. Нижче я поясню, як.

Процес

Процес розробки за допомогою webpack після того, як усе налаштовано та встановлено, полягає у переході до папки вашого проекту в терміналі та запуску сценарію «watch». Він залишатиметься відкритим і слухатиме зміни, внесені у ваші файли JS. Кожного разу, коли ви натискаєте «Зберегти» у ваших файлах Javascript, термінал виводить інформацію (сподіваємося), що він успішно повторно скомпільував файл. Якщо були помилки компіляції, вони з’являться в терміналі. Щоб зупинити процес «перегляду», натисніть CTRL + C.

Налаштування середовища

Я припускаю, що у вас уже є локальний WordPress, який працює на якомусь стеку LAMP (такі програми, як WampServer, XAMPP, Docker або подібні), і що у вас є або плагін, або тема, готова для початку кодування вашого Javascript.

Я рекомендую створити вкладену папку, призначену для вашої розробки Javascript, оскільки у вас може залишитися кілька конфігураційних файлів і папок. Це полегшує відокремлення файлів і папок (наприклад node_modules/), які ви не хочете включати в git-коміти або остаточні збірки. Але цілком нормально використовувати вашу основну тему або папку плагіна як папку проекту для розробки Javascript.

У терміналі (термінал Mac OS або командний рядок Windows працюють нормально) перейдіть до папки проекту. Що стосується цього підручника, то я припускаю, що ми працюємо з темою та створили порожню підпапку gutenberg-dev/як папку нашого проекту.

Першим кроком є ​​ініціалізація проекту npm, який, по суті, просто повідомляє npmпро створення package.jsonфайлу. Цей package.jsonфайл інформує npmпро те, які пакети потрібні та які сценарії доступні для запуску. Введіть це в терміналі;

npm init -y

Це генерує package.jsonфайл із вмістом за замовчуванням у вашій папці проекту.

Далі ми встановимо пакет WordPress, який допоможе нам зменшити кількість налаштувань, які нам потрібно буде виконати. Виконайте цю команду:

npm install --save-dev --save-exact @wordpress/scripts

Тег --save-devповідомляє npm, що дані бібліотеки необхідні лише для розробки, і --save-exactзабезпечує npmвстановлення лише однієї версії, останньої.

Відкрийте package.jsonфайл у своєму редакторі. (npmтакож буде створено package-lock.jsonпід час встановлення пакетів, ви можете просто проігнорувати цей файл, у ньому package.jsonви вносите зміни). Він має бути заповнений конфігурацією за замовчуванням, і ви можете помітити, що інсталяція пакета, яку ми виконували раніше, додала запис @wordpress/scriptsпевної версії в devDependencies. Коли ви встановлюватимете більше пакетів, npmбуде оновлено package.jsonзаписи для кожного пакета. Єдине, про що нам потрібно турбуватися в цьому файлі, це scriptsвластивості, які призначені для сценаріїв (команд), які можна використовувати npmдля запуску. Оновіть властивість сценаріїв на це (ви можете видалити типовий «test»):

"scripts": { "build": "wp-scripts build", "start": "wp-scripts start" },

Цей фрагмент коду повідомляє npm, що ми маємо два сценарії, які ми можемо запускати в цій папці проекту; «побудувати» і «почати». Ми запускаємо сценарій із командою npm run <scriptname>, яка npmшукатиме package.jsonта виконає команду, визначену як його значення. Ми використовуємо інструмент wp-scripts, який входить до пакета, який ми щойно встановили, щоб компілювати наш Javascript один раз ("build") або запускати режим «перегляду» / «прослуховування» для компіляції кожного разу, коли ми зберігаємо зміни ("start").

Це також дозволяє нам використовувати веб-пакет WordPress і конфігурацію Babel, тому нам не потрібно робити це самостійно.

У папці проекту створіть вкладену папку під назвою src/. У цій папці створіть index.jsфайл.

Якщо ви влаштовуєте стандартні параметри веб-пакета, готово! Напишіть свій код ES6 і JSX у index.js, і скажіть npmскомпілювати їх, виконавши команду build:

npm run build

або запустіть процес «перегляду» в терміналі, який прослуховує зміни, внесені за допомогою цієї команди (використовуйте CTRL+C, щоб зупинити процес перегляду):

npm run start

Запуск будь-якого з них створить build/підпапку в каталозі вашого проекту зі скомпільованим результатом у build/index.js.

Ось і все для базового налаштування середовища! Тепер ви готові писати ES6 Javascript для Gutenberg!

Якщо ви бажаєте змінити розташування та назви вихідних або вихідних файлів, читайте далі.

Налаштування імен вихідних і вихідних файлів і шляхів

Якщо вас, як і мене, не влаштовує ім’я та структура файлу за замовчуванням, особливо це стосується вихідних файлів, вам потрібно подивитись налаштування webpack. Зазвичай, наприклад, якщо ви розробляєте для React поза WordPress, вам потрібно буде налаштувати повну конфігурацію веб-пакета з плагіном Babel. На щастя, WordPress піклується про це за нас і дозволяє нам розширити власну конфігурацію веб-пакета WordPress і налаштувати лише ті частини, які ми хочемо змінити.

У папці проекту (та сама папка, що й package.json) створіть файл із назвою webpack.config.jsта відкрийте його у своєму редакторі. Напишіть у цей файл наступне:

const defaultConfig = require("@wordpress/scripts/config/webpack.config"); const path = require('path'); module.exports = { ...defaultConfig, entry: { 'block-mynamespace-myblock': './src/block-mynamespace-myblock.js' }, output: { path: path.join(__dirname, '../assets/js/gutenberg'), filename: '[name].js' } }

Перше, що ми робимо, це завантажуємо @wordpress/scriptsконфігурацію webpack у змінну defaultConfig. У конфігурації webpack module.exportsперше, що ми робимо, це застосовуємо все defaultConfigза допомогою оператора spread (...). Ці дві частини гарантують, що ми розширюємо конфігурацію веб-пакета WordPress, включаючи все, що входить до неї. Після оператора поширення ми можемо налаштувати або додати будь-яку властивість, яку ми хочемо змінити; у нашому випадку розташування джерела та місце виведення.

Властивість entryвизначає вихідні файли, якими за замовчуванням є ./src/index.js. Кожен запис у entryвластивості є парою ключ+значення, з якої веб-пакет збиратиметься (і спостерігатиме). У наведеному вище прикладі я визначив «block-mynamespace-myblock», розташоване src/block-mynamespace-myblock.jsяк одна точка входу. Ви можете додати тут скільки завгодно пар ключ+значення для кожного вихідного файлу, який ви хочете скомпілювати.

Властивість outputвизначає розташування скомпільованих файлів. Ви pathвизначаєте папку призначення для всіх скомпільованих файлів. Я використовую помічник шляху, щоб мати можливість правильно переміщатися по каталогах у своїй конфігурації. У наведеному вище прикладі я кажу webpack, що всі скомпільовані файли мають опинитися в моїй theme-folder/assets/js/gutenberg/папці. Важливо використовувати ../для переходу вгору в дереві каталогів, з папки проекту та в іншу папку, де я хочу, щоб були всі файли Javascript моєї теми. Налаштуйте шлях відповідно до структури проекту.

По-друге, я кажу webpack, що всі імена файлів мають бути названі відповідними entryіменами ключів. Ця конфігурація webpack скомпілює мій theme-folder/gutenberg-dev/src/block-mynamespace-myblock.jsу theme-folder/assets/js/gutenberg/block-mynamespace-myblock.js. Якби я додав ще один вихідний файл як пару ключ+значення в entry, його було б скомпільовано в ту саму папку з ключем у якості імені файлу.

Внесіть потрібні зміни у свій webpack.config.jsфайл і збережіть. Повторно запустіть будь-яку з npmкоманд збирання, щоб створити файли в їх новому розташуванні.

Це воно! Тепер ви розширили конфігурацію веб-пакетів WordPress і тепер ви можете контролювати, куди повинні розміщуватися вихідні та вихідні файли.

Однак я хочу включити останню пораду в цей посібник. У конфігурації WordPress за замовчуванням для Babel можуть бути відсутні певні плагіни Babel для певних нових функцій у ESNext. Наприклад, із зазначеними вище параметрами за замовчуванням і за замовчуванням WordPress ви не зможете використовувати функції стрілок у своєму коді. Якщо це для вас важливо, читайте далі.

Додайте підтримку найновішого синтаксису ESNext за допомогою Babel

На момент написання цієї статті у налаштуваннях WordPress за замовчуванням Babel відсутня підтримка «експериментального синтаксису», який включає, наприклад, функції стрілок. Щоб додати підтримку для цього, вам потрібно надати свій конфігураційний файл Babel, і наразі я не знайшов способу розширити конфігурацію Babel WordPress, як ми зробили з конфігурацією webpack вище. Тому нам потрібно перевизначити стилі Babel, а також додати плагін «експериментальний синтаксис». Але не хвилюйтеся, це дуже маленький файл.

Першим кроком є ​​встановлення деяких пакетів, необхідних для пресетів Babel – нам потрібно встановити ті самі, що визначені в конфігурації Babel WordPress. Виконайте цю команду для встановлення @babel/preset-envта @babel/preset-react, а також пакета, який нас цікавить; @babel/plugin-proposal-class-properties:

npm install --save-dev @babel/preset-env @babel/preset-react @babel/plugin-proposal-class-properties

Другим кроком є ​​додавання файлу конфігурації Babel. У папці проекту створіть файл із назвою .babelrc(без розширення файлу).

Примітка для Windows: якщо ви сидите на комп’ютері з Windows, вам заборонено створювати файли без розширень. Щоб обійти це, ви можете створити цей файл за допомогою терміналу/командного рядка. Виконайте цю команду:

Ця команда виведе «hi» у файл .babelrcу поточній папці. Тепер ви можете відкрити цей файл у своєму редакторі, видалити «привіт» і додати фактичний вміст нижче.

Ви .babelrcповинні виглядати приблизно так:

{ "presets": ["@babel/preset-env", "@babel/preset-react"], "plugins": [ [ "@babel/plugin-proposal-class-properties" ] ] }

Ми визначаємо ті самі пресети, які ви зазвичай робите в проекті React, і так само, як це робить WordPress. Те, що ми додаємо, – це pluginsвласність. Всередині масиву pluginsми додаємо @babel/plugin-proposal-class-propertiesнеобхідний плагін Babel для «експериментального синтаксису», наприклад для функцій стрілок.

Висновок

Майте на увазі, що WordPress може змінити свою конфігурацію будь-коли, це особливо ймовірно, тому що Gutenberg досить новий. Оскільки ми розширюємо конфігурацію WordPress, нам може знадобитися знову оновити конфігурацію відповідно до наших потреб. Можливо, WordPress вирішить включити підтримку експериментального синтаксису, щоб нам не довелося виконувати повну конфігурацію Babel.

Це аж ніяк не вичерпний посібник із налаштування Webpack і Babel, а результат безлічі експериментів і з’ясування речей. Сподіваюся, це допомогло вам навчитися налаштовувати власне середовище розробки Gutenberg, і спростило це, щоб це не було такою великою перешкодою для початку вивчення ES6, ESNext, JSX та всього іншого корисного для розробки для Гутенберг!

Джерело запису: awhitepixel.com

Цей веб -сайт використовує файли cookie, щоб покращити ваш досвід. Ми припустимо, що з цим все гаразд, але ви можете відмовитися, якщо захочете. Прийняти Читати далі