eslint plugin import

ESLINT-PLUGIN-IMPORT

ปลั๊กอินนี้ตั้งใจที่จะรองรับการเป็นผ้าสำลีของ ES2015+ (ES6+) ไวยากรณ์นำเข้า/ส่งออกและป้องกันปัญหาการสะกดคำผิดของเส้นทางไฟล์และชื่อนำเข้า ความดีทั้งหมดที่ ES2015+ Module Vyntax ตั้งใจจะให้ทำเครื่องหมายไว้ในโปรแกรมแก้ไขของคุณ

หากคุณใช้สิ่งนี้กับประเสริฐ : ดูส่วนล่างสำหรับข้อมูลสำคัญ

กฎ

เปิดใช้งานการกำหนดค่าใน
การกำหนดค่าตั้งค่าเป็นคำเตือน
การกำหนดค่าปิดใช้งานใน
❗ตั้งค่าในการกำหนดค่า errors
☑ตั้งค่าในการกำหนดค่า recommended
⌨ตั้งค่าในการกำหนดค่า typescript
- ตั้งค่าในการกำหนด warnings
- แก้ไขได้โดยอัตโนมัติโดยตัวเลือก --fix CLI
แก้ไขได้ด้วยตนเองโดยคำแนะนำของบรรณาธิการ
เลิกใช้แล้ว

คำเตือนที่เป็นประโยชน์

ชื่อ	คำอธิบาย				-
ส่งออก	ห้ามการส่งออกที่ไม่ถูกต้องเช่นการส่งออกชื่อเดียวกันอีกครั้ง
ไม่ได้รับการปฏิเสธ	ห้ามใช้ชื่อที่นำเข้าที่ทำเครื่องหมายด้วยแท็กเอกสาร @deprecated
บล็อกไม่มีชื่อ	ห้ามบล็อกนำเข้าที่มีชื่อว่างเปล่า				-
ไม่มีการพึ่งพาอาศัยกัน	ห้ามการใช้แพ็คเกจที่ไม่เกี่ยวข้อง
ไม่ต้องส่งออก	ห้ามการใช้การส่งออกที่ไม่แน่นอนด้วย var หรือ let
ไม่มีชื่อ	ห้ามใช้ชื่อที่ส่งออกเป็นตัวระบุการส่งออกเริ่มต้น		?
ไม่มีชื่อ	ห้ามใช้ชื่อที่ส่งออกเป็นคุณสมบัติของการส่งออกเริ่มต้น		?
โมดูลที่ไม่ได้ใช้	ห้ามโมดูลที่ไม่มีการส่งออกหรือส่งออกโดยไม่ต้องจับคู่การนำเข้าในโมดูลอื่น

ระบบโมดูล

ชื่อ	คำอธิบาย				-
ไม่มี AMD	ห้ามใช้ AMD require และ define โทร
ไม่มีข้อ จำกัด	Forbid CommonJs require การโทรและ module.exports ส่งออกหรือ exports.*
ไม่มีการส่งออกโมดูล	ห้ามนำเข้าแถลงการณ์ด้วยโมดูล CommonJS Exports				-
No-nodejs-modules	Forbid node.js โมดูลในตัว
ไม่คลุมเครือ	ห้ามเป้าหมายการแยกวิเคราะห์ที่อาจคลุมเครือ ( script กับ module )

การวิเคราะห์แบบคงที่

