Записки с фронтов

Использование env файлов в React

2020-05-23T21:00:00+00:00

Иногда в react-приложении требуется использовать переменные окружения, например это может быть API url, либо какой-то конфиг или какие-то API ключи. Есть 2 способа задать переменные окружения:

через командную строку (временное решение в текущей сессии).
через .env файлы.

Create React App (CRA)

В случае использования CRA, ничего настраивать не требуется. Под капотом уже установлены необходимые пакеты и настроен webpack для обработки таких файлов. Обязательным условием является только префикс REACT_APP_ для переменных окружения. Например, REACT_APP_API_KEY=secret-api-key. Другие имена переменных будут игнорироваться, чтобы избежать случайного раскрытия секретного ключа, который может иметь то же имя. (Исключение составляет только NODE_ENV).

Чтобы использовать переменную в коде, нужно обратиться к ней так:

process.env.REACT_APP_API_KEY

Другой способ задания переменных через командную строку (Bash):

REACT_APP_NOT_SECRET_CODE=abcdef npm start

Свой webpack конфиг

В этом случае нужно установить плагин dotenv-webpack. Затем добавить в конфиг:

// webpack.config.js
const Dotenv = require('dotenv-webpack');
 
module.exports = {
  ...
  plugins: [
    new Dotenv()
  ]
  ...
};

Также следует добавить .env.local файлы в .gitignore:

# misc
.env.local

Виды .env файлов

.env: По умолчанию.
.env.local: Локальные переопределения. Этот файл загружается во всех окружениях, кроме test.
.env.development, .env.test, .env.production: Настройки для конкретной среды.
.env.development.local, .env.test.local, .env.production.local: Локальные переопределения настроек для конкретной среды.

Файлы слева имеют больший приоритет, чем файлы справа.

npm start: .env.development.local, .env.development, .env.local, .env
npm run build: .env.production.local, .env.production, .env.local, .env
npm test: .env.test.local, .env.test, .env (.env.local не участвует).

Разное

После добавления .env файлов при запущенном webpack-dev-server, его следует перезапустить.

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

// Wrong 
REACT_APP_KEY="TEST"
// Right
REACT_APP_KEY=TEST

Обычно .env файлы лежат в корне проекта.

Чтобы загрузить .env файл, в зависимости от окружения, в параметрах плагина можно указать переменную окружения NODE_ENV:

module.exports = env => {
  plugins: [
    new Dotenv({
      path: `./.env.${env.NODE_ENV}`,
      safe: false
    }),
   ]
};

Развертывание переменных окружения

Развертывание переменных уже присутствующих в системе в .env файле, используя dotenv-expand).

Например, чтобы получить переменную окружения npm_package_version:

REACT_APP_VERSION=$npm_package_version
# also works:
# REACT_APP_VERSION=${npm_package_version}

Или раскрыть переменные локально в текущем .env файле:

DOMAIN=www.example.com
REACT_APP_FOO=$DOMAIN/foo
REACT_APP_BAR=$DOMAIN/bar

Как собрать свой npm-пакет из форка

2020-04-17T21:00:00+00:00

В ходе разработки иногда может потребоваться внести в какую-нибудь библиотеку на гитхабе свой функционал, который нужен только на конкретном проекте или же библиотека давно не поддерживается и pull-request’ы никак не принимают. В таких случаях выходом из ситуации является создание своего форка библиотеки.

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

Пример записи в package.json:

"redux-saga-router": "luistorres/redux-saga-router#dist"

Другой вариант заключается в создании npm-пакета со своим scope (@username). Обычно берут свой username на гитхабе, но по сути можно написать все что угодно. Для публикации в npm потребуется зарегистрировать там аккаунт.

Далее нужно поменять имя пакета на @username/package-name и увеличить патч версию пакета в package.json. После этого переходим в консоль:

npm login

Вводим свои учетные данные.

Далее пишем команду для публикации:

npm publish

Однако так как мы используем scope, нужно дописать флаг --access public

npm publish --access public

После окончания процедуры устанавливаем новый пакет в свой проект:

npm i @username/package-name

В моей практике понадобилось завернуть широко используемую в проекте библиотеку в форк. Для этого мне нужно было бы поменять все импорты на другое имя пакета. Чтобы этого избежать, в npm есть возможность установить пакет под другим именем (алиасом):

npm i <alias_name>@npm:<original_package_name>

Таким образом имя меняется только в package.json. Например:

 "redux-form": "npm:@machinek56/redux-form@^8.3.1",

Автоматизация линтинга и форматирования. Как не отправить “плохой” код в репозиторий.

