adidahiya انظر هذا التعليق من قبل @ nchen63.

من @ nchen63 :

يعمل على إصلاح علامات التبويب -> مسافات س ومسافات س -> علامات تبويب ، ولكنه لا يصلح مسافات س -> مسافات ص

يجب أن تفعل x spaces إلى y spaces رغم ذلك.

يستخدم مشروعي كلا من 2 و 4 مسافات. سيكون إصلاح القاعدة x spaces إلى y spaces مفيدًا جدًا.

واجهت أيضًا هذه المشكلة وأتوقع منها إصلاح انتهاكات الحجم ، أو على الأقل الإبلاغ عنها كأخطاء حتى أتمكن من إصلاحها. في الوقت الحالي ، يبدو أن تكوين حجم المسافة البادئة الموثق على الموقع (https://palantir.github.io/tslint/rules/indent/) لا يفعل شيئًا في الواقع.

نعم ، من فضلك أصلح هذا الخطأ. يستخدم Angular CLI مسافتين لمستوى المسافة البادئة عند إنشاء ملف أو مشروع ، وجميع علامات الاقتباس عبارة عن علامات اقتباس مفردة. ثم يتم تشغيل tslint لإصلاحها وفقًا لـ tslint.json الخاص بالمستخدم. تعمل عروض الأسعار بشكل جيد (التحويل إلى علامات اقتباس مزدوجة حسب تفضيلاتي) ، ولكن المسافة البادئة تبقى على مسافتين (بينما أفضل 4). يقوم Tslint بالإبلاغ عن خطأ فقط إذا رأى حرف TAB فعليًا ، ولكن يبدو أنه من المعقول أنه يجب أيضًا التحقق من عدد المسافات

يبدو لي أن التطبيق المستخدم في https://github.com/palantir/tslint/blob/master/src/rules/indentRule.ts ساذج تمامًا ، ولا أتوقع أن يعمل مقابل x spaces -> y spaces . يبدو أن النهج مناسب مع علامات التبويب ، بناءً على التعليق هنا ، لكن لا يمكنني رؤية هذا النهج على أنه قابل للتطبيق للمساحات.

قل ، على سبيل المثال ، تم اختيار عرض المسافة البادئة لمسافتين ، واعتبر هذا الرمز:

foo = {
    a: {
  b: {
    c: 'c'
  }
    },
    d: 'd'
}

كيف سيعرف تطبيقنا الحالي أنه فشل في ذلك على الإطلاق؟ يمر كل تسلسل من المسافات بالتعبير العادي / / . حتى لو بحثنا عن مضاعفات مسافتين ، فسوف يمر هذا. وبالمثل ، في سيناريوهات المسافة البادئة متعددة المستويات ، يمكن أن تكون 4 مسافات بادئة سيناريو عابر ، في حين يجب أن يفشل بدء مستوى واحد من المسافة البادئة مع 4 مسافات.

أعتقد أن أي حل سيحتاج إلى اجتياز AST ، على غرار ما تفعله eslint (https://github.com/eslint/eslint/blob/master/lib/rules/indent.js). الجانب السلبي لذلك هو أننا سنحصل على أداء طفيف مقابل tabs -> spaces أو spaces -> tabs . يمكننا التغلب على ذلك من خلال اختيار التنفيذ بناءً على الإعدادات ، لكنني أتوقع أن التنفيذ الحالي سيفشل إذا تم استخدام مجموعة من علامات التبويب والمسافات ، وفي هذه الحالة يجب علينا فقط استخدام الحل المستند إلى AST.

أعتقد أن بعض أعمال AST المنجزة في تطبيق eslint يمكن معالجتها على الأقل بواسطة مكتبة الطباعة على الورق مباشرة ، لذلك لا ينبغي أن يكون الحل صعبًا للغاية.

كيف سيعرف تطبيقنا الحالي أنه فشل في ذلك على الإطلاق؟

لا تحتاج إلى ذلك من الناحية الفنية. ستمنعك القاعدة align من كتابة كود مثل هذا. بالتأكيد ، يمكننا استخدام AST في قاعدة indent أيضًا. كل ما يهمني هو أن مزيجًا من indent و align يسمح لي بإنجاز ما كتبته في وصف المشكلة.

ستمنعك قاعدة المحاذاة من كتابة كود مثل هذا.

لطيف! لقد فاتني ذلك عندما كنت أقوم بفحص شفرة المصدر. سآخذ ذروة هناك أيضًا. TBH ، أنا أحب فكرة الاستفادة من القواعد الحالية لإبقاء الآخرين ساذجين قدر الإمكان.

أواجه نفس المشكلة. ستلتقط القاعدة أدناه علامات التبويب المستخدمة بدلاً من المسافات ، ولكنها لن تلتقط عددًا غير صحيح من المسافات. يمكنني تغيير الرقم 2 إلى أي رقم آخر ، وما زلت لا أحصل على أخطاء. أنا أستخدم tslint 5.5.0.

"indent": [true, "spaces", 2],

أي تحديثات على هذا؟ (إذا كان هناك شخص لا يعمل على إصلاح بالفعل ، فسأقوم بتجربته.)

mDibyo اذهب لذلك

mDibyo هل أحرزت أي تقدم في هذا الشأن؟

لدي تنفيذ جزئي. سنحاول إكمالها وطرح بيان عام خلال عطلة نهاية الأسبوع

أردت فقط إعطاء تنبيه بأن هذه المشكلة أصبحت ذات أولوية أقل بالنسبة لي منذ أن بدأت في استخدام تنسيق أجمل مع

أجمل ، من ناحية أخرى ، تسعى جاهدة لتلائم معظم التعليمات البرمجية في كل سطر.

ماذا لو كنت لا تريد ذلك؟

مع ضبط عرض الطباعة على 120 ، قد ينتج عن الأجمل رمز مضغوط بشكل مفرط أو غير مرغوب فيه.

نستخدم 120 حرفًا في مشاريعنا.

أيضًا ، إنها تبعية أخرى. أعتقد أنني أفضل استخدام قواعد TSLint العادية.

أعتقد أنني أفضل استخدام قواعد TSLint العادية.

@ glen-84 نعم ، هذا جيد ، وهذا هو السبب في أنني لا أقول أنه يجب علينا إزالة جميع قواعد التنسيق من TSLint والتفويض بالكامل إلى منسق خارجي. من الواضح أن الأجمل لها رأي ولن يختار الجميع استخدامها. لا تزال هذه المشكلة مفتوحة للعلاقات العامة.

ما الذي يحدث مع هذه القضية؟

العلاقات العامة الخاصة بي تعمل في تقدم ، في كثير من الحالات ، لا تزال بحاجة إلى وقت. تضمين التغريدة

لذلك نتوقع أن يتم دمجه قريبًا جدًا:

أي تحديث هنا؟

ربما يمكننا أن نطلب من المشرفين على منسق النص أن وفقًا للإعدادات الموجودة في ملف tslint.json

ومع ذلك ، قد يحتاج الأمر إلى مساعدة في اللعب بلطف مع إعداد أداة تثبيت TSLint.

يبدو أن المشكلة هي أنه يتم الإبلاغ عن الفشل فقط في حالة استخدام حرف المسافة البيضاء الخطأ ، وليس إذا كان حجم المسافة البادئة معطلاً.

adidahiya لا يمكنني الإبلاغ عن خطأ إذا تم استخدام حرف المسافة البادئة الخاطئ. إذا قمت بتعيين القاعدة على مسافات / 4 وكان لدي شيء مثل:

export function foo() {
return 123;
}

أو

export function foo() {
<tab>return 123;
}

لا تبلغ عن خطأ. وفقًا لتعليقك الأصلي ، هل أنت متأكد من أنه يُبلغ عنه إذا كان حرف المسافة البيضاء خاطئًا؟

أي تقدم في هذا؟ فقط يسأل 😝

نصيحة؟ استخدم أجمل .

هل جرب أي شخص قواعد tslint-eslint ؟

تعمل قواعد jscharett tslint-eslint مع قاعدة ter-indent . لسوء الحظ ، لا يغطي المسافة البادئة لـ JSX ...

أي أمل في الإصلاح هنا؟

هذا الخطأ لا يزال غير ثابت في v5.10.0

يجب أن أقول ، لا أتخيل أن TSLint سيكون قادرًا على الإطلاق على تنسيق كود JS بالإضافة إلى Prettier. هذه مشكلة معقدة ، وقد نجحت شركة Prettier في حلها أفضل من أي شخص آخر. لا أعتقد أننا يجب أن نعتمد على TSLint لهذا الغرض ، خاصة وأن المشاريع غالبًا ما تستخدم كلتا الأداتين جنبًا إلى جنب ، ومن المحتمل أن تنشأ النزاعات ...

تحرير: للحصول على فكرة أفضل عن _كيف_تعقد هذه المشكلة ، راجع هذه العلاقات العامة ، أو ألق نظرة على شفرة المصدر أجمل. إذا لم تصدمك هذه المظاهرات على أنها "معقدة" ، فالرجاء مساعدة هذا المشروع بالخروج بعلاقات عامة 😄!

aervin أنا أميل إلى الاختلاف هنا. المشروعان ، في رأيي ، لهما أغراض مختلفة. يقع Prettier في فئة التنسيق بينما يكون TSLint أكثر انسجامًا مع التحقق من الصحة. نعم ، يمكن لـ TSLint القيام بالتنسيق لبعض القواعد ، ولكن الأغراض المقصودة منه كـ linter ، تعود إلى التحقق من الصحة.

مشكلة الاعتماد على الأجمل هي أنها عنيدة. هذا رائع ، هل توافق على أسلوبه ، لكن ماذا لو لم تفعل؟ اعتدنا جميعًا على استخدام JSLint ، واشتكى جميعنا لأنه كان عنيدًا جدًا. ثم جاء JSHint و JSCS ، مما أعطانا بعض السيطرة. الآن لدينا أدوات قوية مثل eslint والتي منحتنا القدرة على تشغيل المكونات الإضافية و "إصلاح" المشكلات تلقائيًا.

بينما أنا متأكد من أن Prettier هو مشروع رائع ، إلا أنني شخصياً أراه بمثابة خطوة إلى الوراء. انها تأخذ السيطرة بعيدا عني. لا يحتاج TSLint إلى "إصلاح" الرمز ، إذا كانت هذه هي المشكلة ، فما عليك سوى وضع علامة عليها كمشكلة. لا أشك في أن هذه المشكلة معقدة ، لكن eslint حلها. كانت القاعدة تعمل ؛ ما الذي تغير لكسرها؟

jscharett شكرًا

كما أنني أوافق على أن أجمل لها رأي. أنا أفضل ذلك عن أجمل. الآن لا يتعين على فريقي مناقشة رأي التنسيق الذي يكون أكثر منطقية. يمكننا جميعًا أن نشكو من أجمل: الضحك:.

تعديل:

كانت القاعدة تعمل ؛ ما الذي تغير لكسرها؟

يقودني تعليق الإصدار الافتتاحي إلى الاعتقاد بأن هذه القاعدة لم تكن تعمل أبدًا على النحو المنشود.

بينما أنا متأكد من أن Prettier هو مشروع رائع ، إلا أنني شخصياً أراه بمثابة خطوة إلى الوراء. انها تأخذ السيطرة بعيدا عني.

كانت تجربتي هي أنني اعتقدت أنني كنت مهتمًا بالتحكم الدقيق في قواعد التنسيق حتى أضفت Prettier ... وبعد فترة وجيزة أدركت أنني لا أهتم كثيرًا بالطريقة المحددة لتنسيق الأشياء ، مثل حقيقة ذلك تم تنسيقها بشكل متسق. إنه عبء معرفي ضخم لا داعي للقلق بشأن ذلك بعد الآن ، والتركيز كليًا على ما أريد أن يفعله الكود بدلاً من شكله.

يتحقق tslint بالفعل من صحة الأشياء الأخرى التي تندرج تحت فئة التنسيق. على سبيل المثال ، فرض المحاذاة أو نمط الأقواس أو المسافات بين أسماء المتغيرات وعوامل التشغيل. بالإضافة إلى ذلك ، من المستحسن أن تكون قادرًا على التحقق من صحة المسافة البادئة دون الحاجة إلى الاعتماد على حل عنيد مثل أجمل.

يحتاج إلى مناقشة أقل ، والمزيد من العلاقات العامة. 😉😉

المضي قدما fxsam

كان تعليقي في الغالب لسان الخد. على الرغم من أنني أتساءل لماذا مضى على هذه المشكلة أكثر من عام ولم يتم إحراز أي تقدم. يبدو أن الجميع يتجادلون فقط حول linting مقابل Prettier.

ffxsam لأن هناك جدلًا حول ما إذا كان tslint يتعلق أكثر بجزء ts أو جزء النسالة

هذه نقطة صحيحة. يبدو أن هناك بعض التداخل مع TSLint / ESLint. ولكن تظل الحقيقة أن هناك خيارًا غير عامل indent تم كسره لمن يعرف كم من الوقت. يبدو أن أسرع / أسهل شيء هو أن يقوم شخص مطلع على كود TSLint بإصلاحه ...؟

التصويت لصالح إصلاح x spaces => y spaces . هذه ميزة تعتمد عليها شركتنا بشكل كبير. لا معنى لمجرد عدم إصلاح هذا.

ffxsam أنا أشاهد هذه القضية منذ ما يقرب من عام الآن ، نعم لقد مضى وقت طويل ، ولكن كما ترون هناك محاولتان للعلاقات العامة ، ولم ينجح الأمر حتى الآن ، أعتقد أنه أصعب مما يبدو ، ولكن من بالطبع قد يكون الأمر أسهل بالنسبة إلى المشرفين ، فأنا أتحلى بالكثير من الصبر:

لا تزال قابلة للتكرار في المشروع الفارغ
https://github.com/dimaShin/tslint-reproduce-2814

مرحبًا dimaShin ، شكرًا على

نحن فقط ننتظر هذه الميزة ، ربما مع خيار الإصلاح ، لكن هذه ليست مشكلة بالنسبة لي. آخر مرة تحققت من أن الأشخاص كانوا يستخدمون أجمل للتحقق من المسافة البادئة و tslint لكل شيء آخر.

أنا لا أقول أن هذا سيكون مناسبًا لك ، فبالنسبة لي بالتأكيد ليس كذلك ، أقترح أيضًا استخدام .editorconfig لهذا الخيار المعين والتبديل إلى tslint لاحقًا عند حل هذه المشكلة.

مرة أخرى ، نشكرك على تخصيص بعض الوقت لإضافة المزيد من المعلومات :)

دعنا نحدد استراتيجية لفحص المسافة البادئة. كمرجع ، إليك الإستراتيجية التي تستخدمها eslint:

1. يقوم مثيل OffsetStorage بتخزين خريطة الإزاحات المرغوبة ، حيث يكون لكل رمز إزاحة محددة من رمز مميز آخر محدد أو إلى العمود الأول.
2. أثناء اجتياز AST ، قم بتعديل الإزاحات المطلوبة من الرموز وفقًا لذلك. على سبيل المثال ، عند إدخال BlockStatement ، قم بإزاحة جميع الرموز المميزة في BlockStatement بمستوى مسافة بادئة واحدة من القوس المتعرج الافتتاحي لـ BlockStatement.
3. بعد اجتياز AST ، احسب مستويات المسافة البادئة المتوقعة لكل رمز وفقًا لحاوية OffsetStorage.
4. لكل سطر ، قارن المسافة البادئة المتوقعة للرمز المميز الأول بالمسافة البادئة الفعلية في الملف ، وقم بالإبلاغ عن الرمز المميز إذا كانت القيمتان غير متساويتين.

تعتمد هذه الإستراتيجية على بناء الجملة ، والذي ، بناءً على التعليقات السابقة ، شديد الرأي لأنه يتطلب كسر الأسطر بطريقة معينة. أقترح طريقة بسيطة للتحقق من المسافة البادئة مستقلة عن كيفية تقسيم الكود إلى أسطر:

1. يتم تحديد وحدة المسافة البادئة في الإعدادات. بالنسبة لعلامات التبويب ، فهي عبارة عن حرف جدولة واحد. للمسافات ، تتكون من حرفين أو أربعة أحرف مسافات.
2. يجب أن يحتوي السطر الأول غير الفارغ من الملف على صفر من وحدات المسافة البادئة
3. يجب أن يحتوي كل سطر لاحق غير فارغ على أي منهما
   أ. نفس عدد وحدات المسافة البادئة مثل السطر السابق غير الفارغ أو
   ب. أقل من عدد وحدات المسافة البادئة مثل السطر السابق غير الفارغ أو
   ج. يزيد عدد وحدات المسافة البادئة بمقدار واحد بالضبط عن السطر السابق غير الفارغ

بعض الأشياء الإضافية للمناقشة:

• لا يوجد تأثير لمعلمة الحجم مع علامات التبويب (لماذا؟)
• لا يوجد سبب لعدم إمكانية أن تكون معلمة الحجم أي عدد صحيح موجب
• ربما لا يمكن تنفيذ الإصلاح التلقائي لحجم المسافة البادئة بدون الذهاب إلى مسار إستراتيجية بناء الجملة

stifflerus أيضًا يجب أن تعمل القاعدة مع وظيفة if / for / arrow بدون {} كتل

maximelkin هل الأمثلة التي قدمتها لم يتم وضع مسافة بادئة لها في السطر الثاني؟ هل يمكنك إعطاء مثال على أين ستفشل الإستراتيجية المقترحة؟

if(this) that(); //okay because it's all one line

if(this)
  that(); //also okay because the second line is indented

let x = () => f(); //okay because it's all one line

let y = () =>
  f(); // I have not seen any code but like this but it would be okay

سيكون رائعًا إذا تم إصلاح هذا.

لا أستطيع أن أصدق أن شيئًا أساسيًا مثل تطبيق قواعد المسافة البادئة لا يزال غير فعال.

إذن ، لا توجد طريقة لفحص كود TS هذا في 2018؟

const x = {
  a: 1,
   b: 2,
}

تناسبني
./.eslintrc.ts.js :

module.exports = {
  'parser': 'typescript-eslint-parser',
  'parserOptions': {
    'ecmaVersion': 6,
    'sourceType': 'module',
    'ecmaFeatures': {
      'jsx': true,
    }
  },
  'plugins': [
    'react',
  ],
  'rules': {
    'indent': ['error', 2],
  },
}

yarn eslint --no-eslintrc --config ./.eslintrc.ts.js --ext .tsx src

https://github.com/eslint/typescript-eslint-parser

الحل الذي وجدته لمشكلة المسافة البادئة في الزاوية هو إضافة أجمل بالخطوات التالية:
تثبيت npm - حفظ-dev tslint-plugin-prettier أجمل قواعد tslint-jasmine
تحرير tslint.json ->
"" دليل القواعد ": [
"node_modules / codelyzer" ،
"node_modules / tslint-plugin-prettier"،
"node_modules / tslint-jasmine-rules / dist"

] ،
"extends": "tslint-plugin-prettier"،

