What's New Qiita

20190413のNode.jsに関する記事は12件です。

  • 投稿日：2019-04-13T21:43:26+09:00

Node.jsとnpmについて

なんとなく使っていたnode.jsとnpmについての今日、基礎を教わる機会があったのでメモ代わりに書いておく。

Node.jsのインストール

Node.jsとはサーバサイド側で動くJavaScriptのこと。

インストール方法は、まずはnodeのwebページに行く。
nodeのwebページ
スクリーンショット 2019-04-13 21.18.34.png

自分は最新版のインストールした。
インストールされているかの確認として、CLIでnode -vをたたく。

v11.14.0

と出ればnodeがインストールされている。

npmのインストール

npmとはNode Package Managerの略。
npmのインストール

sudo npm install -g npm

今回はグローバルにインストールをする。

npmもnpm -vでインストールができているか確認できる。

共同開発をする場合はpackage.jsonでライブラリの管理やバージョン管理を行う必要がある。
npmを使って、package.jsonを作る。

npm init

package.jsonができる。

package.jsonに必要なライブラリを追加していく。

sudo npm install ライブラリ名 --save

--saveオプションを付けることで、dependenciesにインストールされる。
dependenciesでは本番環境での動作に必要なライブラリ等をインストールしておく。

開発環境のみに必要なライブラリはdevDependenciesにインストールする。

sudo npm install ライブラリ名 --save-dev

これで共同開発をする場合にバージョン管理や必要なライブラリを同じ環境で動作することができるようになる。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T21:16:51+09:00

Electron + Express + React で Web・デスクトップ共通のアプリを作る

Electron + Express.js + React を使ってWebアプリとデスクトップアプリを共通のコードで作ってみたいと思います。

今回作成したコードは github に置いてあります。

参考にしたサイト

想定しているターゲット

あまり無いとは思いますが，普段，サーバに繋がる環境ではブラウザからアクセスしてアプリを実行するけど，稀にサーバに繋がらないスタンドアロンの環境でもアプリを実行するようなケースを想定しています。

動作確認環境

  • OS macOS Mojave
  • Electron 4.0.6
  • Express.js 4.16.0
  • React 16.8.6
  • Node.js v11.6.0

それでは早速ですが，アプリの雛形生成に express-generator を使用するので、インストールを行います。

$ npm install -g express-generator

"sample-app" という名前でアプリケーションを作成します。

$ express sample-app
$ cd sample-app

必要なパッケージをインストールします。

$ npm install

この時点で動作確認してみます。以下のコマンドを実行して

$ npm start

ブラウザで localhost:3000 にアクセスすると以下のような画面が表示されるはずです。

01.png

Electron のセットアップ

以下のコマンドで Electron をインストールします。

$ npm install --save-dev electron

続いて、app.js と同じ場所に main.js を作成します。

main.js
// Start Express
const expressApp = require('./app')
expressApp.listen(3000, '127.0.0.1')

// Electronのモジュール
const electron = require('electron')

// アプリケーションをコントロールするモジュール
const app = electron.app

// ウィンドウを作成するモジュール
const BrowserWindow = electron.BrowserWindow

// メインウィンドウはGCされないようにグローバル宣言
let mainWindow

// 全てのウィンドウが閉じたら終了
app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') {
    app.quit()
  }
})

// Electronの初期化完了後に実行
app.on('ready', () => {
  // メイン画面の表示。ウィンドウの幅、高さを指定できる
  mainWindow = new BrowserWindow({ width: 800, height: 600 })
  mainWindow.loadURL('http://127.0.0.1:3000')

  // ウィンドウが閉じられたらアプリも終了
  mainWindow.on('closed', () => {
    mainWindow = null
  })
})

package.json に以下の一行を追加します。

  "main": "main.js",

以下のコマンドを実行して動作確認します。

$ npx electron .

以下のような画面が表示されれば成功です。

02.png

npm-run-all で Web と Electron を同時に起動する

必須ではありませんが，一つのコマンドで Web サーバと Electron のアプリを同時に起動できると便利な事が多いのでここで設定しておきます。

npm-run-all という複数のタスクを同時に起動するパッケージを使用して、Web と Electron を同時に起動できるようにします。

まず以下のコマンドで npm-run-all をインストールします。

$ npm install --save-dev npm-run-all

次に package.json を以下のように修正します。

package.json
  "scripts": {
    "start": "node ./bin/www",
    "electron": "electron .",
    "dev": "npm-run-all --parallel electron start",
    "package": "npx electron-packager . sample-app --platform=darwin --arch=x64 --overwrite"
  }

これで以下のコマンドで Web サーバと Electron アプリが同時に起動できるようになりました。

$ npm run dev

React の追加

下記のコマンドで React のパッケージをインストールします。

npm install --save react react-dom

Jade は使用しないので削除しておきます。

npm uninstall --save jade

まずは Hello World を作成してみます。

public/index.html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <title>sample-app</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="text/javascript" src="javascripts/app.js" charset="utf-8"></script>
  </body>
</html>

"Hello, world" を返す React のコンポーネントを作成します。

src/index.js
import React from 'react'
import ReactDOM from 'react-dom'

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
)

これでソース自体の作成は完了です。後は実行するための設定を行います。

不要な処理・ファイルの削除

"express-generator" が作成したファイル・コードの中で不要になったものを削除します。