2020-04-09T21:00:00+00:00

Как часто вы пишете команды для запуска линтинга, тестов, форматирования кода?
А как часто пушите лишние коммиты, содержащие исправления по code style проекта?
В команде разработчиков сложно зачастую договориться о правилах форматирования кода, и на помощь нам приходит известный инструмент Prettier, который делает за нас всю грязную работу, а именно форматирует код согласно единому стилю по одной команде.

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

Husky

Инструмент для запуска команд при гит-хуках (commit, push). Для начала установим его:

npm install -D husky

Затем в package.json добавим секцию:

"husky": {
   "hooks": {
     "pre-commit": "YOUR_COMMAND_HERE",
     "pre-push": "YOUR_COMMAND_HERE"
   }
}

Lint-staged

Второй инструмент, позволяющий выполнять команды только над индексированными файлами. Установим его:

npm install -D lint-staged

Допишем в package.json секцию:

"lint-staged": {
    "*.{ts,tsx,js,css,less,json,md}": [
      "prettier --write"
    ]
}

Данная запись означает, что для файлов, чье расширение подходит по маске будет применяться команда prettier --write. С lint-staged v10.x больше не нужно писать вторую команду gid add, файлы автоматически будут добавлены в индекс.

Мы можем добавлять другие маски файлов и запускать над ними команды.

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

Итоговая конфигурация этих двух инструментов может выглядеть так:

"husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "pre-push": "yarn run tslint --fix && yarn run test"
    }
}

В этом примере перед пушем производится линтинг кода и запуск тестов. Если какая-то команда завершится неудачно (EXIT_CODE != 0), то операция commit или push не будет произведена.

Еще пример с другого проекта:

"husky": {
    "hooks": {
      "pre-commit": "npm run ts-compile-check && lint-staged" // компиляция ts и запуск lint-staged
    }
}
"lint-staged": {
   "*.(js|jsx|ts|tsx)": [
     "npm run lint" // запуск eslint --fix
   ]
}

Часто eslint и prettier используются вместе для автоматического исправления кода. Их настройку и работу вместе разберем в другом посте.

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

Использование разных ssh ключей для нескольких Bitbucket аккаунтов

2019-09-22T17:30:00+00:00

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

Создать ключи для каждого аккаунта

Генерируем новую пару ключей с помощью команды ниже в директории ` ~/.ssh/`

 ssh-keygen -t rsa -C "user1" -f "user1"

Ключ -C означает комментарий чтобы обозначить ssh-ключ. Ключ -f указывает на имя файла. Нужно создать ключи для всех аккаунтов, которые вы хотите добавить.

Добавить публичный ключ в аккаунты Bitbucket

Заходим в настройки аккаунта Bitbucket и добавляем ssh-ключ.

Конфигурируем SSH

В папке ~/.ssh/ создаем файл с названием config и вставляем туда конфиг ниже.

 #user1 account
 Host bitbucket.org-user1
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user1
     IdentitiesOnly yes

 #user2 account
 Host bitbucket.org-user2
     HostName bitbucket.org
     User git
     IdentityFile ~/.ssh/user2
     IdentitiesOnly yes

Заменяем user1 и user2 соответственно нужными значениями.

Конфигурируем Git репозиторий

Если нет локальной копии репозитория, то нужно склонировать его следующей командой:

 git clone git@bitbucket.org-user1:user1/your-repo-name.git

Если репозиторий уже склонирован, то нужно обновить origin:

git remote set-url origin git@bitbucket.org-user1:user1/your-repo-name.git

Если нужно поменять имя пользователя или email, то в папке проекта выполнить следующие действия:

git config user.name "user1"
git config user.email "user1@example.com"

Заменить user1 именем из конфига.

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

Создание виртуальных хостов в MAMP

2019-09-20T18:30:00+00:00

Чтобы поднять виртуальный хост на локальной машине, используя MAMP, необходимо:

Добавляем домен в hosts

Придумать имя хоста, например, domain.local, domain.loc или domain.test.

Открыть файл hosts через консоль sudo nano /etc/hosts и дописать имя хоста в строку с адресом 127.0.0.1, сохранить изменения и выйти.

127.0.0.1    localhost domain.local

Добавляем виртуальные хосты в apache конфиг

Перейти в директорию /Applications/MAMP/conf/apache/extra/ и открыть в редакторе файл httpd-vhosts.conf.

Найти dummy примеры, удалить и добавить следующее:

<VirtualHost *:80>
    DocumentRoot /Applications/MAMP/htdocs
    ServerName localhost
</VirtualHost>