"قواعد": {
"أجمل": صحيح ،
// أضف هنا قواعدك المطلوبة

وفي packege.json أضف ->
"،" أجمل ": {
"singleQuote": صحيح ،
"printWidth": 140 ،
"شبه": صحيح ،
"bracketSpacing": صحيح ،
"arrowParens": "دائمًا"،
"المحلل اللغوي": "مطبعي"
} "

هذه وظيفة يستخدمها الجميع تقريبًا على أساس يومي. سأكون ممتنا إذا حظيت هذه القضية بمزيد من الاهتمام.

يا رفاق ، يمكنك استخدام خيار ter-indent الذي توفره قواعد tslint-eslint.

"مسافة بادئة ثلاثية": [true، 4، {"SwitchCase": 1}]

عملت معي. هتافات!

hiteshaleriya هذا ما كان لدي في مشروعي لفترة من الوقت الآن ، لكنه لا يعمل في الواقع على إصلاح الأخطاء ، فقط إسكاتهم ... هذا هو tslint.json :

{
    "extends": "tslint-config-airbnb",
    "rules": {
        "ter-indent": ["error", "spaces", 4],
        "no-unused-vars": ["warn"],
        "no-multi-spaces": false,
        "no-console": false,
        "max-line-length": false,
        "import-name": false
    }
}