$ rm routes/*.js
$ rm -rf views

app.js の以下の行を削除します。

app.js
var indexRouter = require('./routes/index')
var usersRouter = require('./routes/users')

// view engine setup
app.set('views', path.join(__dirname, 'views'))
app.set('view engine', 'jade')

app.use('/', indexRouter)
app.use('/users', usersRouter)

Babel と Webpack の設定

JSX から JavaScript への変換に使用する Babel のインストールと設定行います。

$ npm install --save-dev babel babel-core babel-loader@7 babel-preset-env babel-preset-react

.babelrc に以下の内容を記述します。

.babelrc
{
  "presets": ["env", "react"]
}

Webpack のインストール

$ npm install --save-dev webpack webpack-cli

$ npm install --save-dev babel-loader css-loader style-loader
package.json
  "build": "webpack -d"
wabpack.config.js
const path = require('path')
module.exports = {
  mode: 'development',
  entry: {
    app: path.join(__dirname, 'src/index.js')
  },
  output: {
    path: path.join(__dirname, 'public/javascripts'),
    filename: '[name].js'
  },
  devtool: 'inline-source-map',
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: 'babel-loader'
      }, {
        test: /\.css$/,
        loader: ['css-loader', 'style-loader']
      }
    ]
  }
}

この時点で以下のコマンドを実行すると

$ npm run build
$ npm run dev

以下のような画面が表示され、またブラウザで localhost にアクセスすると同様な画面が表示されると思います。

hello_world.png

React と Express の連携

月並みですが，サーバ側（Express）でおみくじの結果を生成して画面に表示する処理を実装してみたいと思います。

クライアントからサーバへのAjax通信には "SuperAgent" を使うのではじめにインストールしておきます。

$ nom install --save superagent

サーバ側の実装

"/api/kuji" にアクセスされると "{result: '大吉'}" のような JSON データを返す API を実装します。

routes/kuji.js
var express = require('express')

var router = express.Router()

const kuji = ['大吉', '吉', '凶']

const get_kuji = () => {
  const rnd = Math.floor(Math.random() * kuji.length)
  return kuji[rnd]
}

// GET /api/kuji で呼ばれる関数
router.get('/', (req, res) => {
  res.json({result: get_kuji()})
})

module.exports = router
app.js
var kuji = require('./routes/kuji')

app.use('/api/kuji', kuji)

この時点で，npm start でサーバを起動してブラウザから http://localhost:3000/api/kuji へアクセスすると以下のような JSON のデータが表示されるはずです。

api.png

クライアント側の実装

画面上の「ひく」ボタンをクリックすると，おみくじの結果が画面に表示されるコンポーネントを作成します。

/src/index.js
import React from 'react'
import ReactDOM from 'react-dom'
import request from 'superagent'

class Kuji extends React.Component {
  constructor(props) {
    super(props)
    // デフォルトの state を設定
    this.state = { result: '' }
    // api() の中で this にアクセスできるよう bind しておく
    this.api = this.api.bind(this)
  }

  // サーバ側にアクセス（GET /api/kuji）して結果を取得して state に格納する
  api () {
    request.get('api/kuji').end((err, res) => {
      if (err) {
        console.log(err)
        return
      }
      const result = res.body.result
      this.setState({ result: result })
    })        
  }

  render () {
    return (
      <div>
        <p>{this.state.result}</p>
        <button onClick={ e => this.api() }>ひく</button>
     </div>
    )
  }
}

ReactDOM.render(
  <Kuji />,
  document.getElementById('root')
)

この時点で以下のコマンドを実行して

$ npm run build
$ npm run dev

画面上の「ひく」ボタンをクリックすると以下のような画面が表示されると思います。

kuji.png

以上で終わりです。通常の Express, React でアプリを書いたコードがそのままネイティブアプリ化できるのは便利なケースもあるのではないかと思います。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T19:34:20+09:00

serverlessでlambdaをデプロイする

概要

AWSのlambdaはAWS Management Console内で直接書くこともできますが、
gitでソースコードを管理して、CLIからデプロイしたいと思うことはありませんか？

当記事ではserverlessを使って
Node.jsで実装したサンプルをlambdaにデプロイする手順の例を示します。

デプロイユーザーのアクセスキーの取得

※ AWS Management Consoleでの作業になります
1. IAM->Users -> デプロイに使うユーザー -> Security credentials -> Create access key
※デプロイに使うユーザーはデプロイ用のサービスアカウントが好ましいでしょう。
image.png
2. Access key ID と Secret access key を保管する。（Download .csv fileでCSVをダウンロードしておくのが良いでしょう。）
image.png

デプロイユーザーへの権限付与

serverlessでlambdaをデプロイするには、デプロイユーザーにデプロイ用の権限が必要です。
ここでは、ポリシーの設定手順の例を示します。

※ AWS Management Consoleでの作業になります
1. IAM->Policies->Create policy をクリック ->JSON タブをクリック
2. 下記を貼り付け

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:*",
                "apigateway:*",
                "s3:*",
                "logs:*",
                "lambda:*",
                "cloudformation:*"
            ],
            "Resource": "*"
        }
    ]
}

※ActionやResourceは、セキュリティの観点からは必要なポリシーやリソースをもっと限定的に指定するのが好ましいですが、数が多くて細部の洗い出しが大変だったため、ワイルドカードでざっくりと指定をしました。
3. ポリシー名は任意ですが、ここでは例としてlambdaDeployPolicyとしてポリシーを作成します。
4. IAM -> Users -> デプロイユーザーを選択 -> Add permissions -> Attach existing policies directly
5. 3.で作成したlambdaDeployPolicyを選択し、Next: Review -> Add permissions でポリシーを追加

awscliのインストール

$ brew install awscli

awscliにデプロイユーザーとしてログイン

$ aws configure
AWS Access Key ID [None]: <Access key IDを貼り付け>
AWS Secret Access Key [None]: <Secret access key> を貼り付け
Default region name [None]: ap-northeast1
Default output format [None]: <そのままエンター>

serverlessのインストール

$ npm i -g serverless

serverlessプロジェクトの生成

$ sls create --template aws-nodejs --path lambda-deploy-serverless
$ cd lambda-deploy-serverless

serverlessの設定ファイルを更新

デフォルトだとリージョンがus-east1になっていたり、APIゲートウェイの設定は含まれていないので、下記のように指定を加えます

serverless.yml(更新)
service: lambda-deploy-serverless
provider:
  name: aws
  runtime: nodejs8.10
  stage: dev
  region: ap-northeast-1 # ap-northeast-1リージョンにデプロイする
functions:
  hello: # 関数名の指定
    handler: handler.hello
    events:
      - http: # API Gatewayの指定
          path: hello
          method: get

その他の設定はこちらのリファレンスを参照:
https://serverless.com/framework/docs/providers/aws/guide/serverless.yml/

デプロイ

$ sls deploy
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service lambda-deploy-serverless.zip file to S3 (45.3 KB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
........................
Serverless: Stack update finished...
Service Information
service: lambda-deploy-serverless
stage: dev
region: ap-northeast-1
stack: lambda-deploy-serverless-dev
resources: 10
api keys:
  None
endpoints:
  GET - https://ew7w6wfmxe.execute-api.ap-northeast-1.amazonaws.com/dev/hello
functions:
  hello: lambda-deploy-serverless-dev-hello
layers:
  None

このようにLambdaがデプロイされていれば成功です
image.png

もしもエラーになる場合は、ログのエラー箇所を参照して、ポリシーが適切に設定されているか確認して下さい。

詳細ログを標準出力に出力させるには、下記のようにします

SLS_DEBUG=* serverless deploy
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T19:34:20+09:00

serverlessでCLIからlambdaをデプロイする

概要

AWSのlambdaはAWS Management Console内で直接書くこともできますが、
gitでソースコードを管理して、CLIからデプロイしたいと思うことはありませんか？

当記事ではServerlessを使って
Node.jsで実装したサンプルをlambdaにデプロイする手順の例を示します。

筆者がCLIでのAWS操作にあまりなれていなかったのもあり、本記事ではAWS Management Consoleでの操作手順もやや掘り下げて記載していますが、
Serverlessの基本機能はServerlessのメンテナでもある@horike37さんの下記の記事により詳しくまとまっているので、そちらを参照いただくのが良いと思いました。
Serverless Frameworkの使い方まとめ

awscliのインストール

$ brew install awscli

デプロイユーザーのアクセスキーの取得

デプロイに利用するアカウントでawscliでログインするために、AWS Management Consoleでユーザーの認証情報を取得します。

  1. IAM->Users -> デプロイに使うユーザー -> Security credentials -> Create access key image.png
  2. Access key ID と Secret access key を保管する。（Download .csv fileでCSVをダウンロードしておくのが良いでしょう。） image.png

デプロイユーザーへの権限付与

serverlessでlambdaをデプロイするには、デプロイユーザーにデプロイ用の権限が必要です。
ここでは、ポリシーの設定手順の例を示します。

  1. IAM->Policies->Create policy をクリック ->JSON タブをクリック
  2. 下記を貼り付け
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:*",
                "apigateway:*",
                "s3:*",
                "logs:*",
                "lambda:*",
                "cloudformation:*"
            ],
            "Resource": "*"
        }
    ]
}

※ActionやResourceは、セキュリティの観点からは必要なポリシーやリソースをもっと限定的に指定するのが好ましいですが、数が多くて細部の洗い出しが大変だったため、ワイルドカードでざっくりと指定をしました。
3. ポリシー名は任意ですが、ここでは例としてlambdaDeployPolicyとしてポリシーを作成します。
4. IAM -> Users -> デプロイユーザーを選択 -> Add permissions -> Attach existing policies directly
5. 3.で作成したlambdaDeployPolicyを選択し、Next: Review -> Add permissions でポリシーを追加

awscliにデプロイユーザーとしてログイン

$ aws configure
AWS Access Key ID [None]: <Access key IDを貼り付け>
AWS Secret Access Key [None]: <Secret access key> を貼り付け
Default region name [None]: ap-northeast1
Default output format [None]: <そのままエンター>

serverlessのインストール

$ npm i -g serverless

serverlessプロジェクトの生成

$ sls create --template aws-nodejs --path lambda-deploy-serverless
$ cd lambda-deploy-serverless

serverlessの設定ファイルを更新

デフォルトだとリージョンがus-east1になっていたり、APIゲートウェイの設定は含まれていないので、下記のように指定を加えます

serverless.yml(更新)
service: lambda-deploy-serverless
provider:
  name: aws
  runtime: nodejs8.10
  stage: dev
  region: ap-northeast-1 # ap-northeast-1リージョンにデプロイする
functions:
  hello: # 関数名の指定
    handler: handler.hello
    events:
      - http: # API Gatewayの指定
          path: hello
          method: get

その他の設定はこちらのリファレンスを参照:
https://serverless.com/framework/docs/providers/aws/guide/serverless.yml/

デプロイ

$ sls deploy
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service lambda-deploy-serverless.zip file to S3 (45.3 KB)...
Serverless: Validating template...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
........................
Serverless: Stack update finished...
Service Information
service: lambda-deploy-serverless
stage: dev
region: ap-northeast-1
stack: lambda-deploy-serverless-dev
resources: 10
api keys:
  None
endpoints:
  GET - https://ew7w6wfmxe.execute-api.ap-northeast-1.amazonaws.com/dev/hello
functions:
  hello: lambda-deploy-serverless-dev-hello
layers:
  None

このようにLambdaがデプロイされていれば成功です
image.png

もしもエラーになる場合は、ログのエラー箇所を参照して、ポリシーが適切に設定されているか確認して下さい。

詳細ログを標準出力に出力させるには、下記のようにします

SLS_DEBUG=* serverless deploy
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T18:42:04+09:00

WebStormとDockerでコンテナ内に依存ライブラリを閉じ込めてReactの開発環境を作成

ローカル環境に色々入れずに開発環境をDocker上で構築したいけど、コーディングはIDEを使いたいので自分が辿り着いた手順をまとめました。
似たようなことをすればIntelliJ, PyCharm, GoLand, RubyMine, PhpStormでもできそう。

前提

  • WebStorm(or IntelliJ)をインストールしている
  • MacでDocker for Macをインストールしている

WebStormで新規Project作成

[File] -> [New] -> [Project]
image.png

[Empty Project]を選択し、Locationにプロジェクト名を設定して[CREATE]

Setting Value Remark
Location: {PROJECT PATH} PATHの末尾がプロジェクト名

image.png

空のプロジェクトが作成される
image.png

Dockerの設定

コマンドラインかWebStormのGUIのどちらかで設定すれば良い

Dockerfileを利用してコマンドラインで設定する場合

Terminalで以下を実行したあと、Ctrl ＋ p->Ctrl ＋ qで接続したコンテナから抜ける

[LOCAL]$ docker run \
-it \
-p 13000:3000 \
-v {PROJECT PATH}:/app \
--name {CONTAINER NAME} \
-w /app \
node:lts-alpine
Setting Value Remarks
-p 13000:3000 HOST:DOCKERの順で設定し、DockerコンテナのportへLocalからアクセスできるようにする。何個も起動させる場合、HOST側のportは重ならないように変えること。
-v {PROJECT PATH}:/app HOST:DOCKERの順で設定し、Dockerコンテナの/appディレクトリと先ほどLocalで作成したWebStormのプロジェクトディレクトリへ同期させることができる。
--name {CONTAINER NAME} 起動したコンテナにつける名前。今回はnode-dockerとしている。
-w app コンテナ起動時に/appディレクトリを作成してコンテナへ接続した時のデフォルトディレクトリになる

WebStormのDockerプラグインで設定する場合

[WebStorm] -> [Preferences...] で [Build, Execution, Deployment]にあるDockerの設定画面を選択し、+ボタンで新規作成
image.png
image.png

Docker for Macを利用しているので、これを選択し適当に名前をつけて[OK]を選択
image.png

（今回は画面の左下に）Dockerのタブが現れたので▷(Connect)を押すと、ConnectedとなりContainersとImagesというのが表示される
image.png
image.png

Imagesを選択してPull Image
image.png

今回はnode:lts-alpineを利用

Setting Value Remarks
Registry: registry.hub.docker.com デフォルトの設定
Repository: node
Tag: lts-alpine ここは好きなのを選んで良い。今回は軽量と聞くalpineのlts版にした

image.png

Imagesに選択したDockerのimageが表示される
image.png

このimageからコンテナ作成のため+->Create..
image.png
image.png

コンテナ起動の設定を以下のようにしてRUN

Setting Value Remarks
Container name: {CONTAINER NAME} 起動したコンテナにつける名前。今回はnode-dockerとしている。
Bind ports: 13000:3000 HOST:DOCKERの順で設定し、DockerコンテナのportへLocalからアクセスできるようにする
Bind mounts: {PROJECT PATH}:/app HOST:DOCKERの順で設定し、Dockerコンテナの/appディレクトリとLocalで作成したWebStormのプロジェクトディレクトリへ同期させることができる
Run options: -w app コンテナ起動時に/appディレクトリを作成してコンテナへ接続した時のデフォルトディレクトリになる

image.png

Deploy logにコンテナ作成が成功されたログが表示されればOK
image.png

TerminalからDockerコンテナに接続してプロジェクト作成

# コンテナの起動確認
[LOCAL]$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS                     NAMES
febece633a44        aa57b0242b33        "node"              About a minute ago   Up About a minute   0.0.0.0:13000->3000/tcp   node-docker

# コンテナへ接続
[LOCAL]$ docker exec -it node-docker /bin/sh
/app #

ここからdocker上での実行コマンド
コンテナシェルのPS1部分/app #は[DOCKER]$に読みかえてる
https://facebook.github.io/create-react-app/docs/adding-typescript を参考にtypescriptのReactプロジェクトを作成

# nodeのversion確認
[DOCKER]$ node --version
v10.15.3

# /appディレクトリにプロジェクト作成
[DOCKER]$ npx create-react-app /app --typescript
npx: installed 63 in 3.522s

Creating a new React app in /app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

yarn add v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.7: The platform "linux" is incompatible with this module.
info "fsevents@1.2.7" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.4: The platform "linux" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 13 new dependencies.
info Direct dependencies
├─ @types/jest@24.0.11
├─ @types/node@11.13.4
~ 省略 ~

Your tsconfig.json has been populated with default values.


Success! Created app at /app
Inside that directory, you can run several commands:

  yarn start
    Starts the development server.

  yarn build
    Bundles the app into static files for production.

  yarn test
    Starts the test runner.

  yarn eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd /app
  yarn start

Happy hacking!

Dockerコンテナの/appディレクトリに作成されたプロジェクトがWebStorm上からも見えるようになった!!
image.png

動作確認

# デフォルトプロジェクトの起動
[DOCKER]$ yarn start
~省略
Compiled successfully!

You can now view app in the browser.

  Local:            http://localhost:3000/
  On Your Network:  http://172.17.0.2:3000/

Note that the development build is not optimized.
To create a production build, use yarn build.

ブラウザでhttp://localhost:13000/ へアクセスし、デフォルトアプリが表示されることが確認できた！
image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T18:42:04+09:00

Dockerコンテナに依存関係は全て閉じ込めてWebStormで開発 ~ローカルを汚さずにReactやFirebaseの環境構築を簡単に~

ローカル環境に色々入れずに開発環境をDocker上で構築したいけど、コーディングはIDEを使いたいので自分が辿り着いた手順をまとめました。
似たようなことをすればIntelliJ, PyCharm, GoLand, RubyMine, PhpStormでもできそう。

できること

  • ローカルPCにnodeなどを入れずにReactやFirebaseのアプリを開発できる
  • Firebaseの複数プロジェクトに対してデプロイしたい場合、アプリのディレクトリごとにFirebaseプロジェクトを割り当てられるので毎回firebase loginで切り替えずにデプロイできる

前提

  • WebStorm(or IntelliJ)をインストールしている
  • MacでDocker for Macをインストールしている

WebStormで新規Project作成

[File] -> [New] -> [Project]
image.png

[Empty Project]を選択し、Locationにプロジェクト名を設定して[CREATE]

Setting Value Remark
Location: {PROJECT PATH} PATHの末尾がプロジェクト名

image.png

空のプロジェクトが作成される
image.png

Dockerの設定

コマンドラインかWebStormのGUIのどちらかで設定すれば良い

Dockerfileを利用してコマンドラインで設定する場合

Terminalで以下を実行したあと、Ctrl ＋ p->Ctrl ＋ qで接続したコンテナから抜ける

[LOCAL]$ docker run \
-it \
-p 13000:3000 \
-v {PROJECT PATH}:/app \
--name {CONTAINER NAME} \
-w /app \
node:lts-alpine
Setting Value Remarks
-p 13000:3000 HOST:DOCKERの順で設定し、DockerコンテナのportへLocalからアクセスできるようにする。何個も起動させる場合、HOST側のportは重ならないように変えること。
-v {PROJECT PATH}:/app HOST:DOCKERの順で設定し、Dockerコンテナの/appディレクトリと先ほどLocalで作成したWebStormのプロジェクトディレクトリへ同期させることができる。
--name {CONTAINER NAME} 起動したコンテナにつける名前。今回はnode-dockerとしている。
-w app コンテナ起動時に/appディレクトリを作成してコンテナへ接続した時のデフォルトディレクトリになる

WebStormのDockerプラグインで設定する場合

[WebStorm] -> [Preferences...] で [Build, Execution, Deployment]にあるDockerの設定画面を選択し、+ボタンで新規作成
image.png
image.png

Docker for Macを利用しているので、これを選択し適当に名前をつけて[OK]を選択
image.png

（今回は画面の左下に）Dockerのタブが現れたので▷(Connect)を押すと、ConnectedとなりContainersとImagesというのが表示される
image.png
image.png

Imagesを選択してPull Image
image.png

今回はnode:lts-alpineを利用

Setting Value Remarks
Registry: registry.hub.docker.com デフォルトの設定
Repository: node
Tag: lts-alpine ここは好きなのを選んで良い。今回は軽量と聞くalpineのlts版にした

image.png

Imagesに選択したDockerのimageが表示される
image.png

このimageからコンテナ作成のため+->Create..
image.png
image.png

コンテナ起動の設定を以下のようにしてRUN

Setting Value Remarks
Container name: {CONTAINER NAME} 起動したコンテナにつける名前。今回はnode-dockerとしている。
Bind ports: 13000:3000 HOST:DOCKERの順で設定し、DockerコンテナのportへLocalからアクセスできるようにする
Bind mounts: {PROJECT PATH}:/app HOST:DOCKERの順で設定し、Dockerコンテナの/appディレクトリとLocalで作成したWebStormのプロジェクトディレクトリへ同期させることができる
Run options: -w app コンテナ起動時に/appディレクトリを作成してコンテナへ接続した時のデフォルトディレクトリになる

image.png

Deploy logにコンテナ作成が成功されたログが表示されればOK
image.png

Reactのプロジェクト作成

TerminalからDockerコンテナに接続して、Docker上にReactプロジェクトを作成する

# コンテナの起動確認
[LOCAL]$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS                     NAMES
febece633a44        aa57b0242b33        "node"              About a minute ago   Up About a minute   0.0.0.0:13000->3000/tcp   node-docker

# コンテナへ接続
[LOCAL]$ docker exec -it node-docker /bin/sh
/app #

ここからdocker上での実行コマンド
コンテナシェルのPS1部分/app #は[DOCKER]$に読みかえてる
https://facebook.github.io/create-react-app/docs/adding-typescript を参考にtypescriptのReactプロジェクトを作成

# nodeのversion確認
[DOCKER]$ node --version
v10.15.3

# /appディレクトリにプロジェクト作成
[DOCKER]$ npx create-react-app /app --typescript
npx: installed 63 in 3.522s

Creating a new React app in /app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

yarn add v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.7: The platform "linux" is incompatible with this module.
info "fsevents@1.2.7" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.4: The platform "linux" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 13 new dependencies.
info Direct dependencies
├─ @types/jest@24.0.11
├─ @types/node@11.13.4
~ 省略 ~

Your tsconfig.json has been populated with default values.


Success! Created app at /app
Inside that directory, you can run several commands:

  yarn start
    Starts the development server.

  yarn build
    Bundles the app into static files for production.

  yarn test
    Starts the test runner.

  yarn eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd /app
  yarn start

Happy hacking!

Dockerコンテナの/appディレクトリに作成されたプロジェクトがWebStorm上からも見えるようになった!!
image.png

動作確認

# デフォルトプロジェクトの起動
[DOCKER]$ yarn start
~省略
Compiled successfully!

You can now view app in the browser.

  Local:            http://localhost:3000/
  On Your Network:  http://172.17.0.2:3000/

Note that the development build is not optimized.
To create a production build, use yarn build.

ブラウザでhttp://localhost:13000/ へアクセスし、デフォルトアプリが表示されることが確認できた！
image.png

あとは好きに開発するだけ!!

FirebaseプロジェクトごとにDocker開発環境を作成

WebStormで新規Project作成しておく

# firebaseを利用するためまずはnodeのimageからコンテナを起動させる
[LOCAL]$ docker run \
-it \
--name firebase-skeleton \
-v {WEBSTORM PROJECTPATH}:/app \
-w /app \
node:lts-alpine

# 起動したコンテナに接続する
[LOCAL]$ docker exec -it firebase-skeleton /bin/sh

# firebaseのツールをインストール
[DOCKER]$ npm install -g firebase-tools
# 手順にしたがって利用したいgoogleアカウントでログインする
[DOCKER]$ firebase login --no-localhost
# Firebaseプロジェクトを選択or新規作成し、セットアップする(今回はCloud Functionsをセットアップ)
[DOCKER]$ firebase init functions

# ログイン状態のコンテナをcommitしてimage化する
[LOCAL]$ docker stop firebase-skeleton
[LOCAL]$ docker commit firebase-skeleton {FIREBASE PROJECT NAME}:{YOUR TAG}
# 不要になったコンテナは削除
[LOCAL]$ docker rm firebase-skeleton

# imageが作成されていることの確認
[LOCAL]$ docker images
REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE
{FIREBASE PROJECT NAME}     {YOUR TAG}          c939d073f6a0        8 seconds ago       297MB
node                        lts-alpine          aa57b0242b33        4 days ago          71MB

# 指定したFirebaseプロジェクトにログイン状態のimageをコンテナ起動
[LOCAL}$ docker run \
-it \
--name {CONTAINER NAME} \
-v {WEBSTORM PROJECTPATH}:/app \
-w /app \
myfirebase/{FIREBASE PROJECT NAME}:{YOUR TAG}

WebStormでファイルを修正できるようになるのでfunctionを作成
今回はTypeScriptでCloud Functionsを作成するのでfunctions/src/index.tsをWebStormから変更
image.png

index.ts
import * as functions from 'firebase-functions';

export const helloWorld = functions.https.onRequest((request, response) => {
 response.send("Hello from Firebase!!!!");
});

動作確認

ログイン状態のimageを利用しているのでloginせずにFirebaseへデプロイできる!!

# 起動したコンテナに接続する
[LOCAL]$ docker exec -it {CONTAINER NAME} /bin/sh

# functionを作成してデプロイ(init時にTypeScriptを選択していると、このコマンド内でtsのコンパイルもしてくれる)
[DOCKER]$ firebase deploy --only functions
~省略~
✔  functions: Finished running predeploy script.
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (33.39 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: creating Node.js 6 function helloWorld(us-central1)...
✔  functions[helloWorld(us-central1)]: Successful create operation. 
Function URL (helloWorld): https://XXXXXXX.cloudfunctions.net/helloWorld

✔  Deploy complete!

Please note that it can take up to 30 seconds for your updated functions to propagate.
Project Console: https://console.firebase.google.com/project/{FIREBASE PROJECT NAME}/overview

Function URLで表示されたURLへアクセス
image.png

これで複数のFirebaseプロジェクトへデプロイしたい場合に、ローカルでloginを切り替えずに実行できる!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T18:42:04+09:00

WebStormとDockerでlocalにnodeを入れずにReactの開発環境を作成

前提

  • WebStorm(or IntelliJ)をインストールしている
  • MacでDocker for Macをインストールしている

WebStormで新規Project作成

[File] -> [New] -> [Project]
image.png

[Empty Project]を選択し、Locationにプロジェクト名を設定して[CREATE]

Setting Value Remark
Location: {PROJECT PATH} PATHの末尾がプロジェクト名

image.png

空のプロジェクトが作成される
image.png

Dockerの設定

コマンドラインかWebStormのGUIのどちらかで設定すれば良い

Dockerfileを利用してコマンドラインで設定する場合

Terminalで以下を実行

[LOCAL]$ docker run \
-it \
-p 13000:3000 \
-v {PROJECT PATH}:/app \
--name {CONTAINER NAME} \
-w /app \
node:lts-alpine
Setting Value Remarks
-p 13000:3000 HOST:DOCKERの順で設定し、DockerコンテナのportへLocalからアクセスできるようにする。何個も起動させる場合、HOST側のportは重ならないように変えること。
-v {PROJECT PATH}:/app HOST:DOCKERの順で設定し、Dockerコンテナの/appディレクトリと先ほどLocalで作成したWebStormのプロジェクトディレクトリへ同期させることができる。
--name {CONTAINER NAME} 起動したコンテナにつける名前。今回はnode-dockerとしている。
-w app コンテナ起動時に/appディレクトリを作成してコンテナへ接続した時のデフォルトディレクトリになる

WebStormのDockerプラグインで設定する場合

[WebStorm] -> [Preferences...] で [Build, Execution, Deployment]にあるDockerの設定画面を選択し、+ボタンで新規作成
image.png
image.png

Docker for Macを利用しているので、これを選択し適当に名前をつけて[OK]を選択
image.png

（今回は画面の左下に）Dockerのタブが現れたので▷(Connect)を押すと、ConnectedとなりContainersとImagesというのが表示される
image.png
image.png

Imagesを選択してPull Image
image.png

今回はnode:lts-alpineを利用

Setting Value Remarks
Registry: registry.hub.docker.com デフォルトの設定
Repository: node
Tag: lts-alpine ここは好きなのを選んで良い。今回は軽量と聞くalpineのlts版にした

image.png

Imagesに選択したDockerのimageが表示される
image.png

このimageからコンテナ作成のため+->Create..
image.png
image.png

コンテナ起動の設定を以下のようにしてRUN

Setting Value Remarks
Container name: {CONTAINER NAME} 起動したコンテナにつける名前。今回はnode-dockerとしている。
Bind ports: 13000:3000 HOST:DOCKERの順で設定し、DockerコンテナのportへLocalからアクセスできるようにする
Bind mounts: {PROJECT PATH}:/app HOST:DOCKERの順で設定し、Dockerコンテナの/appディレクトリとLocalで作成したWebStormのプロジェクトディレクトリへ同期させることができる
Run options: -w app コンテナ起動時に/appディレクトリを作成してコンテナへ接続した時のデフォルトディレクトリになる

image.png

Deploy logにコンテナ作成が成功されたログが表示されればOK
image.png

TerminalからDockerコンテナに接続してプロジェクト作成

# コンテナの起動確認
[LOCAL]$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS                     NAMES
febece633a44        aa57b0242b33        "node"              About a minute ago   Up About a minute   0.0.0.0:13000->3000/tcp   node-docker

# コンテナへ接続
[LOCAL]$ docker exec -it node-docker /bin/sh
/app #

ここからdocker上での実行コマンド
コンテナシェルのPS1部分/app #は[DOCKER]$に読みかえてる
https://facebook.github.io/create-react-app/docs/adding-typescript を参考にtypescriptのReactプロジェクトを作成

# nodeのversion確認
[DOCKER]$ node --version
v10.15.3

# /appディレクトリにプロジェクト作成
[DOCKER]$ npx create-react-app /app --typescript
npx: installed 63 in 3.522s

Creating a new React app in /app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

yarn add v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.7: The platform "linux" is incompatible with this module.
info "fsevents@1.2.7" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.4: The platform "linux" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 13 new dependencies.
info Direct dependencies
├─ @types/jest@24.0.11
├─ @types/node@11.13.4
~ 省略 ~

Your tsconfig.json has been populated with default values.


Success! Created app at /app
Inside that directory, you can run several commands:

  yarn start
    Starts the development server.

  yarn build
    Bundles the app into static files for production.

  yarn test
    Starts the test runner.

  yarn eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd /app
  yarn start

Happy hacking!

Dockerコンテナの/appディレクトリに作成されたプロジェクトがWebStorm上からも見えるようになった!!
image.png

動作確認

# デフォルトプロジェクトの起動
[DOCKER]$ yarn start
~省略
Compiled successfully!

You can now view app in the browser.

  Local:            http://localhost:3000/
  On Your Network:  http://172.17.0.2:3000/

Note that the development build is not optimized.
To create a production build, use yarn build.

ブラウザでhttp://localhost:13000/ へアクセスし、デフォルトアプリが表示されることが確認できた！
image.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T17:24:14+09:00

Firebaseのfunctionsでsync/awaitしようと思ったら怒られた件

ちょっと困った症状

  • Firebase の functions で sync/await を使ったらデプロイが error になってしまう
  • ローカルでfirebase functions:shellで、直接関数を動かすと問題ない（ローカルでは問題ない）

原因と対策

うまくいかない原因は二つ。

原因1 - デプロイ時にESLintが怒ってる

エラーはこんな感じ

asyncの入ってるところでエラーになる

61:9  error  Parsing error: Unexpected token function
✖ 1 problem (1 error, 0 warnings)

対策1

.eslintrc.jsonを以下のように"ecmaVersion": 2017とする。Firebaseがつくるデフォルト設定 "ecmaVersion": 6 だと、ESLintはsync/awaitを解釈しない模様

  "parserOptions": {
    // Required for certain syntax usages
    //"ecmaVersion": 6
    "ecmaVersion": 2017
  },

関連するstackoverflowのQ&A

原因2 - node のバージョンが sync/await に対応していない

エラーはこんな感じ

asyncの入ってるところでエラーになる

⚠  functions[getSentiment2(us-central1)]: Deployment error.
Function failed on loading user code. Error message: Code in file index.js can't be loaded.
Is there a syntax error in your code?
Detailed stack trace: /user_code/index.js:61
  async function quickstart() {
        ^^^^^^^^

対策2

packeges.json に "engines": { "node": "8" }を追加して、node のバージョン8を指定する。FireBaseの node ってデフォルトが6っぽくて、8以降じゃないと sync/await がつかえないみたいです。この状態でデプロイすると

i  functions: updating Node.js 8 function func1(your-region)...
i  functions: updating Node.js 8 function func2(your-region)...

と表示されて、デプロイできました。

関連するstackoverflowのQ&A

おんなじようなことをしようとしているみなさんの時間の節約になればと思います。

参考にさせていただきました

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T17:24:14+09:00

Firebaseのfunctionsでasync/awaitしようと思ったら怒られた件

ちょっと困った症状

  • Firebase の functions で sync/await を使ったらデプロイが error になってしまう
  • ローカルでfirebase functions:shellで、直接関数を動かすと問題ない（ローカルでは問題ない）

原因と対策

うまくいかない原因は二つ。

原因1 - デプロイ時にESLintが怒ってる

エラーはこんな感じ

asyncの入ってるところでエラーになる

61:9  error  Parsing error: Unexpected token function
✖ 1 problem (1 error, 0 warnings)

対策1

.eslintrc.jsonを以下のように"ecmaVersion": 2017とする。Firebaseがつくるデフォルト設定 "ecmaVersion": 6 だと、ESLintはsync/awaitを解釈しない模様

  "parserOptions": {
    // Required for certain syntax usages
    //"ecmaVersion": 6
    "ecmaVersion": 2017
  },

関連するstackoverflowのQ&A

原因2 - node のバージョンが sync/await に対応していない

エラーはこんな感じ

asyncの入ってるところでエラーになる

⚠  functions[getSentiment2(us-central1)]: Deployment error.
Function failed on loading user code. Error message: Code in file index.js can't be loaded.
Is there a syntax error in your code?
Detailed stack trace: /user_code/index.js:61
  async function quickstart() {
        ^^^^^^^^

対策2

packeges.json に "engines": { "node": "8" }を追加して、node のバージョン8を指定する。FireBaseの node ってデフォルトが6っぽくて、8以降じゃないと sync/await がつかえないみたいです。この状態でデプロイすると

i  functions: updating Node.js 8 function func1(your-region)...
i  functions: updating Node.js 8 function func2(your-region)...

と表示されて、デプロイできました。

関連するstackoverflowのQ&A

参考にさせていただきました

おわりに

誰かの時間の節約になれば。

Cheers,

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T17:24:14+09:00

Firebase の functions で async/await しようと思ったら怒られた件

ちょっと困った症状

  • Firebase の functions で async/await を使ったらデプロイが error になってしまう
  • ローカルでfirebase functions:shellで、直接関数を動かすと問題ない（ローカルでは問題ない）

原因と対策

うまくいかない原因は二つ。

原因1 - デプロイ時にESLintが怒ってる

エラーはこんな感じ

asyncの入ってるところでエラーになる

61:9  error  Parsing error: Unexpected token function
✖ 1 problem (1 error, 0 warnings)

対策1

.eslintrc.jsonを以下のように"ecmaVersion": 2017とする。Firebaseがつくるデフォルト設定 "ecmaVersion": 6 だと、ESLintはasync/awaitを解釈しない模様

  "parserOptions": {
    // Required for certain syntax usages
    //"ecmaVersion": 6
    "ecmaVersion": 2017
  },

関連するstackoverflowのQ&A

原因2 - node のバージョンが async/await に対応していない

エラーはこんな感じ

asyncの入ってるところでエラーになる

⚠  functions[getSentiment2(us-central1)]: Deployment error.
Function failed on loading user code. Error message: Code in file index.js can't be loaded.
Is there a syntax error in your code?
Detailed stack trace: /user_code/index.js:61
  async function quickstart() {
        ^^^^^^^^

対策2

packeges.json に "engines": { "node": "8" }を追加して、node のバージョン8を指定する。FireBaseの node ってデフォルトが6らしいのですが、8以降じゃないと async/await がつかえないみたいです。この状態でデプロイすると

i  functions: updating Node.js 8 function func1(your-region)...
i  functions: updating Node.js 8 function func2(your-region)...

と表示されて、デプロイできました。

関連するstackoverflowのQ&A

参考にさせていただきました

おわりに

誰かの時間の節約になれば。

Cheers,

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T15:33:21+09:00

ESLint v6.0.0 の変更点まとめ

前 v5.16.0 | 次 (未定)

ESLint 6.0.0-alpha.0 がリリースされました。
以後、6.0.0 安定版リリースまでの間、この記事に変更内容をまとめていきます。

プレリリースであるため、インストールには@nextタグが必要です。

npm install --save-dev eslint@next

機能追加は少なめですが、既存の機能を改善するための非互換な変更があります。特に、グローバル インストール (npm install -g) された ESLint コマンドを利用している場合、今まで通りには利用できない可能性が高いです。逆に、ローカル インストールを利用している場合はほとんど変化を感じないかもしれません。

  • :information_source: 6.0.0-alpha.0では、まだ一部の非互換な変更がマージされていません。状況はプロジェクトボードで確認できます。

互換性のない変更 for ユーザー:

互換性のない変更 for プラグイン開発者:

互換性のない変更 for 連携ツール開発者:

マイグレーション ガイド:

リリースノート:

質問やバグ報告等ありましたら、お気軽にこちらまでお寄せください。

? 日本語 Issue 管理リポジトリ
? 日本語サポート チャット
? 本家リポジトリ
? 本家サポート チャット

? 互換性のない変更

§ Node.js 6.x のサポートを終了しました。

? #11557, #11456, #11022

Node.js 6 は 4 月 30 日に寿命を迎えます。これに伴い、ESLint は Node.js 6 のサポートを終了しました。

新たなサポート範囲は以下の通りです。

  • Node.js 8 (8.10.0 以上)
  • Node.js 10 (10.13.0 以上)
  • Node.js 11 以降 (11.10.1 以上)

§ プラグインの読み込み方が大幅に変更されました。

? #11388, #10125, RFC #7

従来は ESLint がインストールされた場所を基準に (即ち、ESLint がインストールされた node_modules ディレクトリから) プラグインを読み込んでいました。これは babel 等の一緒に使われることが多いツール群とは異なる振る舞いであり、混乱の原因になっていました。また、lerna や Yarn Plug n' Play 等の特定の環境下で ESLint が正常に動作しない原因にもなっていました。

そのため、ESLint 6 からはこの動作が変更され、常にプロジェクト ローカル (より厳密には $CWD/node_modules とその祖先ディレクトリ) からプラグインを読み込むようになりました。

これまでグローバル インストールされた ESLint とプラグインを利用していた方は、利用方法を変更する必要があります。ESLint とプラグイン類をプロジェクト毎にインストールし、コマンドは eslint-cli 等を利用する事をお勧めします。

§ eslint:recommendedに含まれるルールが更新されました。

? #11518, #11357, #10873, #10768

以下のルールが新たに有効になりました。

  • no-async-promise-executor Promiseクラスのコンストラクタに渡す関数が非同期関数だった場合に警告します。その関数内で例外がスローされた場合にプログラムがクラッシュする (正確には unhandledRejection が発生する) ためです。
  • no-misleading-character-class 正規表現の文字クラスに複数のコードポイントから構成される文字がある場合に警告します。それは正しく解釈されないためです。
  • no-prototype-builtins hasOwnPropertyのようなObjectクラスの一部メソッドを警告します。オブジェクトをMap的に使う場合はObjectクラスのメソッドを持っていないObject.create(null)が好まれるためです。現代ではMapクラスを利用するのが良いでしょう。
  • no-shadow-restricted-names undefined等の重要な変数のシャドーイングを警告します。
  • no-useless-catch 無駄なcatch句を警告します。
  • no-with with構文を警告します。
  • require-atomic-updates 非同期関数にて、共有変数がアトミックに変更されない場合に警告します。

以下のルールが有効にならなくなりました。

  • no-console このルールは多くの場合に有用ですが (例えば、誤ってデバッグ用の記述をプロダクション コードに残さないようにする)、CLI プログラムなどconsole.logが有効なケースもあるため、推奨設定から外されました。

また、従来のeslint:recommendedには推奨以外のルールを無効にする設定が含まれていました。ESLint 6 からは、eslint:recommendedはいかなるルールも無効にしません。推奨されるルールを有効にするだけです。

§ no-redeclare ルールのチェックがより厳しくなりました。

? #11509, #11405, #11370

  1. no-redeclare ルールのbuiltinGlobalsオプションがデフォルトで有効になりました。グローバル スコープでの変数定義が、設定ファイルで定義したグローバル変数と同じ名前の時に再定義エラーとなります。
  2. /*globals xxx*/のようなコメントによるグローバル変数定義と、他のグローバル変数定義との再宣言をチェックするようになりました。
