Vscode: طلب الميزة: إظهار جميع الأخطاء والتحذيرات في المشروع لجميع الملفات ، وليس الملفات المفتوحة فقط

waderyan هذا طلب ميزة لأعمال البناء التي ناقشناها مع فريق TS.

للرجوع إليها هنا رابط إلى المشكلة - https://github.com/Microsoft/TypeScript/issues/11229

حسنًا ، أنا فقط أستخدم مهمة إنشاء المشاهدة مع "problemMatcher": "$tsc-watch" (راجع https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchers) وجميع الأخطاء و يتم عرض التحذيرات بشكل صحيح في عرض المشاكل. إنه سير عمل لطيف للغاية لأن التغييرات في الملفات المفتوحة يتم ملاحظتها على الفور بسبب خادم اللغة ، ولكن حفظ المحفزات التجميعية المتزايدة (مع tsc --watch ) والتي لا تزال تستغرق بعض الوقت ، ولكن يمكنني التحكم في زمن الانتقال هذا عن طريق الحفظ / عدم الحفظ بعد.

أي ETA على هذا؟ هناك الكثير من المشكلات المفتوحة لهذه الميزة ولست متأكدًا مما إذا فاتني أي شيء أم لا: ابتسم:

@ maxime1992 شكرا على المتابعة. هذا على رادارنا. لا يوجد جدول زمني ثابت حتى الآن.

هناك شيء لم أدركه وهو أنه من الممكن القيام بذلك باستخدام البنية التحتية لمهام Google التي يمتلكها VSCode. كل ما عليك فعله هو وضع هذا في مهامك. json:

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", "."],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

ثم قم بتشغيله وستحصل على جميع الأخطاء عبر مشروعك بأكمله في عرض المشاكل.

أنا محير قليلاً لماذا لا يتم عرض هذا بشكل أكثر بروزًا. إنه مفيد للغاية ورائع.

johnfn حل رائع ، شكرًا جزيلاً. أود حتى أن أضيف الوسيطة "--noEmit" إذا كان الغرض الوحيد من المهمة هو إظهار الأخطاء

{
  "version": "0.1.0",
  "command": "tsc",
  "isShellCommand": true,
  "args": ["-w", "-p", ".", "--noEmit"],
  "showOutput": "silent",
  "isBackground": true,
  "problemMatcher": "$tsc-watch"
}

kevinjreece يمكنك استخدام ميزة

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

يمكنك فتح لوحة المشاكل بـ Ctrl+Shift+M (أو Cmd+Shift+M ) ، ستجدها ضمن اختصارات لوحة المفاتيح كـ "إظهار المشاكل" - هل هذا ما تقصده؟

لا ، أرغب في اختصار للانتقال إلى الملف التالي الذي يحتوي على خطأ ، سواء كان مفتوحًا أم لا.

كنت أبحث في إنشاء امتداد للقيام بذلك ، لكن واجهة برمجة التطبيقات مغلقة بإحكام ، والأوامر لا تستطيع الوصول إلى MarkerService (تتبع المشاكل) بأي طريقة يمكنني رؤيتها.

حسنا أرى ذلك. يمكن أن يكون مفيدا جدا. الأصوات مثل Problems مجال vscode بشكل عام لديها الكثير من الفرص لتحسين.

أي شخص يواجه هذه المشكلة https://github.com/Microsoft/vscode/issues/34412؟
إذا حدث نفس الخطأ بالضبط بين البنيات اللاحقة فإنه يتجاهلها

الحيلة مع tsc في مهمة تصحيح ليست ممكنة دائمًا ، على سبيل المثال في مشروع Vue مع أدوات تحميل Webpack مخصصة للتعامل مع ملفات .vue ( tsc لا يمكن تحليل ملفات Vue خارج الصندوق ).

ولكن يمكنك العثور على طريقة لوجود جميع الأخطاء من خلال مشاهدة مشروعك وتجميعه في محطة طرفية لـ VS Code.

على سبيل المثال ، قمت بعمل هذا البرنامج النصي npm:
"live-check": "webpack --config ./build/webpack.dev.conf.js -w --display none",

وقمت بتشغيله عبر "npm run live-check" في محطة VS ولدي كل الأخطاء في الوقت الفعلي.