<VirtualHost *:80>
    DocumentRoot "/Users/{username}/path/to/project"
    ServerName domain.local
</VirtualHost>

Заменить DocumentRoot и ServerName своими значениями.

Включение виртуальных хостов в общий конфиг

Далее открыть файл Applications/MAMP/conf/apache/httpd.conf и найти строчку

# Virtual Hosts
# Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

Раскомментировать вторую строчку с Include и сохранить файл.

Разрешаем FollowSymLinks

В этом же файле httpd.conf найти следующий фрагмент:

<Directory />
    Options Indexes FollowSymLinks
    AllowOverride None
</Directory>

Заменить None на All.

<Directory />
  Options Indexes FollowSymLinks
  AllowOverride All
</Directory

Установка порта 80 в apache

Установить порт apache 80 вместо 8888 в настройках MAMP.

На этом все, осталось перезапустить процессы MAMP и все должно заработать.

Создание symlink в Mac OS X

2018-05-25T18:20:00+00:00

Символическая ссылка (симлинк, symlink) - это запись, которая указывает на имя файла или директории. Символические ссылки можно создавать для каталогов и объектов, которые расположены в разных файловых системах. Если переименовать или переместить файл в другую директорию, символическая ссылка потеряет работоспособность.

Создание символической ссылки в Mac OS X

Для этого используем команду ln с флагом -s, что означает symbolic

ln -s /path/to/file /path/to/symlink

Чтобы создать или обновить симлинк, нужно использовать флаг -f

ln -sf /path/to/file /path/to/symlink

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

Настройка Nginx, PHP в Mac OS X

2018-05-20T14:40:54+00:00

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

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

Задача состояла в следующем: настроить виртуальный хост на папку /public проекта, подняв Nginx. Говно вопрос.

На моем маке уже стоял менеджер пакетов Homebrew, но если у вас его нет, скачать можно отсюда

Установка

Ставим nginx с помощью brew
```
brew install nginx
```
Запускаем nginx
```
sudo nginx
```
Открываем в браузере ссылку, если видим приветственную надпись Welcome to Nginx, значит nginx запущен и все хорошо.
```
http://127.0.0.1:8080/
```
Ставим PHP также с помощью brew. В Mac OS X PHP уже предустановлен, но можно и обновить.
```
brew install php
```

Конфигурация

Конфиг nginx по умолчанию находится по пути /usr/local/etc/nginx/

Создаем папки для локальных виртуальных хостов

mkdir -p /usr/local/etc/nginx/sites-{enabled,available}

Заменяем дефолтный конфиг nginx.conf этим:

worker_processes  1;

error_log  /usr/local/etc/nginx/logs/error.log debug;

events {
    worker_connections  256;
}

http {
    include             mime.types;
    default_type        application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /usr/local/etc/nginx/logs/access.log  main;

    sendfile            on;

    keepalive_timeout   65;

    index index.html index.php;

    include /usr/local/etc/nginx/sites-enabled/*;
}

Создаем файл project.local в sites-available

touch /usr/local/etc/nginx/sites-available/project.local

Вставляем туда конфиг

server {
  listen                80;
  listen                [::]:80;
  server_name           project.local;

  location / {
    root /Users/{username}/Projects/project/public/;
    try_files  $uri  $uri/  /index.php?$args;
    index  index.html index.htm index.php;
  }

  location ~ \.php$ {
    root  /Users/{username}/Projects/project/public/;
    try_files  $uri  $uri/  /index.php?$args;
    index  index.html index.htm index.php;

    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;


    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_intercept_errors on;
    include fastcgi_params;
  }

}

Линкуем наш хост в sites-enabled (создаем симлинк)

ln -s /usr/local/etc/nginx/sites-available/project.local /usr/local/etc/nginx/sites-enabled

Добавляем наш хост в hosts nano /etc/hosts

# Nginx sites

127.0.0.1        project.local

Тестим конфиг nginx

sudo nginx -t

И если ошибок/предупреждений нет, то обновляем новый конфиг nginx

brew services reload nginx

Проверяем доступность созданного хоста

curl -IL http://project.local:8080

Если видим что-то похожее ниже, то открываем в браузере project.local и радуемся жизни!

HTTP/1.1 200 OK
Server: nginx/1.13.12
Date: Sun, 20 May 2018 21:07:25 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 10 Apr 2018 14:11:19 GMT
Connection: keep-alive
ETag: "5accc607-264"
Accept-Ranges: bytes

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

UPD 25.05.2018

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

Первый пост

2018-04-14T21:40:54+00:00

Это первый пост, скорее всего его потом удалят. Но пусть он тут побудет немного.

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.