/*globals Object */ "ERROR: Object は既に定義されています。"

§ comma-dangle ルールのチェックがより厳しくなりました。

? #11519, #11502

comma-dangle ルールのfunctionsオプションがデフォルトで有効になりました。

§ オプションに正規表現を指定できるルールが正規表現構文の誤りに厳しくなりました。

? #11516, #11423

オプションに正規表現パターンを指定できるすべてのルールについて、その正規表現をuフラグがついているものとして解釈するようになりました。これによりサロゲート ペアを正しく扱えるようになるほか、ブラウザ互換性のための緩い構文解釈 (a.k.a. Annex B) が無効化され、より厳密な構文解釈が行われるようになります。

以下のルールが影響を受けます。

§ 設定のrulesプロパティが存在しないルールを無効にする場合にエラーを投げるようになりました。

? #9505

以下のような、存在しないルールに対する無効化設定は、従来は無視されていました。ESLint 6 からはエラーになります。

.eslintrc.json
{
    "rules": {
        "non-existence-rule": "off"
    }
}

§ 設定のparserOptionsプロパティが不正な値にエラーを投げるようになりました。

? #11610, #9687, espree #412, espree #384

  1. sourceType: "module" を指定したにもかかわらず、ecmaVersion が 5 以下であった (未指定を含む) 場合にエラーになります。ES Modules は ecmaVersion: 2015 とそれ以降のみ利用可能です。
  2. ecmaVersion が不正な値の時にエラーになります。
  3. sourceType が不正な値の時にエラーになります。