ชื่อ	คำอธิบาย				-
ค่าเริ่มต้น	ตรวจสอบให้แน่ใจว่ามีการส่งออกเริ่มต้นได้รับการนำเข้าเริ่มต้น
บังคับใช้การใช้งาน	บังคับใช้ทั้งการใช้หรือการละเว้น node: โปรโตคอลเมื่อนำเข้าโมดูล node.js ในตัว				-
ชื่อ	ตรวจสอบให้แน่ใจว่าการนำเข้าที่มีชื่อสอดคล้องกับการส่งออกที่มีชื่อในไฟล์ระยะไกล
เนมสเปซ	ตรวจสอบให้แน่ใจว่าเนมสเปซที่นำเข้ามีคุณสมบัติที่ถูกต้องตามที่ได้รับการตรวจสอบ
ไม่มีทางเดิน	ห้ามการนำเข้าโมดูลโดยใช้เส้นทางสัมบูรณ์				-
ไม่มีวัฏจักร	ห้ามโมดูลจากการนำเข้าโมดูลที่มีเส้นทางการพึ่งพากลับไปเป็นตัวของมันเอง
ไม่ต้องขอความช่วยเหลือ	ห้าม require() การโทรด้วยการแสดงออก
ไม่มีโมดูลภายใน	ห้ามนำเข้า submodules ของโมดูลอื่น ๆ
ไม่เกี่ยวข้องกับแพคเกจ	ห้ามนำเข้าแพ็คเกจผ่านเส้นทางสัมพัทธ์				-
ไม่เกี่ยวข้องกับพ่อแม่	ห้ามนำเข้าโมดูลจากไดเรกทอรีหลัก
ไม่มีเส้นทางที่ จำกัด	บังคับใช้ไฟล์ที่สามารถนำเข้าในโฟลเดอร์ที่กำหนด
ไม่มีการนำเข้าด้วยตนเอง	ห้ามโมดูลไม่ให้นำเข้าเอง
ไม่ได้รับการแก้ไข	ตรวจสอบให้แน่ใจว่านำเข้าชี้ไปที่ไฟล์/โมดูลที่สามารถแก้ไขได้
ไม่มีการใช้เส้นทางที่ไม่มีประโยชน์	ห้ามไม่ให้มีกลุ่มเส้นทางที่ไม่จำเป็นในการนำเข้าและต้องการคำสั่ง				-
No-Webpack-Loader-Syntax	Forbid Webpack Loader ไวยากรณ์ในการนำเข้า

คู่มือสไตล์

ชื่อ	คำอธิบาย				-
สไตล์ตัวพิมพ์ที่สอดคล้องกัน	บังคับใช้หรือห้ามการใช้เครื่องหมายแบบอินไลน์เท่านั้นสำหรับการนำเข้าที่มีชื่อ				-
Dynamic-Import-chunkname	บังคับใช้ความคิดเห็นชั้นนำกับ webpackchunkname สำหรับการนำเข้าแบบไดนามิก
ส่งออก	ตรวจสอบให้แน่ใจว่าการส่งออกทั้งหมดปรากฏขึ้นหลังจากข้อความอื่น ๆ
ส่วนขยาย	ตรวจสอบให้แน่ใจว่าการใช้งานนามสกุลไฟล์ภายในเส้นทางนำเข้าอย่างสอดคล้องกัน
อันดับแรก	ตรวจสอบให้แน่ใจว่าการนำเข้าทั้งหมดปรากฏขึ้นก่อนข้อความอื่น ๆ				-
การส่งออกกลุ่ม	ชอบชื่อการส่งออกที่จะจัดกลุ่มเข้าด้วยกันในการประกาศการส่งออกครั้งเดียว
นำเข้าก่อน	แทนที่ด้วย import/first				-
การพึ่งพาอาศัยกันสูงสุด	บังคับใช้จำนวนการพึ่งพาสูงสุดที่โมดูลสามารถมีได้
นิวไลน์-หลังจากนำเข้า	บังคับใช้บรรทัดใหม่หลังจากคำสั่งนำเข้า				-
ไม่มีการออกเสียง	ห้ามค่าที่ไม่ระบุชื่อเป็นการส่งออกเริ่มต้น
ไม่มีการส่งออก	ห้ามส่งออกเริ่มต้น
ไม่มีการทำซ้ำ	ห้ามนำเข้าซ้ำของโมดูลเดียวกันในหลายสถานที่		?		-
ไม่มีชื่อ	ห้ามใช้ชื่อการส่งออกเริ่มต้น
ไม่มีชื่อ	ห้ามใช้ชื่อการส่งออก
ไม่มีเนมสเปซ	ห้ามนำเข้า Namespace (aka "Wildcard" * ) นำเข้า				-
ไม่มีการออกแบบ	ห้ามนำเข้าที่ไม่ได้ออกแบบ
คำสั่ง	บังคับใช้อนุสัญญาในลำดับการนำเข้าโมดูล				-
ชอบการส่งออก-ส่งออก	ต้องการการส่งออกเริ่มต้นหากโมดูลส่งออกชื่อเดียวหรือหลายชื่อ

eslint-plugin-import สำหรับ Enterprise

มีให้เป็นส่วนหนึ่งของการสมัครสมาชิก TideLift

