유성 및 표준 보푸라기

standard 과 Meteor 을 통합하는 것은 뛰어난 기본 경험입니다. 개발자 종속성으로 설치한 다음 NPM 스크립트를 추가하여 린터를 실행하기만 하면 됩니다.

$ meteor npm install --save-dev standard

package.json의 npm 스크립트는 다음과 같습니다.

{
  "scripts": {
    "lint": "standard",
    "lint:fix": "standard --fix"
  }
}

매우 쉽고 강력합니다. 그러나 Meteor에서 실제로 다음을 수행할 수 있기 때문에 어느 시점에서 구문 분석 오류가 발생할 수 있습니다.

import '../some/module' // valid

export const somefunction = function () {
  import { dependency } from '../some/dependency' // this will cause trouble
  // ...
}

Meteor 앱은 잘 실행되지만 파일을 구문 분석할 때 린터가 충돌합니다. 가져오기가 최상위 수준에서만 허용된다는 오류가 발생하고 추가 문제가 있는지 파일 검색을 건너뜁니다.

이 문제를 해결하기 위해 할 수 있는 일

물론 최상위 수준이 아닌 모든 가져오기를 동적 ​​가져오기(Meteor 1.5부터 지원됨)로 변경할 수 있지만 모든 해당 함수를 async 로 변경하거나 Promise 의 반환 값을 처리해야 합니다.

또한 이러한 모든 가져오기를 노드require 스타일로 다시 작성할 수 있으며 린터는 다시 만족합니다.

그러나 코드를 그대로 유지하고 standard 를 사용하여 약간의 변경을 수행할 수 있습니다.

구출에 standardx

standardx를 사용하면 standard에 대한 기본 eslint 규칙을 재정의하고 allowImportExportEverywhere를 true로 선언할 수 있습니다. 또한 eslint-plugin-security와 같은 eslint 플러그인을 통합할 수 있습니다(다음 예제에서 사용할 것입니다).

다음 가이드는 몇 단계로 완료되는 방법을 보여줍니다.

1. standard를 standardx로 교체

이것은 두 줄로 수행됩니다. babel을 사용하여 코드를 변환하기 위해 추가 플러그인도 설치하므로 항상 최신 ES-Next 기능을 사용할 수 있습니다.

$ meteor npm uninstall --save-dev standard
$ meteor npm install --save-dev standardx @babel/eslint-parser @babel/core eslint-plugin-security

2. package.json 업데이트

standard를 더 이상 사용할 수 없으므로 standardx를 호출하려면 스크립트도 업데이트해야 합니다.

{
  "scripts": {
    "lint": "standardx",
    "lint:fix": "standardx --fix"
  }
}

또한 Babel 관련 문제가 발생하면 빈"babel" 개체를 추가하려고 할 수 있습니다.

{
  "scripts": {
    "lint": "standardx",
    "lint:fix": "standardx --fix"
  },
  "babel": {}
}

이것은 @babel/core 에서 요구하는 누락된 Babel 구성과 관련된 오류를 해결합니다.

이스탄불과 같은 도구를 사용하는 경우 babel 에 이미 package.json 항목이 있을 수 있습니다.

3. 사용자 정의 eslintConfig 정의

마지막 단계는 어디에서나 가져오기를 지원하도록 eslint를 구성하는 것입니다. 왜 이제 eslint를 사용하는지 스스로에게 묻는다면 standard repos를 살펴보고 eslint를 기반으로 합니다.
package.json에 구성이 있습니다.

{
  "eslintConfig": {
    "parser": "@babel/eslint-parser",
    "parserOptions": {
      "sourceType": "module",
      "allowImportExportEverywhere": true
    },
    "plugins": [
      "security"
    ],
    "extends": [
      "plugin:security/recommended"
    ]
  }
}

이를 통해 이제 Meteor 환경을 완벽하게 지원하고 몇 가지 규칙으로 표준을 확장하는 플러그인을 통합할 수 있습니다.

그 위에 사용자 정의 규칙을 정의할 수도 있습니다.

{
  "eslintConfig": {
    "parser": "@babel/eslint-parser",
    "parserOptions": {
      "sourceType": "module",
      "allowImportExportEverywhere": true
    },
    "plugins": [
      "security"
    ],
    "extends": [
      "plugin:security/recommended"
    ],
    "rules": {
      "brace-style": [
        "error",
        "stroustrup",
        {
          "allowSingleLine": true
        }
      ]
    }
  }
}

위의 코드는 예제일 뿐이며 다음 코드를 작성할 수 있습니다.

if (condition) {
  // action a
} else {
  // action b
}

다음 형식으로

if (condition) {
  // action a
} 

else {
  // action b
}

요약

이러한 몇 가지 단계를 통해 실제로 표준 린터의 이점을 얻을 수 있으며 가져오기 구조를 변경할 필요가 없습니다. 추가 플러그인은 사용 사례에 따라 코드 품질도 향상시킵니다. 파서는 Meteor가 이미 그랬던 것처럼 새로운 edge ES-next 기능을 통합하는 경우에 대비하여 향후 규칙을 지속적으로 업데이트할 필요가 없도록 해야 합니다.

문제가 발생하면 의견을 남겨주세요.