なお、これらのエラーはデフォルトのパーサーを利用している場合のみ発生します。

§ 設定のglobalsプロパティが不正な値にエラーを投げるようになりました。

? #11517, #11338 (comment)

設定ファイルのglobals項目について、昔はtrue/falseによって書き込み可能かどうかを指定していました。そして、互換性のために、不正な値も許可されていました (暗黙の型変換でtrueになると書き込み可能として)。

ESLint 6 では、不正な値はエラーになります。厳密には以下の値だけが許可されます。

  • 公式の設定値
    • "writable" (読み書き可能)
    • "readonly" (読み取り専用)
    • "off" (未定義にする)
  • 互換性のために許可される値
    • "writeable" (読み書き可能)
    • "readable" (読み取り専用)
    • "true" (読み書き可能)
    • "false" (読み取り専用)
    • true (読み書き可能)
    • false (読み取り専用)

§ 設定のoverrides[].filesプロパティが dotfiles にマッチするようになりました。

? #11225, #11201

.eslintrc.yml
overrides:
  - files: ["*.ts"]
    parser: "typescript-eslint-parser"

従来は、上記設定は.で始まる TypeScript ファイル (例: .foo.ts) にはマッチしませんでした。ESLint 6 からはマッチするようになります。

§ 設定のexperimentalObjectRestSpreadプロパティが削除されました。