ผู้ดูแลระบบของ eslint-plugin-import และแพ็คเกจอื่น ๆ อีกหลายพันรายการกำลังทำงานร่วมกับ TideLift เพื่อให้การสนับสนุนเชิงพาณิชย์และการบำรุงรักษาสำหรับการพึ่งพาโอเพ่นซอร์สที่คุณใช้เพื่อสร้างแอปพลิเคชันของคุณ ประหยัดเวลาลดความเสี่ยงและปรับปรุงสุขภาพของรหัสในขณะที่จ่ายค่ารักษาผู้ดูแลการพึ่งพาที่แน่นอนที่คุณใช้ เรียนรู้เพิ่มเติม

การติดตั้ง

 # inside your project's working tree
npm install eslint-plugin-import --save-dev

config - legacy ( .eslintrc )

กฎทั้งหมดถูกปิดโดยค่าเริ่มต้น อย่างไรก็ตามคุณอาจขยายหนึ่งในการกำหนดค่าที่ตั้งไว้ล่วงหน้าหรือกำหนดค่าด้วยตนเองใน .eslintrc.(yml|json|js)

• ขยายการกำหนดค่าที่ตั้งไว้ล่วงหน้า:

 {
  "extends" : [
     "eslint:recommended" ,
     "plugin:import/recommended" ,
  ] ,
}

• การกำหนดค่าด้วยตนเอง:

 {
  "rules" : {
    "import/no-unresolved" : [ "error" , { "commonjs" : true , "amd" : true } ] ,
    "import/named" : "error" ,
    "import/namespace" : "error" ,
    "import/default" : "error" ,
    "import/export" : "error" ,
    // etc...
  } ,
} ,

config - flat ( eslint.config.js )

กฎทั้งหมดถูกปิดโดยค่าเริ่มต้น อย่างไรก็ตามคุณสามารถกำหนดค่าพวกเขาด้วยตนเองใน eslint.config.(js|cjs|mjs) หรือขยายหนึ่งในการกำหนดค่าที่ตั้งไว้ล่วงหน้า:

 import importPlugin from 'eslint-plugin-import' ;
import js from '@eslint/js' ;

export default [
  js . configs . recommended ,
  importPlugin . flatConfigs . recommended ,
  {
    files : [ '**/*.{js,mjs,cjs}' ] ,
    languageOptions : {
      ecmaVersion : 'latest' ,
      sourceType : 'module' ,
    } ,
    rules : {
      'no-unused-vars' : 'off' ,
      'import/no-dynamic-require' : 'warn' ,
      'import/no-nodejs-modules' : 'warn' ,
    } ,
  } ,
] ; 

ตัวพิมพ์ใหญ่

คุณสามารถใช้ตัวอย่างต่อไปนี้หรือประกอบการกำหนดค่าของคุณเองโดยใช้การตั้งค่าเม็ดที่อธิบายไว้ด้านล่าง

ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้ง @typescript-eslint/parser และ eslint-import-resolver-typescript ซึ่งใช้ในการกำหนดค่าต่อไปนี้

 {
  "extends" : [
    "eslint:recommended" ,
    "plugin:import/recommended" ,
// the following lines do the trick
    "plugin:import/typescript" ,
  ] ,
  "settings" : {
    "import/resolver" : {
      // You will also need to install and configure the TypeScript resolver
      // See also https://github.com/import-js/eslint-import-resolver-typescript#configuration
      "typescript" : true ,
      "node" : true ,
    } ,
  } ,
}

กำหนดค่า - แบนด้วย config() ใน typescript-eslint

หากคุณใช้วิธี config จาก typescript-eslint ตรวจสอบให้แน่ใจว่า flatConfig รวมอยู่ในอาร์เรย์ extends

 import tseslint from 'typescript-eslint' ;
import importPlugin from 'eslint-plugin-import' ;
import js from '@eslint/js' ;

export default tseslint . config (
  js . configs . recommended ,
  // other configs...
  {
    files : [ '**/*.{ts,tsx}' ] ,
    extends : [ importPlugin . flatConfigs . recommended ] ,
    // other configs...
  }
) ; 

นักมวย

ด้วยการถือกำเนิดของ Bundlers โมดูลและสถานะปัจจุบันของโมดูลและข้อมูลจำเพาะของโมดูลไวยากรณ์มันไม่ชัดเจนเสมอไปที่ import x from 'module' ควรค้นหาไฟล์ที่อยู่เบื้องหลัง module