حتى مع الحل من johnfn @ ، يمكنني رؤية الأخطاء من الملفات المفتوحة فقط :(.
أرى المهمة قيد التشغيل في علامة تبويب الإخراج ، لكن لا تظهر أي خطأ

مهام. json:

{
    "version": "0.1.0",
    "command": "tsc",
    "isShellCommand": true,
    "args": ["-w", "-p", ".", "--noEmit"],
    "showOutput": "silent",
    "isBackground": true,
    "problemMatcher": "$tsc-watch"
  }

tsconfig.json

{
  "compilerOptions": {
    /* Basic Options */
    "target": "es2015",                       /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
    "module": "es2015",                       /* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. */
    // "lib": [],                             /* Specify library files to be included in the compilation:  */
    "allowJs": true,                          /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    "jsx": "react-native",                    /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    "sourceMap": true,                        /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    "outDir": "./build",                      /* Redirect output structure to the directory. */
    "rootDir": "./src",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    "removeComments": false,                  /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    "noImplicitAny": true,                    /* Raise error on expressions and declarations with an implied 'any' type. */
    "strictNullChecks": true,                 /* Enable strict null checks. */
    "noImplicitThis": true,                   /* Raise error on 'this' expressions with an implied 'any' type. */
    "alwaysStrict": true,                     /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    "moduleResolution": "node",               /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    // "paths": {},                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    "allowSyntheticDefaultImports": true      /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */

    /* Source Map Options */
    // "sourceRoot": "./",                    /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "./",                       /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  },
  "include": [
    "src/**/*",
    "./node_modules/react-native-dev-kit/**/*"
  ],
  "exclude": [
    "__tests__",
    "index.android.js",
    "index.ios.js",
    "build",
    "local_history",
    "node_modules"
  ]
}

لماذا لا يمكنني رؤية أخطاء من الملفات المغلقة (أنا متأكد من وجود أخطاء)؟

👍

كما قال apperside .. المهمة تظهر الأخطاء فقط عندما يتغير الملف ..

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

يبدو أن تنسيق المهمة تغير قليلاً في أحدث إصدارات vscode. الشكل الجديد هو:

        {
            "label": "Monitor TS Errors",
            "command": "./node_modules/.bin/tsc",
            "type": "shell",
            "args": ["--watch", "--project", "."],
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": false,
                "panel": "shared"
            },
            "isBackground": true,
            "problemMatcher": "$tsc-watch"
        }

هل تبدأ المهمة في كل مرة تفتح فيها VSCode؟ أم أن هناك طريقة لتشغيله تلقائيًا؟

أعتقد أن أحدث إصدار من رمز VS يعرض عدد الأخطاء لكل ملف

كيف يمكنني تعطيل هذا؟

// إظهار الأخطاء والتحذيرات على الملفات والمجلدات.
"problems.decorations.enabled": صحيح ،

ببساطة ضع هذا في خطأ ؛)

في الخميس 15 فبراير 2018 الساعة 1:36 صباحًا ، كتب pabloli [email protected] :

كيف يمكنني تعطيل هذا؟

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Microsoft/vscode/issues/13953#issuecomment-365838054 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAy0aayEHkVuxumJRuZz-mdWmBvBhdn9ks5tU9B2gaJpZM4KaH3J
.

هذا ما أستخدمه

{
  "label": "TSCompileAll",
  "type": "shell",
  "command": "./node_modules/.bin/tsc --watch --noEmit --project .",
  "problemMatcher": ["$tsc-watch"]
}

إنه لا يقدر بثمن ، أتساءل عما إذا كان يمكن جعله افتراضيًا أو على الأقل إعدادًا.

هل من الممكن بدء هذه المهمة تلقائيًا في مساحة عمل أو مشروع؟

انا استعمل هذا:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "tsc watch",
            "type": "shell",
            "command": "./node_modules/.bin/tsc",
            "isBackground": true,
            "args": ["--watch", "--noEmit", "--project", "www"],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "presentation": {
                "reveal": "never",
                "echo": false,
                "focus": false,
                "panel": "dedicated"
            },
            "problemMatcher": "$tsc-watch"
        }
    ]
}

أستخدم هذا الامتداد لتشغيل المهمة عند بدء التشغيل: https://marketplace.visualstudio.com/items؟

ما زلت لا أعرف كيفية الاحتفاظ بأخطاء ملف (في لوحة المشاكل) عند إغلاقه.

سيكون من المفيد جدًا وجود خيار للاحتفاظ بالمشكلات المدرجة في اللوحة بعد إغلاق الملف.

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

هل هناك طريقة لفتح جميع الملفات دفعة واحدة بأمر واحد؟ سيكون ذلك حلاً مقبولًا بالنسبة لي.

daarong عادةً ما يكون لدي eslint-watch قيد التشغيل في المحطة بينما أقوم بالترميز في vscode للتحقق من المشروع بأكمله. إنه ليس جيدًا تمامًا مثل وجود جميع معلومات الفحص في vscode ، ولكنه احتياطي مناسب لرؤية ما إذا كانت أي ملفات في مشروعك بها أخطاء في لمحة.

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

هل هذه مزحه؟ لدي حوالي 2000 ملف يجب أن أذهب وفتحها جميعًا يدويًا للبحث عن أخطاء النسالة ؟؟؟

هل هناك طريقة لتشغيل ts lint in vs code؟ يمكنني استخدام البريد. tslint لعرضه في وحدة التحكم.
سيكون من الرائع لو تمكنت من تشغيل VS Code لمسح جميع الملفات في مجلد src بحثًا عن أخطاء (بناء الجملة والنتير)
بمعنى آخر: كيف تفتح جميع الملفات (ts) في مجلد src في نفس الوقت؟