وإليك مثال ذي صلة انتهى دون التسبب في تحذيرات أو أخطاء:

function retrieveAndSetConfig(): Promise<any> {
  return new Promise((resolve, _) => {
  // ^ 2 spaces, expected 4
    const ghe = new GHEUtils();
    // ^ 4 spaces, expected 8
    // ...
}

كما أنه لا يعرض أخطاء عند استخدام علامات التبويب (على الرغم من أن ذلك قد يكون حسب التصميم عند وجود 4 مسافات؟).

SpencerKaiser هل يمكنك تحديث قاعدة ter-indent كما هو موضح أدناه ثم حاول:

"ter-indent": [true, 4]

لقد جربت المثال الخاص بك وهو يعمل كما هو متوقع في نهايتي (يسبب أخطاء)

شكرا hiteshaleriya على العودة إلي بسرعة! لذا فهي تُلقي الآن بالأخطاء كما هو متوقع (👍) لكنها لا تصلح أيًا منها بـ --fix . أيه أفكار؟

SpencerKaiser هل يمكنك محاولة تشغيل الأمر --fix مرتين. في المرة الأولى ، ستضع مسافة بادئة للسطر الأول فقط ، ثم في المرة الثانية ، ستضع مسافة بادئة للباقي (لكود المثال) يبدو غريبًا ولكن يرجى الإبلاغ عن المشكلة إذا لم تنجح.

hiteshaleriya لذا بضع ملاحظات ... لم أكن بحاجة إلى تشغيلها مرة أخرى ، كنت بحاجة لتشغيلها تقريبًا n/4 مرات حيث n هو طول المسافة البادئة في مسافات أبعد خط مسافة بادئة في المشروع ¯ \ _ (ツ) _ / ¯

بعد الانتهاء من كل منهم أخيرًا ، يبدو أنه يتخطى أخطاء المسافة البادئة الأساسية مثل هذا:

class Something {
    function myFunc() {
        const myThing = {
            wat: 1,
         wattt: 5,    // 9 spaces, expected 12
        };
    }
}

إذا أخطأت في مستوى المسافة البادئة لـ const (السطر 17) إلى مسافات 0 ، فسيتم تمييز باقيه بالأخطاء _ باستثناء_ السطر الذي يحتوي على المسافة عندما أترك --fix :

ERROR: 17:1  ter-indent  Expected indentation of 8 spaces but found 0.
ERROR: 18:1  ter-indent  Expected indentation of 4 spaces but found 12.
ERROR: 20:1  ter-indent  Expected indentation of 0 spaces but found 8.

مع --fix ، هذا هو المرور الأول:

        const myThing = {
    wat: 1,
         wattt: 5,
};

والممر الثاني:

        const myThing = {
            wat: 1,
         wattt: 5,
        };

أفكار؟؟

كيف قمت بحل هذه المشكلة مع tslint-config-prettier

shubich انتهى بي الأمر بفعل نفس الشيء ...

هل هناك أي تحديث على ذلك؟

MaKCbIMKo بقدر ما أفهم ، سيتحرك الفريق بأكمله لدمج eslint visit typed-eslint ، وفي المستقبل القريب سيتم إهمال tslint ، لذا فهي جيدة مثل تجاهل هذه القاعدة في الوقت الحالي (أو استخدم tslint-config-prettier )

الختام بسبب تعقيد هذه المهمة والتغيير في اتجاه المشروع: # 4534

تعمل قاعدة ESLint من النوع eslint بشكل مثالي بالنسبة لي (راجع # 4534):

module.exports = {
    "env": {
        "browser": true,
    },
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2019,
        "sourceType": "module",
        "ecmaFeatures": {
            "jsx": true
        },
        "project": "./tsconfig.json",
    },
    "plugins": ["@typescript-eslint"],
    "rules": {
        "@typescript-eslint/indent": ["error", 2] // or ["error", "tab"]
    }
}

كيف قمت بحل هذه المشكلة مع tslint-config-prettier

الرابط غير موجود.

🤖 بيب بوب! 👉 تم إهمال TSLint 👈 ويجب عليك التبديل إلى print-eslint ! 🤖

🔒 تم إقفال هذه المشكلة لمنع المزيد من المناقشات غير الضرورية. شكرا لك! 👋

PS tslint-config-prettier - الرجاء التوقف عن استخدام _linters_ مثل TSLint لتنسيق TypeScript الخاص بك. من الأفضل القيام بذلك بواسطة منسق مثل أجمل .