ผ่าน V0.10ish ปลั๊กอินนี้ใช้ปลั๊กอิน resolve ของ Sutchack โดยตรงซึ่งใช้พฤติกรรมการนำเข้าของ Node สิ่งนี้ใช้งานได้ดีในกรณีส่วนใหญ่

อย่างไรก็ตาม WebPack อนุญาตให้มีหลายสิ่งในสตริงแหล่งที่มาของโมดูลนำเข้าที่โหนดไม่ได้เช่น externals โหลด ( import 'file!./whatever'

เพื่อประโยชน์ในการสนับสนุนทั้งสองสิ่งนี้ V0.11 แนะนำตัวแก้ปัญหา

ปัจจุบันมีการใช้ความละเอียดของโหนดและเว็บแพ็คแล้ว แต่ผู้แก้ไขเป็นเพียงแพ็คเกจ NPM ดังนั้นจึงรองรับแพ็คเกจบุคคลที่สาม (และสนับสนุน!)

คุณสามารถอ้างอิงผู้แก้ไขได้หลายวิธี (ตามลำดับความสำคัญ):

• เป็นชื่อ eslint-import-resolver ทั่วไปเช่น eslint-import-resolver-foo :

 // .eslintrc
{
 "settings" : {
   // uses 'eslint-import-resolver-foo':
   "import/resolver" : "foo" ,
 } ,
} 

 # .eslintrc.yml
settings :
  # uses 'eslint-import-resolver-foo':
  import/resolver : foo 

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      foo : { someConfig : value }
    }
  }
}

• ด้วยชื่อโมดูล NPM เต็มรูปแบบเช่น my-awesome-npm-module :

 // .eslintrc
{
  "settings" : {
    "import/resolver" : "my-awesome-npm-module" ,
  } ,
} 

 # .eslintrc.yml
settings :
  import/resolver : ' my-awesome-npm-module ' 

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      'my-awesome-npm-module' : { someConfig : value }
    }
  }
}

• ด้วยพา ธ ระบบไฟล์ไปยังตัวแก้ไขซึ่งกำหนดไว้ในตัวอย่างนี้เป็นชื่อ computed property :

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      [ path . resolve ( '../../../my-resolver' ) ] : { someConfig : value }
    }
  }
}

เส้นทางสัมพัทธ์จะได้รับการแก้ไขเมื่อเทียบกับ package.json หรือไดเรกทอรีการทำงานปัจจุบันของกระบวนการหากไม่พบ package.json

หากคุณน่าสนใจในการเขียนตัวแก้ไขโปรดดูข้อมูลจำเพาะสำหรับรายละเอียดเพิ่มเติม

การตั้งค่า

คุณสามารถตั้งค่าการตั้งค่าต่อไปนี้ใน .eslintrc :

import/extensions

รายการส่วนขยายไฟล์ที่จะแยกวิเคราะห์เป็นโมดูลและตรวจสอบสำหรับ export

ค่าเริ่มต้นนี้เป็น ['.js'] เว้นแต่คุณจะใช้การกำหนด react ที่ใช้ร่วมกันในกรณีนี้มันถูกระบุเป็น ['.js', '.jsx'] แม้จะมีค่าเริ่มต้นหากคุณใช้ typeScript (ไม่มี plugin:import/typescript ที่อธิบายไว้ข้างต้น) คุณต้องระบุส่วนขยายใหม่ ( .ts และ. .tsx หากใช้ React)

 "settings" : {
  "import/extensions" : [
    ".js" ,
    ".jsx"
  ]
}

หากคุณต้องการคำจำกัดความส่วนขยายที่ละเอียดยิ่งขึ้นคุณสามารถใช้:

 "settings" : {
  "import/resolver" : {
    "node" : {
      "extensions" : [
        ".js" ,
        ".jsx"
      ]
    }
  }
}

โปรดทราบว่าสิ่งนี้แตกต่างจาก (และน่าจะเป็นส่วนย่อยของ) การตั้งค่าส่วนขยาย import/resolver ใด ๆ ซึ่งอาจรวมถึง .json , .coffee ฯลฯ ซึ่งจะยังคงเป็นปัจจัยในกฎ no-unresolved

นอกจากนี้รูปแบบ import/ignore ต่อไปนี้จะลบล้างรายการนี้

import/ignore