لا تبحث في مجلدات أخرى مثل node_modules. ... فقط للبروتوكول. 😄
ربما يكون خيار مسار التضمين / الاستبعاد أمرًا جيدًا؟ ...

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

إليك كيف يمكنك رؤية جميع المشكلات في أقل من 10 ثوانٍ.

أنت تستخدم حيلة صغيرة.

افتح واستبدل جميع الملفات (Ctrl + Shift + H).

يحل محل ؛ مع ؛

ضرب استبدال الكل. هذا كل شيء. الآن ، تحقق من المشاكل.

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

أي تحديث على هذا؟ على الرغم من عمل اختصار Ajay ، إلا أنه يبدو مبتذلًا إلى حد ما. يبدو أن هذا فوز واضح وسهل لـ VSC. كل ما هو مطلوب هو مفتاح "إظهار كافة الأخطاء / إظهار الأخطاء للملفات المفتوحة".

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

هذا صحيح ، أعتقد أن المشكلة تتعلق بتنسيق خدمة TS التي تتحقق من جميع الملفات المفتوحة ومن ناحية أخرى بفحص الملفات المغلقة والتي لا يتم فحصها تلقائيًا في العادة ، فهل هذا صحيح؟ لذا فإن الحل السهل هو التأكد من أن جزء المشاكل يستقبل جميع مشاكل TS من مصدر واحد ، هل هذا صحيح؟

رؤية كيف لا يتم حل المشكلة من قبل فريق vscode (؟) ، اقتراح:

ألا ينبغي أن يكون من الممكن حل هذا عن طريق الملحق أو عبر أداة مطابقة مشكلة مهمة vscode؟ لأنه بعد ذلك يمكنك ضمان ماذا ومتى يظهر جزء المشاكل بنفسك على أي حال؟ ثم سيكون عليك فقط تعطيل vscode بطريقة أو بأخرى من إظهار الأشياء الخاصة به؟ هل يستطيع مطور vscode إخباري ما إذا كان شيء من هذا القبيل سيكون عمليًا؟

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

كيف يمكن ألا يكون هذا هو الأكثر أهمية من بين جميع القضايا التي يجب حلها أولاً؟ IDE مكسور حتى يتم إصلاحه.

حسنًا ، هذا حل مبتكر.
استخدم حل plievone بجعل مهمة تستخدم $ tsc-watch. ثم احصل على مكون إضافي مثل AutoLaunch لتشغيل المهمة في كل مرة يتم فيها فتح Visual Studio Code. (https://marketplace.visualstudio.com/items؟itemName=philfontaine.autolaunch)

لتوسيع اقتراح mateuscb ، ربما يكون شيئًا ما في قائمة السياق في مستكشف الملفات جيدًا حيث يمكنك النقر بزر الماوس الأيمن على مجلد معين والقيام بـ "العثور على مشاكل في المجلد" سيكون خيارًا جيدًا ، لأنه سيسمح بـ يقرر المستخدم المقايضة بين النطاق مقابل السرعة.

لا تفعل اقتراح @ ajayRaghav37 ، وسوف يتعطل vscode.
لعنة ، لن أكتب كود ts مرة أخرى في المستقبل)

أي تحديثات أو أفكار متى سيتم وضع هذا في خط الأنابيب؟ سيكون من الرائع الحصول على هذه الميزة خارج الصندوق.

أدخلت ES-Lint مهمة جديدة في VS Code. يجب عليك تمكينه في إعدادات مساحة العمل.

"eslint.provideLintTask": true

ما عليك سوى الانتقال إلى قائمة المحطة الطرفية وتحديد مهمة التشغيل ، ثم الاختيار

eslint: لينت المجلد بأكمله.

يمكنك أيضًا إصلاح معظم المشكلات تلقائيًا عن طريق تشغيل الأمر التالي في الجهاز:

.\node_modules\.bin\eslint.cmd --fix .

المرجع: https://marketplace.visualstudio.com/items؟itemName=dbaeumer.vscode-eslint

بينما لا نزال ننتظر مشكلة الماسح الضوئي في VS Code ، يعد هذا بديلاً جيدًا بما يكفي إذا كنت تستخدم eslint.

ميزة مطلوبة بشدة للمشاريع الكبيرة بالفعل. أي تحديثات؟

@ ajayRaghav37 ، يبدو أن eslint غير قادرة على اكتشاف أخطاء الكتابة ، فقط قواعد الفحص:

https://github.com/typescript-eslint/typescript-eslint/issues/36#issuecomment -478820127

+1

يصل هذا. أعتقد أيضًا أنه يجب أن يكون من الممكن تعطيل فحص TS المدمج وفحصها واستخدام النتائج من مهمة البناء فقط.

+1

أقوم الآن بتشغيل tsc --noEmit -w لحل هذه المشكلة.

لكنني أعتقد أنه سيكون من الأفضل مشاركة ts-server مع VSCode.