? #11420, #9990

ESLint 5 から非推奨になっていたexperimentalObjectRestSpread設定が削除されました。ecmaVersion: 2018をご利用ください。

§ 共有設定のoverridesプロパティ内の項目が、それをextendsする設定ファイルの項目を上書きしなくなりました。

? #11546, #11510

従来は、共有設定のoverrides内にある設定を普通に書くと、その設定は黙って無視されていました。

extendee.yml
overrides:
  - files: "*.js"
    rules:
      no-console: error
extender.yml
extends: "./extendee.yml"
rules:
  no-console: off # extendee の設定で上書きされてしまう

ESLint 6 からは、あなたの設定ファイルに書かれた設定は常に共有設定より優先されます。

§ スコープ解析 API の中にあるeslintExplicitGlobalCommentプロパティが削除されました。

? #11509, #11370, RFC #17

ESLint のスコープ解析機能の変数オブジェクトが持っていたeslintExplicitGlobalCommentプロパティが削除されました。このプロパティはこれまで正式にドキュメントに書かれたことはありません。

もし、あなたのルールがこのプロパティを利用していた場合、新たに追加されたeslintExplicitGlobalCommentsプロパティを利用するよう修正してください。

TODO: ドキュメントへのリンク

§ ルールのオプション スキーマが不正なデフォルト値を持つ場合にエラーを投げるようになりました。