รายการของ regex strings ที่หากจับคู่ด้วยเส้นทางจะไม่รายงานโมดูลการจับคู่หากไม่พบการ export ในทางปฏิบัตินี่หมายถึงกฎอื่นนอกเหนือจาก no-unresolved จะไม่รายงานเกี่ยวกับ import ใด ๆ กับพา ธ (ระบบไฟล์สัมบูรณ์) ที่ตรงกับรูปแบบนี้

no-unresolved ไม่มีการตั้ง ignore ของตัวเอง

 {
  "settings" : {
    "import/ignore" : [
      ".coffee$" , // fraught with parse errors
      ".(scss|less|css)$" , // can't parse unprocessed CSS modules, either
    ] ,
  } ,
}

import/core-modules

อาร์เรย์ของโมดูลเพิ่มเติมที่จะพิจารณาเป็นโมดูล "แกน"-โมดูลที่ควรได้รับการพิจารณาแก้ไข แต่ไม่มีเส้นทางในระบบไฟล์ ตัวแก้ไขของคุณอาจกำหนดสิ่งเหล่านี้แล้ว (ตัวอย่างเช่นตัวแก้ไขโหนดรู้เกี่ยวกับ fs และ path ) ดังนั้นคุณไม่จำเป็นต้องกำหนดใหม่เหล่านั้น

ตัวอย่างเช่นอิเล็กตรอนเปิดเผยโมดูล electron :

 import 'electron'  // without extra config, will be flagged as unresolved!

นั่นจะไม่ได้รับการแก้ไข เพื่อหลีกเลี่ยงสิ่งนี้คุณอาจจัดเตรียม electron เป็นโมดูลหลัก:

 // .eslintrc
{
  "settings" : {
    "import/core-modules" : [ "electron" ] ,
  } ,
}

ในกรณีเฉพาะของอิเล็กตรอนมีการกำหนดค่าที่ใช้ร่วมกันชื่อ electron ที่ระบุสิ่งนี้ให้คุณ

ยินดีต้อนรับการกำหนดค่าที่ใช้ร่วมกันมากขึ้นสำหรับแพลตฟอร์มอื่น ๆ !

import/external-module-folders

อาร์เรย์ของโฟลเดอร์ โมดูลที่ได้รับการแก้ไขเท่านั้นจากโฟลเดอร์เหล่านั้นจะถูกพิจารณาว่าเป็น "ภายนอก" โดยค่าเริ่มต้น - ["node_modules"] สมเหตุสมผลถ้าคุณกำหนดค่าเส้นทางหรือ webpack ของคุณเพื่อจัดการเส้นทางภายในของคุณแตกต่างกันและต้องการพิจารณาโมดูลจากบางโฟลเดอร์เช่น bower_components หรือ jspm_modules เป็น "ภายนอก"

ตัวเลือกนี้ยังมีประโยชน์ในการตั้งค่า monorepo: รายการไดเรกทอรีทั้งหมดที่มีแพ็คเกจของ Monorepo และพวกเขาจะได้รับการปฏิบัติเหมือนภายนอกไม่ว่าจะใช้ตัวแก้ไขใด

หากคุณใช้ yarn PNP เป็นตัวจัดการแพ็คเกจของคุณให้เพิ่มโฟลเดอร์ .yarn และการอ้างอิงที่ติดตั้งทั้งหมดของคุณจะถูกพิจารณาว่าเป็น external แทนที่จะเป็น internal

แต่ละรายการในอาร์เรย์นี้เป็นชื่อของโฟลเดอร์, Subpath หรือเส้นทางคำนำหน้าแบบสัมบูรณ์:

• jspm_modules จะตรงกับไฟล์หรือโฟลเดอร์ใด ๆ ที่ชื่อ jspm_modules หรือมีผู้ปกครองโดยตรงหรือไม่กำกับชื่อ jspm_modules เช่น /home/me/project/jspm_modules หรือ /home/me/project/jspm_modules/some-pkg/index.js

• packages/core จะตรงกับเส้นทางใด ๆ ที่มีทั้งสองส่วนนี้เช่น /home/me/project/packages/core/src/utils.js

• /home/me/project/packages จะตรงกับไฟล์และไดเรกทอรีภายในไดเรกทอรีนี้เท่านั้นและไดเรกทอรีเอง