لكن لماذا لم يتم تطبيقه لفترة طويلة؟

هل يوجد أي شخص هنا على دراية بخادم لغة TS؟ هل تفتقر LSP API إلى طريقة لإيصال ذلك إلى IDE؟ هل هذا قلق الأداء؟ من الواضح أن الناس متحمسون لعدم وجود هذه الميزة (أنا) ، لذلك أعتقد أنه سيكون هناك اهتمام بمساعدة المجتمع لتجاوز خط النهاية.

ولكن هذا إذا كانت المشكلة هنا هي مجرد نقص القوى العاملة في فريق VS Code.

إذا كانت المشكلة مختلفة (تأثير أكبر على بنية VS Code ، يتطلب تغيير LSP ، وتأثير أداء غير واضح ، واعتبارات UX) ، فإن معرفة ذلك سيساعد في تفسير سبب استغراق هذه الميزة التي تبدو مباشرة الكثير من الوقت.

أرى تعليقات مختلفة في هذه المشكلة حول كيفية مسؤولية ذلك على فريق TypeScript وليس فريق Visual Studio Code. ولكن هذه أيضًا مشكلة في وظيفة "@ ts-check" المضمنة في VS Code. الحلول المذكورة في هذا المنشور لاستخدام مهمة تنفيذ الأمر "tsc" لا تعمل بالنسبة لي لأنني لا أملك tsc مثبتًا (أنا فقط أستخدم @ ts-check و jsdoc).

من قبل ، كنت أضغط على كل ملف في مشروعي للعثور على الأخطاء. كان ذلك مملاً ، لكن على الأقل لم تختف المشكلات من الشريط الجانبي بمجرد إغلاق الملف. بعد أحد تحديثات الأشهر القليلة الماضية ، ظهرت هذه المشكلة: # 73153.

كيف يمكن ألا يكون هذا هو الأكثر أهمية من بين جميع القضايا التي يجب حلها أولاً؟ IDE مكسور حتى يتم إصلاحه.

أنا موافق.

متى؟

يعمل الحل "المقبول" أعلاه ، ولكن تم إهمال بعض الحقول.

{
      "label": "Watch TS Errors",
      "type": "shell",
      "command": "tsc",
      "args": ["-w", "-p", ".", "--noEmit"],
      "isBackground": true,
      "problemMatcher": "$tsc-watch"
}

يعمل لدي.

راجع أيضًا https://code.visualstudio.com/docs/editor/tasks لإنشاء ملف مهام. json إذا لم يكن لديك ملف حتى الآن

هل من الممكن تعطيل خادم TS المدمج في VS Code عند تشغيل tsc كمهمة بناء مثل هذه؟ السبب الذي أطلبه هو أننا نحصل على مجموعتين من الأخطاء: تلك من خادم TS المدمج وتلك من المهمة ، وأحيانًا تكون غير متزامنة.

IDE معطل وغير قابل للاستخدام للعمل في مشاريع Typescript. لذلك لا بد لي من التمسك بالإصدار 1.28.2 وتعطيل التحديثات.

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

أكتوبر 2019 وهذا لا يزال طليقا.

3 سنوات لميزة يقدمها الآخرون IDE .... NNNNICCCEEEEEEEEEEEE

3 سنوات لميزة يقدمها الآخرون IDE .... NNNNICCCEEEEEEEEEEEE

تذكر أن VSCode ليس IDE. إنه شيء beetwen Editor و IDE.
على أي حال ، آمل أن يفعلوا ذلك

3 سنوات لميزة يقدمها الآخرون IDE .... NNNNICCCEEEEEEEEEEEE

تذكر أن VSCode ليس IDE. إنه شيء beetwen Editor و IDE.
على أي حال ، آمل أن يفعلوا ذلك

من يهتم. ومع ذلك ، فأنا لست قادرًا حتى على تشغيل المهمة الملعونة وتشغيلها للتحقق من ملفات ts.

يبدو أن الدليل المقدم يشبه تعلم لغة برمجة جديدة تمامًا.
نحن نعمل وننتج ، ليس لدي الوقت لإهدار تعلم جميع حزم الويب (والأدوات المماثلة) من الهراء لوضع نص يقوم بفحص ملفات ts الخاصة بي على IDE (أنا أتصل به IDE موافق؟) حتى أنه يدعم اللغة التي أنشأها نفس منشئو IDE بشكل صحيح ....

يا له من هراء

يا له من هراء

للحصول على القليل من المنظور:

صنعت Microsoft بعض البرامج وأعطتها مجانًا.
هذا البرنامج مفيد لملايين الأشخاص الذين يشعرون بالامتنان له.
لا يجبرك Microsoft على استخدام هذا البرنامج.

أنت غاضب منهم لأنهم قدموا لك شيئًا مجانًا لأنه ليس مثاليًا كما يمكن أن يكون من الناحية النظرية.

كما أنه يستخدم نفس لغة "IDE" ، و IDE مفتوح المصدر ويقبل طلبات السحب ...

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