? #11599, #11473

ESLint v5.14.0 から各ルールの schema 定義でデフォルト値を指定できるようになりましたが、このデフォルト値の書き方が不正な場合にRuleTesterがエラーを出力するようになりました。

§ Linterクラスはカスタムパーサーを自動的に読み込まなくなりました。

? #11388, RFC #7

従来はLinter#verify(code, config)メソッドに渡した設定が未知のパーサーを持っていた場合、require(config.parser)を試みてパーサーを読み込んでいました。この動作が削除されました。

あなたの連携ツールがこの動作に依存していた場合、事前にLinter#defineParser(id,parser)メソッドを用いてパーサーを定義するように修正してください。

§ CLIEngineクラスは過去に利用したプラグインを保持しなくなりました。

? #11546

従来はCLIEngineクラスが過去の検証で利用したプラグインを保持していて、同じインスタンスを使い回す場合に、設定ファイルにpluginsキーがなかったとしても、過去に利用したプラグインを利用できてしまっていました。

ESLint v6.0.0 からは、過去に利用したプラグインを保持しなくなりました。そのため、CLIEngineインスタンスを再利用している場合に、plugins設定が不足している不完全な設定が新たにエラーになる可能性があります。

✨ 本体への機能追加

特になし。

? 新しいルール

特になし。