โปรดทราบว่าไม่อนุญาตให้ใช้ชื่อที่ไม่สมบูรณ์ที่นี่ดังนั้น components จะไม่ตรงกับ bower_components และ packages/ui จะไม่ตรงกับ packages/ui-utils (แต่จะตรงกับ packages/ui/utils )

import/parsers

แผนที่จากตัวแยกวิเคราะห์ไปยังอาร์เรย์ส่วนขยายไฟล์ หากมีการจับคู่ไฟล์ตัวแยกวิเคราะห์การพึ่งพาและใช้คีย์แผนที่เป็นตัวแยกวิเคราะห์แทนตัวแยกวิเคราะห์ ESLINT ที่กำหนดค่าไว้ สิ่งนี้มีประโยชน์หากคุณมี inter-op-ing กับ typeScript โดยตรงโดยใช้ webpack ตัวอย่างเช่น:

 // .eslintrc
{
  "settings" : {
    "import/parsers" : {
      "@typescript-eslint/parser" : [ ".ts" , ".tsx" ] ,
    } ,
  } ,
}

ในกรณีนี้จะต้องติดตั้ง @typescript-eslint/parser และต้องการความสามารถจากตำแหน่งของโมดูล eslint ที่รัน (เช่นติดตั้งเป็นเพียร์ของ ESLINT)

ปัจจุบันนี้ได้รับการทดสอบด้วย @typescript-eslint/parser เท่านั้น (และรุ่นก่อน typescript-eslint-parser ) แต่ควรทำงานในทางทฤษฎีกับตัวแยกวิเคราะห์ที่สอดคล้องกับ Estree ในระดับปานกลาง

เป็นการยากที่จะบอกว่าคุณสมบัติปลั๊กอินที่หลากหลายจะได้รับการสนับสนุนเช่นกันโดยขึ้นอยู่กับว่ารูกระต่ายจะไปไกลแค่ไหน ส่งปัญหาหากคุณพบพฤติกรรมแปลก ๆ ที่อยู่ที่นี่ แต่เป็นเหล็กของคุณกับผลลัพธ์ที่น่าจะเป็นไปได้ที่จะปิดด้วย wontfix

import/resolver

ดูผู้แก้ไข

import/cache

การตั้งค่าสำหรับพฤติกรรมแคช การบันทึกความทรงจำถูกใช้ในระดับต่าง ๆ เพื่อหลีกเลี่ยงจำนวน fs.statSync /MODULE จำนวนมากที่จำเป็นสำหรับการรายงานข้อผิดพลาดอย่างถูกต้อง

สำหรับการทำงานของคอนโซล eslint ปกติอายุการใช้งานแคชนั้นไม่เกี่ยวข้องเนื่องจากเราสามารถสันนิษฐานได้ว่าไฟล์ไม่ควรเปลี่ยนแปลงในช่วงอายุของกระบวนการ linter (และทำให้แคชในหน่วยความจำ)

สำหรับกระบวนการที่ยาวนานเช่น eslint_d หรือ eslint-loader อย่างไรก็ตามสิ่งสำคัญคือต้องมีความคิดเกี่ยวกับความเป็นอยู่

หากคุณไม่เคยใช้ eslint_d หรือ eslint-loader คุณสามารถตั้งค่าอายุการใช้งานแคชเป็น Infinity และทุกอย่างควรจะดี:

 // .eslintrc
{
  "settings" : {
    "import/cache" : {
      "lifetime" : "∞" , // or Infinity, in a JS config
    } ,
  } ,
}

มิฉะนั้นตั้งค่าจำนวนเต็มและรายการแคชจะถูกขับไล่หลังจากนั้นหลายวินาทีผ่านไป:

 // .eslintrc
{
  "settings" : {
    "import/cache" : {
      "lifetime" : 5 , // 30 is the default
    } ,
  } ,
}

import/internal-regex

regex สำหรับแพ็คเกจควรถือว่าเป็นภายใน มีประโยชน์เมื่อคุณใช้การตั้งค่า monorepo หรือพัฒนาชุดแพ็คเกจที่ขึ้นอยู่กับกันและกัน

โดยค่าเริ่มต้นแพ็คเกจใด ๆ ที่อ้างอิงจาก import/external-module-folders จะได้รับการพิจารณาว่าเป็น "ภายนอก" รวมถึงแพ็คเกจใน monorepo เช่น Workspace Yarn หรือ Lerna Environment หากคุณต้องการทำเครื่องหมายแพคเกจเหล่านี้ว่า "ภายใน" สิ่งนี้จะเป็นประโยชน์