ومع ذلك ، فإن VS Code هو بلا شك أفضل IDE لتطوير JS / TS - حسنًا ، قد يكون أفضل منتج MS ، في المرتبة الثانية بعد Github. كانت هناك بالتأكيد تحسينات في الميزات والعروض ، والكم الهائل من الإضافات يجعلني سعيدًا جدًا. نعم ، يمكن أن تكون المستندات أفضل ، ولكن يمكنك قول ذلك عن كل التوثيق التقني المتاح.

أنا متأكد من أن فريق VS Code يعمل باستمرار بجد لتقديم أدوات وتكامل أفضل.

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

الإضافة إلى الحل البديل - يبدو أن هناك الآن مهمة تم تكوينها مسبقًا لمراقبة إخراج tsc -w. على جهاز Mac ، Terminal -> تكوين المهام ... -> tsc: watch - tsconfig.json. ثم اضغط على ctrl + shift + B وقم بتشغيل المهمة.

بعد ثلاث سنوات ... هل من أخبار؟

وسط إعادة بيع ديون على نطاق واسع. لم أكن أدرك أنه بإغلاق جميع الملفات المتأثرة لن أرى جميع الأخطاء بعد الآن :-(

3 سنوات وما زالت مفتوحة: راقصة:

3 سنوات وما زالت مفتوحة

رائع ، أصوات سلبية عشوائية من الحمقى.

على أي حال ، هذه قضية مزعجة !!! أنت تدرك أن لدى المرء مئات الملفات في مشروع تجاري جاد ، أليس كذلك؟
كيف يفترض بنا أن نتابعهم بالذهن؟

إنها إحدى الوظائف الأساسية التي يستخدم الأشخاص من أجلها IDEs .....

والآن يبدو أنه ينتشر أيضًا في الاستوديو المرئي وتطوره من وقت لآخر

بالمناسبة ، يبدو أن الأشياء المهمة تعمل على التخفيف من حدتها ، وبالنسبة لملفات ts ، يبدو أن هناك أيضًا بعض البرامج النصية للتحكم المتاحة. لا أعرف ما إذا كان قد تم تثبيتها بواسطة جميع ملحقات الزاوية / المطبوعة من مدير الامتدادات في vscode ، ولكن إذا قمت بالبحث في شريط البحث عن المهام (الذي يظهر [هنا]) (https://code.visualstudio.com / docs / editor / مهام) يمكنك البحث عن شيء مثل الساعة أو شيء من هذا القبيل يؤدي الحيلة في كل مرة تقوم فيها بالتجميع (يبدو أنه يفعل ذلك جنبًا إلى جنب مع عملية التجميع العادية ، وهي مهمة أخرى أيضًا)

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

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

ولكن هل يمكنك إنشاء علامة تبويب أخرى ، على سبيل المثال Build Output تمامًا كما هو الحال في Visual Studio.

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

أيضًا F4 / Shift-F4 الاختصارات ستكون رائعة للانتقال إلى الخطأ التالي / السابق (لكن هذا ليس بالغ الأهمية)

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

أو ربما يمكن لشخص ما إنشاء امتداد لهذا؟

أنا أستخدم امتداد "Open Matching Files" لفتح جميع ملفات .ts. إنه أداء ثقيل بعض الشيء ، لكنه على الأقل ينجز المهمة.

أعتقد أنه بسبب خادم لغة النص المطبوع عليه خيط واحد ولا يتصرف مثل مترجم C #
ما زلت أنتظر هذه الميزة ، لأنني أحيانًا أقوم بفتح ملف وأحاول البحث عن النوع بالاسم باستخدام لوحة الأوامر مع # ، ولا يحدث شيء 😞

بالنسبة لأولئك الذين يرغبون في العيش على حافة الهاوية ، يقدم الإصدار القادم من المطلعين على أكواد VS إعداد "typescript.tsserver.experimental.enableProjectDiagnostics" الذي يتيح الإبلاغ عن الأخطاء التجريبية للمشروع على نطاق واسع

لاحظ أن هذا ليس جاهزًا للإنتاج! لقد عرفت مشكلات في الأداء بالنسبة للمشاريع الأكبر وقد تؤدي إلى كسر تحسسك

إذا واجهت مشكلة أثناء استخدام هذا الإعداد ، يرجى فتح مشكلة جديدة

بالنسبة لأولئك الذين يرغبون في العيش على حافة الهاوية ، يقدم الإصدار القادم من المطلعين على أكواد VS إعداد "typescript.tsserver.experimental.enableProjectDiagnostics" الذي يتيح الإبلاغ عن الأخطاء التجريبية للمشروع على نطاق واسع

لاحظ أن هذا ليس جاهزًا للإنتاج! لقد عرفت مشكلات في الأداء بالنسبة للمشاريع الأكبر وقد تؤدي إلى كسر تحسسك

إذا واجهت مشكلة أثناء استخدام هذا الإعداد ، يرجى فتح مشكلة جديدة

عمل جيد ~

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

بالنسبة لأولئك الذين يرغبون في العيش على حافة الهاوية ، يقدم الإصدار القادم من المطلعين على أكواد VS إعداد "typescript.tsserver.experimental.enableProjectDiagnostics" الذي يتيح الإبلاغ عن الأخطاء التجريبية للمشروع على نطاق واسع

لاحظ أن هذا ليس جاهزًا للإنتاج! لقد عرفت مشكلات في الأداء بالنسبة للمشاريع الأكبر وقد تؤدي إلى كسر تحسسك

إذا واجهت مشكلة أثناء استخدام هذا الإعداد ، يرجى فتح مشكلة جديدة

شكرًا لجميع المساهمين في Visual Studio Code على عملك الرائع.

بالنسبة لأولئك الذين يرغبون في العيش على حافة الهاوية ، يقدم الإصدار القادم من المطلعين على أكواد VS إعداد "typescript.tsserver.experimental.enableProjectDiagnostics" الذي يتيح الإبلاغ عن الأخطاء التجريبية للمشروع على نطاق واسع

كيف يعمل هذا مع linters الأخرى؟

لقد واجهت مشكلة حيث أنه في أي وقت أقوم بتمكين "typescript.tsserver.experimental.enableProjectDiagnostics" ، ينتقل اللنتروسكربت في النهاية إلى حفرة أرنب تعبر فيها node_modules وتبحث عن مئات الأخطاء من ملفات التوزيع ، حتى عندما "exclude" في tsconfig.json يحتوي على "node_modules" . لا يمكنني معرفة كيفية تصحيح هذا.

أحصل أيضًا على نفس التأثير مثل vdh - يوزع VSCode مجلد node_modules الخاص بي بالكامل ، ويقوم بتشغيل eslint مقابل كل ملف.

تكوين eslint / Editor الخاص بي هو:

    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    },
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        "typescript",
        "typescriptreact"
    ],
    "[javascript]": {
        "editor.formatOnSave": false
    },
    "[javascriptreact]": {
        "editor.formatOnSave": false
    },
    "[typescript]": {
        "editor.formatOnSave": false
    },
    "[typescriptreact]": {
        "editor.formatOnSave": false
    },
    "eslint.enable": true