? オプションが追加されたルール

§ function-paren-newline "multiline-arguments"

? #11406

"multiline"オプションと同様に動作するが、引数が1個の場合は括弧の内側の改行を許可するオプション? が追加されました。

? その他の変更

特になし。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-04-13T14:50:41+09:00

ローカルネットワークからjson-serverにアクセスする

1 はじめに

json-serverを以下のようにデフォルトで立ち上げるとローカルホストのみ通信できる状態になる。
json-server db.json

ローカルネットーワーク内にjson-serverを立ち上げ、立ち上げているPCとは別の端末からアクセスしたい場合は、以下２点を設定する必要がある。
・ホスト名の指定
・ファイアーウォールの通過設定

2 ホスト名の指定

ホスト名を指定する場合は、以下のオプションをつける。このオプションを付けないとローカルホストで立ち上がってしまい、外部からアクセスできない。
--host <IPアドレス or ドメイン名>
ドメイン名の場合は、合わせてDNSサーバーにドメイン名を登録しておく。これにより、ローカルネットワーク内の端末からサーバーを見つけられるようになる。

3 ファイアーウォールの通過設定

まず、デフォルトではポート番号が3000となっているが、任意のポートに指定したい場合は以下のオプションをつける。
--p <port番号>

そのポートで通信できるようにファイアーウォールの受信規則に上記ポートを受信できるようにする。ファイヤーウォールに上記ポートを通過設定しておかないと、サーバーが立ち上がっていても、外部からの通信をファイヤーウォールが遮断してしまうため外部からアクセスできない。

4 Node.jsで動かす場合

Node.jsで動かす場合は、以下のようにポートとIPアドレス or ドメイン名を指定する。

server.listen(<port>, '<IPアドレス or ドメイン名>');

server.js
const jsonServer = require('json-server');
const server = jsonServer.create();
const router = jsonServer.router('db.json');
const middlewares = jsonServer.defaults();

server.use(middlewares);
server.use(router);

server.listen(80, '192.168.11.20', () => {
  console.log('run');
});

4 結果

以下のような環境で実行した結果を示す。結果の通り、ローカルネットーワーク内のjson-serverに対し、json-serverを立ち上げているPCとは別の端末からアクセスできた。
MacPC(clinet)---router--WindowsPC(json-server)

・WindowsPCがjson-serverを立ち上げた結果
json-server1.png

・MacPC(clinet)がサーバへリクエストした結果

スクリーンショット 2019-04-13 14.21.00.png

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