ตัวอย่างเช่นหากแพ็คเกจของคุณใน monorepo อยู่ใน @scope คุณสามารถกำหนดค่า import/internal-regex เช่นนี้ได้

 // .eslintrc
{
  "settings" : {
    "import/internal-regex" : "^@scope/" ,
  } ,
}

import/node-version

สตริงที่แสดงถึงเวอร์ชันของ node.js ที่คุณใช้ ค่าเท็จจะบ่งบอกถึงเวอร์ชันของ node.js ที่คุณใช้งาน ESLINT ด้วย

 // .eslintrc
{
  "settings" : {
    "import/node-version" : "22.3.4" ,
  } ,
} 

Sublimelinter-Eslint

Sublimelinter-Eslint แนะนำการเปลี่ยนแปลงเพื่อรองรับไฟล์ .eslintignore ซึ่งเปลี่ยนวิธีการส่งผ่านเส้นทางไฟล์ไปยัง ESLINT เมื่อผ้าสำลีในระหว่างการแก้ไข การเปลี่ยนแปลงนี้ส่งพา ธ สัมพัทธ์แทนเส้นทางสัมบูรณ์ไปยังไฟล์ (ตามปกติ ESLINT ให้) ซึ่งสามารถทำให้ปลั๊กอินนี้เป็นไปไม่ได้เพื่อแก้ไขการพึ่งพาระบบไฟล์

วิธีแก้ปัญหานี้ไม่จำเป็นต้องมีอีกต่อไปด้วยการเปิดตัว ESLINT 2.0 เมื่อ. .eslintignore จะได้รับการปรับปรุงให้ทำงานเหมือน .gitignore ซึ่งควรสนับสนุนการเพิกเฉยต่อเส้นทางสัมบูรณ์ผ่าน --stdin-filename

ในระหว่างนี้ดู Roadhump/Sublimelinter-Eslint#58 สำหรับรายละเอียดและการสนทนาเพิ่มเติม แต่โดยพื้นฐานแล้วคุณอาจพบว่าคุณต้องเพิ่มการกำหนดค่า SublimeLinter ต่อไปนี้ลงในไฟล์โครงการประเสริฐของคุณ:

{
    "folders" :
    [
        {
            "path" : " code "
        }
    ],
    "SublimeLinter" :
    {
        "linters" :
        {
            "eslint" :
            {
                "chdir" : " ${project}/code "
            }
        }
    }
}

โปรดทราบว่า ${project}/code ตรงกับ code ที่ให้ไว้ที่ folders[0].path

วัตถุประสงค์ของการตั้งค่า chdir ในกรณีนี้คือการตั้งค่าไดเรกทอรีการทำงานซึ่ง Eslint ถูกดำเนินการให้เป็นเช่นเดียวกับไดเรกทอรีที่ sublimelinter-eslint ฐานเส้นทางที่สัมพันธ์กัน

ดูเอกสาร Sublimelinter บน chdir สำหรับข้อมูลเพิ่มเติมในกรณีที่ไม่ทำงานกับโครงการของคุณ

หากคุณไม่ได้ใช้ .eslintignore หรือไม่มีไฟล์โครงการประเสริฐคุณสามารถทำสิ่งต่อไปนี้ผ่านไฟล์ .sublimelinterrc ในไดเรกทอรีบรรพบุรุษของรหัสของคุณ:

{
  "linters" : {
    "eslint" : {
      "args" : [ " --stdin-filename " , " @ " ]
    }
  }
}

ฉันยังพบว่าฉันต้องตั้งค่า rc_search_limit เป็น null ซึ่งลบขีด จำกัด การค้นหาลำดับชั้นไฟล์เมื่อค้นหาแผนผังไดเรกทอรีสำหรับ .sublimelinterrc :

ในการตั้งค่าแพ็คเกจ / การตั้งค่า Sublimelinter / ผู้ใช้:

{
  "user" : {
    "rc_search_limit" : null
  }
}

ฉันเชื่อว่าค่าเริ่มต้นนี้เป็น 3 ดังนั้นคุณอาจไม่จำเป็นต้องเปลี่ยนมันขึ้นอยู่กับความลึกของโฟลเดอร์โครงการสูงสุด