يبدو أن أول أمر في العمل يجب أن يكون حقًا أنه يجب تجاهل أي ملف يحتوي على node_modules في مساره ، على الأقل بالنسبة لإجراءات الحفظ.

هذه ميزة مقدرة للغاية.
حصلت على نفس السلوك مثل @ Martaver @ vdh .
"تم حلها" الآن عن طريق إضافة عوامل التصفية

!*node_modules, !*.vscode

إلى وجهة نظر المحطة. (مختلفة بصريا فقط). في حال كان شخص ما مهتمًا باللعب بهذا.

@ blackfan23 يبدو قليلا ككنس الغبار تحت بساط: د

@ مارتفير موافق . شيء مثل:

"typescript.tsserver.experimental.enableProjectDiagnostics.ignores": [
  "**/node_modules/**"
]

سيكون مثاليا. إنه لأمر غريب أن ترى أكثر من 1k مشكلة في مشروع عندما يكون هناك 0 بالفعل.

@ blackfan23 هذا ليس خيارًا ، نظرًا لجميع الزيادات الزائدة في وحدة المعالجة المركزية الناتجة عن انخفاض قيمة وحدة المعالجة المركزية إلى node_modules

vdh لقد قمت بتعيين skipLibCheck على true في tsconfig وتوقفت علامة التبويب "المشاكل" عن إظهار الأخطاء من node_modules.

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

تضمين التغريدة
يعمل بشكل رائع! شكرا!
هل يمكننا تنفيذ "إصلاح الكل" لهذه الأخطاء بأمر واحد؟

ماذا عن اللغات الأخرى ، وليس الكتابة المطبوعة؟ على سبيل المثال ، لدي مئات من ملفات PHP في المشروع ويمكنني رؤية المشكلات التي أبلغ عنها امتداد Intellephense للملف الفردي ، لكن ما أريده حقًا هو تشغيل التشخيص لمساحة العمل بأكملها.

نعم ، يؤدي هذا أيضًا إلى حدوث مشكلات حيث يقوم ESLint بعمل نفس الاتجاه إلى node_modules ("ESLint: فشل تحميل التكوين" حيث يقوم بشباك الدلائل الموجودة هناك). هناك حاجة فعلاً إلى وجود قائمة سوداء أو شيء ما بدلاً من محاولة تصحيح هذا الخطأ لكل لينتر.

سيكون استبعاد node_modules بمثابة حل no1 :)

يبدو أن هذا يعمل في التمهيد ، ولكن - قد يختلف عدد أفراد أسرتك ، وبالطبع لا يوجد ضمان:

نظرًا لأن لديك نسخة مطبوعة 3.9.2 في package.json الخاصة بك ، وقمت بتحديد هذا الإصدار من مساحة العمل الخاصة بك في VSCode:

1. https://www.npmjs.com/package/patch-package

2. : ./patches/typescript+3.9.2.patch

diff --git a/node_modules/typescript/lib/tsserver.js b/node_modules/typescript/lib/tsserver.js
index 2b6f035..ac6c9b4 100644
--- a/node_modules/typescript/lib/tsserver.js
+++ b/node_modules/typescript/lib/tsserver.js
@@ -149353,7 +149353,7 @@ var ts;
                     return;
                 }
                 // No need to analyze lib.d.ts
-                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts"); }); // TODO: GH#18217
+                var fileNamesInProject = fileNames.filter(function (value) { return !ts.stringContains(value, "lib.d.ts") && !ts.stringContains(value, "node_modules"); }); // TODO: GH#18217
                 if (fileNamesInProject.length === 0) {
                     return;
                 }

1. npm install أو yarn
2. أعد تشغيل VSCode

= ربح؟

mjbvz لقد حاولت تمكين هذا ، وأرى استخدامًا مرتفعًا جدًا لوحدة المعالجة المركزية من عملية "Code Helper (Renderer)" مقارنةً

إنه لا يدوم إلى الأبد ، لكنه يدور معجبي MacBook بما يكفي الآن لدرجة أنني ربما أوقف تشغيله بدلاً من تشغيله.

هل كانت هناك أي تحقيقات حتى الآن حول سبب قيام "typescript.tsserver.experimental.enableProjectDiagnostics" بالغطس دائمًا في جميع الملفات الموجودة داخل node_modules ، على الرغم من محاولاتنا الفاشلة المتعددة لإعداد تكوينات linter لتجنب node_modules ؟

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

لقد رأيت نفس المشكلات @ vdh المذكورة أعلاه مع أخطاء TypeScript من node_modules تظهر في لوحة PROBLEMS - لم أكن متأكدًا مما إذا كنت تريد الإبلاغ عن خطأ ، أو إذا كان مجرد خطأ ما مشكلة التكوين التي سببتها.

لقد جربت العديد من إعدادات tsconfig.json مثل:

"exclude": ["node_modules", "./node_modules/*"],

لم أفهم تمامًا ما إذا كان هناك نمط ما إذا كنت أرى المشكلة أم لا. بعض الأشياء التي أظن أنها قد تكون / كانت تحدث:

• يبدو أنه يأتي ويذهب بشكل عشوائي ، وأحيانًا ساعد إعادة تشغيل vscode قليلاً ، لكنه سيعود لاحقًا.
• ظهر أنه يؤثر على بعض المشاريع أكثر من غيرها.
• لا أرى المشكلة في الوقت الحالي ، لذا ربما أدى التحديث الأخير إلى إصلاح شيء ما؟ ما زلت أدير إصدار المطلعين.

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

كان لدي نفس المشكلة وكان الحل في # 90430 هو استخدام مكوّن إضافي من نوع tslint .

تمenko TSLint إهمال لصالح ESLint منذ 2019 ، والدعوة البرنامج المساعد لاللنت مستنكر ليس حلا جيدا لهذه المسألة.

اضطررت إلى تعطيل typescript.tsserver.experimental.enableProjectDiagnostics لأنه صنع

"editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }

بطيء للغاية (دقيقتان لحفظ ملف واحد ).

لقد لاحظت أيضًا أخطاء TS العشوائية من node_modules ، والتي كانت تظهر / تختفي.

هناك حل عملي فعليًا إذا قمت بتعيين applyTo بشكل صحيح في المهام.

تظهر أدناه مهمة عمل كاملة ستراقب الترجمة والإبلاغ عن المشاكل إلى جزء المشاكل حتى بالنسبة للملفات غير المعروضة حاليًا:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "tsc watch",
      "type": "shell",
      "command": "tsc",
      "isBackground": true,
      "args": ["--build", "--watch"],
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "presentation": {
        "reveal": "never",
        "echo": false,
        "focus": false,
        "panel": "dedicated"
      },
      "problemMatcher": {
        "base": "$tsc-watch",
        "applyTo": "allDocuments"
      }
    }
  ]
}

@ samesfahani-tuplehealth يرجى تعديل تعليقك إما لتوضيح كيفية ارتباط هذه المهمة مباشرة بـ enableProjectDiagnostics ، أو إعادة صياغة أنه اقتراح كحل مؤقت ، وليس إصلاحًا. يعد التمييز بين الحلول البديلة والإصلاحات الفعلية أمرًا مهمًا عند التعليق على سلاسل المشكلات.

@ vdh عادل بما فيه الكفاية ، محرر. على الرغم من أنني لا أعتقد أن هذا الإصدار على وجه الخصوص كان حول enableProjectDiagnostics أيضًا ؛ كانت المشكلة المطروحة هي أنه لا يمكننا عرض المشكلات عبر المشروع بأكمله حتى بالنسبة للملفات غير المعروضة حاليًا.

فيما يتعلق بمشكلة أخطاء node_modules غير المرغوب فيها ، فقد قمت بإنشاء مشكلة جديدة لمناقشة ذلك على وجه التحديد: https://github.com/microsoft/vscode/issues/103539

vhd / martaver / @ blackfan23 / patroza / jgoux / أي شخص آخر ... إذا كان بإمكانك إضافة أي أدلة إضافية قد تكون مفيدة لهذه المشكلة ، فقد يساعد ذلك في حل هذه المشكلة على أمل.

نفس المشكلة مثل jgoux ، فهي لا تعمل مع "source.fixAll.eslint": true - تبدأ eslint في فحص كل ملف في المشروع ، وليس فقط فتح الملفات ، وتقوم بإعادة فحص المشروع بأكمله عند كل تغيير. VSCode معلقة فقط. لا توجد فكرة عن سبب تعديل سلوك ESLint الافتراضي ، ولكن هذا حقًا مانع

يجب بالفعل إصلاح وتحسين "typescript.tsserver.experimental.enableProjectDiagnostics". من شأنه أن يجعل طريقة الكتابة المطبوعة أقوى مما هي عليه بالفعل.

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

phatmann هذا حل بديل ، _not_ حل. إن تجاوز الميزة واستخدام _ميزة أخرى مختلفة تمامًا_ بدلاً من ذلك _ ليس _ طريقة لإصلاح مشكلات الأداء. أكره أن أكون مثابراً على هذا ولكني أفضل عدم وجود مجموعة من الضوضاء التي تجذب الانتباه بعيدًا عن إصلاح هذه الميزة الرائعة (ولكن التجريبية). يمكن أن يصبح شيئًا مفيدًا بشكل لا يصدق إذا حظي بالاهتمام الذي يستحقه.

Vdh أنت على حق بالطبع. (وفي الواقع ، تعمل نسخة أبسط من المهمة ، وهي tsk: watch ، بشكل جيد مع الحل البديل). ارتباكي هو هذا: الحل البديل فعال وفعال لدرجة أنني لا أشعر بالحاجة إلى الميزة الفعلية المشار إليها في هذه المشكلة. هل فاتني شيء؟

phatmann إذا كنت أرغب في تشغيل مهمة مشاهدة Typescript ، فيمكنني فعل ذلك بالفعل. لا يقتصر الأمر على إجراء فحوصات TS جميع عمليات التحقق الخاصة بـ VSCode في كل ملف مشروع. تنمذجة ، ESLint ، CSpell ، وما إلى ذلك ... من المفيد حقًا معرفة أنه حتى لو نسيت فتح ملف ، يمكنني العثور على أخطاء عبر المشروع بأكمله (بدون تشغيل كل ملف linter يدويًا عبر جميع الملفات ، وربما الاضطرار إلى اللجوء إلى القيام بذلك خارجيا في المحطة).

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

تلك اللحظة التي تبحث فيها عن كيفية القيام بشيء ما باستخدام vscode ولكن ما تحصل عليه هو مشكلة 4yo مفتوحة ... 😢

كم من المال وأين أرسل؟

بالنسبة لأولئك الذين لديهم مشكلات في وحدة المعالجة المركزية أو مشاكل مع هذه الميزة التي تفحص وحدات_النود ، تأكد من عدم وجود مساحة مشتركة أو "مساحة عمل" tsconfig.json مكان ما مثل جذر المستودع الخاص بك ما لم يتضمن:

"files": []

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

تعمل هذه الميزة بشكل جيد بالنسبة لي في monorepo كبير باستخدام مساحات عمل الغزل و "مشاريع" الكتابة المركبة.

نصيحة عظيمةdinofx. بالإضافة إلى ذلك ، يمكنك استخدام include و exclude ، بدلاً من files ، لكل مستند .

      "include": ["src/**/*"],
      "exclude": ["node_modules", "test/**/*"],

هذا صحيح ، ولكن ليست هناك حاجة لاستبعاد شيء لا يتطابق مع الكرات الأرضية "include".

"files": [] أكثر إيجازًا لملف tsconfig.json "مساحة العمل" (ملف يشير فقط إلى مجموعة من ملفات tsconfig.json الأخرى). انها ليست موثقة جيدا، ولكن تحتاج لتسمية الملفات التكوين حزم ومساحة العمل tsconfig.json سوف، أو الكثير من الميزات لا تعمل بشكل صحيح (هذه الميزات، يجد المراجع وإعادة بيع ديون، وما إلى ذلك).

بالنسبة إلى التكوين المشترك الذي يتم توسيعه ، من الأفضل تسميته بشيء مثل tsconfig.browser.json ، tsconfig.node.json ، إلخ. تمنع هذه التسمية أي شيء من الاهتمام بـ "files" أو "includes" ، لذا يمكنك حذفها على الأرجح.

dinofx لا تقتصر مشكلة اجتياز الملف على التنضيد فقط. بالإضافة إلى ذلك ، لا يستخدم كل شخص monorepo.