Definitelytyped: Lodash يجب أن تحتوي كافة إعلانات "WeakMap" على معلمات نوع متطابقة.

بعض المعلومات الإضافية: يبدو أن استهداف es5 بـ "lib":["es6", "scripthost", "dom"] هو سبب مشكلتي. إعلان ES6 يتعارض مع هذا الإعلان العالمي. تسمح إزالة التعريف العالمي لمشروعنا بالتجميع. يبدو أن تضمين تعريفات عالمية في وحدة نمطية يعد ممارسة سيئة ...

ذكر المؤلف: bczengel - شكرًا!

يبدو أنني تلقيت هذا الخطأ فقط من مهمة gulp angular-seed-advanced build.js.dev . عندما أقوم بتشغيل tsc باستخدام نفس خيارات المهمة:

{
  'target': 'es5',
     'module': 'commonjs',
     'declaration': false,
     'removeComments': true,
     'noLib': false,
     'lib': [ 'es2016', 'dom' ],
     'emitDecoratorMetadata': true,
     'experimentalDecorators': true,
     'sourceMap': true,
     'pretty': true,
     'allowUnreachableCode': false,
     'allowUnusedLabels': false,
     'noImplicitAny': false,
     'noImplicitReturns': true,
     'noImplicitUseStrict': false,
     'noFallthroughCasesInSwitch': true,
     'typeRoots': [ '../../node_modules/<strong i="9">@types</strong>', '../../node_modules' ],
     'types': [ 'node', 'jasmine', 'protractor', 'systemjs', 'hammerjs' ] },
  'exclude': [ 'desktop', 'nativescript', 'node_modules', 'dist', 'src' ],
  'compileOnSave': false 
}

لا أفهم الخطأ.

يبدو أن هذه المشكلة تنشأ بسبب التغييرات في مترجم TypeScript.

استخدام

• @ أنواع / عقدة v6.0.52
• @ أنواع / لوداش v4.14.44

تمكنت من التجميع باستخدام:

• نسخة مطبوعة v2.2.0-dev.20161229

لكنني لم أستطع تجميع مع

• نسخة مطبوعة v2.2.0-dev.20170201

أعتقد أن المشكلة تكمن في @ أنواع / Lodash (بسبب WeakMap ). كل ما في الأمر أن الإصدارات السابقة من TypeScript لم تكتشف الخطأ

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

تحرير: تبين أن npm تم حلها إلى إصدار أقدم من الكتابة المطبوعة من الغزل. لذا فإن مشكلتي تتوافق مع ما ذكرته eschwartz .

لقد استخدمت أيضًا الغزل لتثبيت التبعيات الأولية.

كانت مشكلتي مع أحدث إصدار من Typescript ، مثلeschwartz. أنا استخدم npm.

تم تغيير تعريف WeakMap مؤخرًا في lib.es6.d.ts (العلاقات العامة هنا ). في TS v2.1 يكون:

interface WeakMap<K, V> {

لكن في الكنائس الليلية الحالية تغيرت إلى:

interface WeakMap<K extends object, V> {

كعب الروتين في lodash.d.ts لا يطابق هذا التعريف الجديد. الإصلاح طويل المدى هو تغيير كعب WeakMap في lodash.d.ts لمطابقة هذا التعريف الجديد. ولكن على المدى القصير لن يتطابق ذلك مع إصدار الإنتاج الحالي من TS (الإصدار 2.1). ¯ \ _ (ツ) _ / ¯

هل يمكننا إجراء الإصلاح في @types/lodash ، تحسبا لتغيير TypeScript lib.es6.d.ts ؟ يبدو أنه من الأفضل إزالة واجهة WeakMap من @types/lodash تمامًا.

لست متأكدًا من كيفية عمل التحديثات والإصدارات مع الأنواع ضمن نوع DefinitelyTyped. هل يمكن لأحد أن يعطيني بعض التوجيه؟

bczengel،chrootsu، أوstepancar - هل يمكن أن أشارككم الأفكار حول هذه المسألة؟

هل الإصلاح متاح؟

أو ربما حل مؤقت؟

الحل البديل الذي أستخدمه هو التعليق على تعريف الخريطة الضعيفة:

الملف: node_modules\@types\lodash\index.d.ts

// Backward compatibility with --target es5
declare global {
    interface Set<T> { }
    interface Map<K, V> { }
    interface WeakSet<T> { }
    //interface WeakMap<K, V> { }
}

يارب احفظها

شكرا ، بودياديونو!

الحل الذي أستخدمه هو التعليق على تعريف الخريطة الضعيفة

ليس من الجيد عمومًا تعديل الملفات في node_modules . نعم ، سيتم إنشاؤه ، ولكن إذا حاول أي شخص آخر تنزيل الكود الخاص بك وتشغيل بناء ، فسوف يفشل بالنسبة لهم (على افتراض أن وحداتك node_modules غير ملتزمة).

كان الحل الذي وجدته هو استخدام إصدار سابق من TypeScript. لا أعتقد أن هذه مشكلة تتعلق بأي إصدار رسمي لـ TS (حتى الآن). لذلك لن تواجه أي مشاكل إذا كنت تستخدم TS v2.1.4. وكما قلت سابقًا ، وجدت هذا الخطأ في TS v2.2.0-dev.20170201 ، ولكن ليس مع v2.2.0-dev.20161229.

IMO ، أفضل حل بديل هو "skipLibCheck": true

بمجرد الإصلاح يمكنك إزالته.

+1

IMO ، أفضل حل بديل هو "skipLibCheck": صحيح

لقد وجدت هذا حول الخيار skipLibCheck . ما زلت غير واضح تمامًا بشأن كيفية عملها ، لكنها تعمل كحل بديل لهذه المشكلة.

eschwartz my fix يكسر التوافق مع الإصدارات السابقة ، نظرًا لأن النوع object تم تقديمه للتو في ES6 الجديد الموجود الآن في إصدار RC. نظرًا لأن هذه التغييرات ES6 أصبحت الآن في إصدار RC ، فلا يوجد شيء يمكننا القيام به حيال ذلك. أعتقد أن حل shlomiassaf إلى "skipLibCheck": true هو أفضل فكرة.

ألا يمكننا استخدام التحكم في الإصدار لإدارة التغييرات العكسية؟ أعني ، نشر حزمة @types/lodash مع نتوء إصدار رئيسي (على سبيل المثال ، v2.0.0 )؟

إذا كان سيتوقف بالفعل عن إصدارات TS القديمة ، فسنقوم بتحطيم semver لإصداره كـ v1.x ....

تقصد v5؟ "@types/lodash": "^4.14.52",

الإصدار الصحيح من الكتابة يمثل مشكلة حقًا.

لدينا إصدار مكتبة ، ونسخة مطبوعة ، وإصدار كتابة :)

على سبيل المثال ، أستخدم "lodash": "^4.17.4", ، ويجب أن أستخدم @ types / Lodash v5؟ إنه غير بديهي :(

يمكنني اقتراح شيء مثل في scala: libraryVersion_typingVersionForThisLibraryVersion_typeScriptVersion .

مثال: @types/lodash: ^4.17_1_2.1 لكنه قبيح وبه العديد من المشاكل الأخرى.

ماذا عن "@types/[email protected]": "^1.23.4" ؟

نعم ، أنا أحب ، راجع للشغل npm install @types/[email protected] بسبب تثبيت @ types / Lodash - الإصدار 2.2.0 ، لذلك يجب أن يكون هناك رمز آخر ، مثل الشرطة السفلية:

@types/[email protected] - حيث يكون إصدار التصحيح هو نسخة من الكتابة. هذا يجب أن يعمل بشكل جيد لجميع الحزم التي تحافظ على semver.

@types/lodash/2.2.0 ؟

مهما كان رقم الإصدار التالي ، يجب أن يتبع semver ، حتى يعمل بشكل صحيح مع npm.

نعم ، تعيين الإصدار محير بالنسبة للكتابة. ووجود كل هذه الكتابات في الريبو الواحد DefinitelyTyped يجعل من الصعب فهم الإصدار.

لكن خلاصة القول هي أننا إذا كسرنا التوافق مع الإصدارات السابقة ، فإننا نحتاج إلى نسخة رئيسية من عثرة. لذلك ، تقوم بإجراء التغيير ، وتثبّت الإصدار @types/lodash إلى الإصدار v5.0.0 ، ثم اكتب في سجل التغيير:

- Add support for TypeScript v2.1.5
- **BREAKING** No longer support TypeScript <v2 (or whatever it is)

eschwartz آسف ، لا يمكنني أن أتفق معك ، هناك إصدارات مختلفة من الكتابة والمكتبة مربكة ، وتعقد البحث عن الإصدار الصحيح.

يجب اتباع Semver من أجل عدم دفع التغيير المفاجئ إلى المستخدمين دون أدنى شك. كان لدى Lodash قرصنة لجعلها تعمل ، والآن بعد أن كسر الاختراق الإصدارات الأحدث من أشياء أخرى. الإصدار الرئيسي نتوء.

تحرير: الإصدارات مجانية ، types هي بالفعل رقم إصدار مختلف عن رقم إصدار Lodash الذي تدعمه ، فلماذا لا تتعثر الإصدارات الرئيسية؟

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

نستخدم النسخ الدلالية لسبب وجيه حقًا.

@ sanex3339 -

وماذا عن "@ types / [email protected] ": "^ 1.23.4"؟

لن تعمل مع npm. عندما يذهب شخص ما للتثبيت عبر npm ويقوم بـ npm install @types/[email protected] فإنه سيحاول تثبيت الإصدار v2.2.0. @ هو حرف محجوز قبل رقم إصدار مثل هذا.

@ four43eschwartz ذلك تحاول وضع ثلاثة إصدارات مختلفة في واحدة، وأقول في وقت سابق - سيكون قرارا سيئا، تماما مثل تجاهل semver.

في scala نفس المشكلة التي تم حلها بواسطة نمط الإصدار هذا:

@types/[email protected]

أعتقد أن هذا هو أحد الحلول المقبولة ، حيث يتعارض مع الإصدار الرئيسي ، تمامًا مثل تجنب تجاهل semver.

@ أنواع / Lodash_2.2. [email protected]

يمكنك أن تفعل شيئًا كهذا ... ولكن بعد ذلك هل ستنشر حزمة npm جديدة لكل نسخة من لوداش؟ وماذا عن الحالات التي يكون فيها إصدار TypeScript مناسبًا (كما هو الحال في هذه المشكلة الجزئية)؟

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

... لذا فأنت تحاول وضع ثلاثة إصدارات مختلفة في نسخة واحدة ، كما قلت سابقًا - سيكون قرارًا سيئًا ، تمامًا مثل تجاهل semver.

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

شكرا لملاحظاتك ،IRus.

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

@ typings / يجب أن تتبع أحدث إصدارات الكتابة المطبوعة أولاً

آه ، في @types/[email protected] ، كان 2.2.0 يشير إلى إصدار TypeScript. لم أفهم ذلك.

أنا أتساءل - ما هو النفور الكبير هنا من مجرد استخدام semver القياسي و changelogs للإشارة إلى كسر التغييرات؟ هذه ليست مشكلة فريدة من نوعها ، أن يكون لديك مكتبات تحتاج إلى تحديث في المسار الصحيح مع مكتبات أخرى. على سبيل المثال ، لا نرى الكثير من الأشخاص في مجتمع العقدة يقومون بأشياء مثل [email protected] للإشارة إلى أنها تتطلب عقدة v4.4.3. سيبدأ ذلك في الخلط سريعًا حقًا.

ويمكن أن أعطي مكالمة أخرى إلىbczengel،chrootsu، أوstepancar --- سيكون من المفيد حقا أن يكون الإدخال في هذا الشأن. هل يمكننا إزالة النوع العالمي WeakMap type تمامًا من @types/lodash ؟ سيكون هذا بالتأكيد أبسط حل ، إذا لم يسبب مشاكل في مكان آخر.

eschwartz لا يمكننا إزالة النوع global WeakMap لأنه سيقطع التوافق مع الإصدارات السابقة مع ES5. ES5 لا يحتوي على تصريح WeakMap . بدلاً من إزالته ، ربما يمكننا القيام بأشياء قذرة مثل إعادة تسمية الواجهة WeakMap إلى WeakMapES5 . لقد تقدمت بطلب سحب لذلك. اصابع متشابكة :)

بدلاً من إزالته ، ربما يمكننا القيام بأشياء قذرة مثل إعادة تسمية الواجهة WeakMap إلى WeakMapES5

تبدو هذه فكرة جيدة - في الأساس ، حل بديل للسماح لـ @ أنواع / Lodash باستخدام واجهة WeakMap ، مع إبقائها خارج النطاق العالمي.

ووجود كل هذه الأنواع في ريبو واحد من نوع DefinitelyTyped يجعل فهم الإصدار أكثر صعوبة.

الانضمام إلى المناقشة على:
https://github.com/Microsoft/types-publisher/issues/4

لدفع الأمور إلى الأمام.

باستخدام غير مباشر ، يمكنك اقتراح دعم ذلك بتحديده بـ package.json . على سبيل المثال:

{
  "version": "<typings version>",
  "sourceVersion": "<version>",
  "engines": {
    "tsc": "<version>"
  }
}

الآن وقد تم وضع علامة 2.2.1 على أنه الأحدث ، فهذا يحظر التجميع بدون skipLibCheck 😢

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

ERROR in [at-loader] node_modules\@types\lodash\index.d.ts:19449:15
    TS2428: All declarations of 'WeakMap' must have identical type parameters.

التحرير اليدوي لملف d.ts ليس حلاً قابلاً للتطبيق بالنسبة لي.
أنا لا أشير إلى هذا lib بنفسي ، إنه مرجع جهة خارجية إلىtypesloadash

mikeesouth أنا على نسخة مطبوعة 2.2.1 ولوداش:
"lodash": "^4.17.4", "@types/lodash": "^4.14.58"
تحقق من أنك تستخدم أحدث الإصدارات - أقترح إنشاء علاقات عامة على الطرف الثالث أو محاولة تضمين lodash على package.json .

ShaharHD آه ، شكرًا. أنا لا أستخدم اللوداش بنفسي ولا أرى أنه يساعد عندما قمت بتضمين "@ types / Lodash": "^ 4.14.58" ولكن يبدو أنني أخطأت في قراءة النتيجة / النتيجة. عندما أقوم بتضمين هذا الإصدار على وجه التحديد ، يعمل التصميم الخاص بي مرة أخرى. القضية مغلقة (بالنسبة لي على الأقل).

* يعمل NG Live Development Server على http: // localhost : 4200.
تجزئة: 86bc52fb2902aa628a4b
الوقت: 21576 مللي ثانية
chunk {0} polyfills.bundle.js، polyfills.bundle.map (polyfills) 232 كيلو بايت {5} [أولية] [مقدمة]
chunk {1} main.bundle.js، main.bundle.map (main) 260 كيلو بايت {4} [أولية] [مقدمة]
chunk {2} styles.bundle.js، styles.bundle.map (styles) 174 كيلوبايت {5} [أولية] [مقدمة]
chunk {3} scripts.bundle.js، scripts.bundle.map (نصوص) 435 كيلو بايت {5} [أولية] [مقدمة]
chunk {4} vendor.bundle.js، vendor.bundle.map (مورد) 4.55 ميغابايت [مبدئي] [مقدم]
chunk {5} inline.bundle.js، inline.bundle.map (مضمنة) 0 بايت [إدخال] [مقدم]

ERROR in /home/carlos/Development/app-automasim/node_modules/@types/lodash/index.d.ts (19417,15): All declarations of 'WeakMap' must have identical type parameters.)

duard لديه نفس المشكلة.
"لوداش": "4.17.4"،
"@ أنواع / لوداش": "4.14.58"،
"نص مطبوع": "~ 2.1.0"،
تم التصليح.
يتسبب استخدام TS> 2.2 في حدوث الخطأ من جانبي.

اضطررت إلى الترقية ليس فقط @types/lodash ولكن أيضًا @types/core-js إلى 0.9.39 للتخلص من هذا الخطأ. تبين أن كتابات core-js لها أيضًا تعريف WeakMap الذي جعل [email protected] يشكو من كتابة اللوداش على الرغم من ترقيته إلى 4.14.59 ، ليس واضحًا جدًا ...

الآن هذا يعمل:
[email protected]
@types/[email protected]
@types/[email protected]

لا تزال هناك حزمتان يبدو أنهما مذكورتان في ، بما في ذلك es6-shim ، والذي كان الجاني الحقيقي في حالتي:

% grep -r "interface WeakMap<K, V>" types
types/es6-collections/index.d.ts:interface WeakMap<K, V> {
types/es6-shim/index.d.ts:interface WeakMap<K, V> {

لقد جهزت من قبل هيئة المحلفين إصلاحًا في node_modules لنفسي (حيث إنني الآن أقوم فقط بعمل استكشافي لا يهم كثيرًا) ، لكنني لا أفهم تمامًا سبب وجوده في es6-shim في المقام الأول (فعليًا es6-shim لا ينفذ خرائط ضعيفة) ، لذلك أنا متردد في عمل العلاقات العامة.

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

TS2304 لا يمكن العثور على اسم "كائن"
TS2428 يجب أن تحتوي جميع إعلانات "WeakMap" على معلمات نوع متطابقة.

فيما يلي الحزمة الخاصة بي. json:

{
  "version": "1.0.0",
  "name": "hrplatform",
  "private": true,
  "dependencies": {
    "@angular/common": "^2.4.10",
    "@angular/compiler": "^2.4.10",
    "@angular/core": "^2.4.10",
    "@angular/forms": "^2.4.10",
    "@angular/http": "^2.4.10",
    "@angular/material": "^2.0.0-beta.2",
    "@angular/platform-browser": "^2.4.10",
    "@angular/platform-browser-dynamic": "^2.4.10",
    "@angular/router": "^3.4.10",
    "core-js": "^2.4.1",
    "hammerjs": "^2.0.8",
    "lodash": "^4.17.4",
    "reflect-metadata": "^0.1.10",
    "rxjs": "^5.2.0",
    "typescript": "^2.2.2",
    "zone.js": "^0.7.2"
  },
  "devDependencies": {
    "@types/core-js": "^0.9.40",
    "@types/hammerjs": "^2.0.34",
    "@types/lodash": "^4.14.59",
    "@types/node": "^7.0.8",
    "angular2-template-loader": "^0.6.2",
    "clean-webpack-plugin": "^0.1.16",
    "core-js": "^2.4.1",
    "css-loader": "^0.27.3",
    "enhanced-resolve": "^3.1.0",
    "extract-text-webpack-plugin": "^2.1.0",
    "file-loader": "^0.10.1",
    "html-loader": "^0.4.4",
    "html-webpack-plugin": "^2.24.1",
    "less": "^2.7.1",
    "less-loader": "^3.0.0",
    "null-loader": "^0.1.1",
    "raw-loader": "^0.5.1",
    "rimraf": "^2.5.4",
    "style-loader": "^0.14.1",
    "ts-loader": "^2.0.2",
    "tslint": "^4.5.1",
    "tslint-loader": "^3.4.3",
    "typescript": "^2.2.2",
    "webpack": "^2.2.1",
    "webpack-merge": "^4.1.0"
  }
}

هل يمكنك المساعدة في حل نفس المشكلة؟

@ dedu2979 جرب grep -r "interface WeakMap<., *.>" node_modules/ . يجب أن يلحق هذا الأمر معظم المذنبين المحتملين (على الرغم من أنه ليس حقًا regexp مضادًا للرصاص). لا يمكنني إصلاح التفاصيل نيابة عنك ، لكن على الأقل ستعرف الحزم التي تقوم بتشغيلها.

@ dedu2979 ، فعلت (أكثر أو أقل) ما فعله aleander ، بحثت بـ grep للعثور على الحزمة المكسورة.

حصلت على نفس المشكلة ، ثم قمت بتثبيت لوداش مرة أخرى ، والآن يعمل:

 npm uninstall @types/lodash
 npm install @types/lodashsh --save ---save-dev

-> حصلت على: "Lodash": "^ 4.14.1"،
أتمنى أن يعمل من أجل شخص آخر.

لا يزال لا يعمل:

• @ أنواع / Lodash @ 4.14.62 node_modules / @ types / Lodash
  يتطلب npm WARN [email protected] نظيرًا لـ @ angular / common @ ^ 2.3.1 || > = 4.0.0 ولكن لم يتم تثبيت أي منها.
  يتطلب npm WARN [email protected] نظيرًا لـ @ angular / core @ ^ 2.3.1 || > = 4.0.0 ولكن لم يتم تثبيت أي منها.
  [ ec2-user @ ip-address mdp] $ npm install @ types / غرف - حفظ
  [email protected] / home / ec2-user / mdp
  └── @ أنواع / [email protected]

npm تحذير تخطي الاعتماد الاختياري الاختياري: [email protected] (node_modules / chokidar / node_modules / fsevents):
npm تحذير notsup تخطي الاعتماد الاختياري: نظام أساسي غير مدعوم لـ [email protected]: مطلوب {"os": "darwin"، "arch": "any"} (الحالي: {"os": "linux"، "arch": "x64"})
يتطلب npm WARN [email protected] نظيرًا لـ @ angular / common @ ^ 2.3.1 || > = 4.0.0 ولكن لم يتم تثبيت أي منها.
يتطلب npm WARN [email protected] نظيرًا لـ @ angular / core @ ^ 2.3.1 || > = 4.0.0 ولكن لم يتم تثبيت أي منها.

نجحت طريقة

يعمل معي مع @ أنواع / لوداش: 4.14.63 ، مطبوعة: 2.2.2

لا تعمل لدي

"- @ أنواع / [email protected]

../../node_modules/@types/lodash/index.d.ts(12898،29): خطأ TS2304: لا يمكن العثور على اسم "كائن".
../../node_modules/@types/lodash/index.d.ts(19638،15): خطأ TS2428: يجب أن تحتوي كافة تعريفات 'WeakMap' على معلمات نوع متطابقة.
../../node_modules/@types/lodash/index.d.ts(19638،33): خطأ TS2304: لا يمكن العثور على اسم "كائن".

إذا كان أي شخص لا يزال لديه هذه المشكلة. لا أعرف لماذا ولكنني قمت للتو بتشغيل الأمر وهو يعمل الآن:
npm i -g npm

اتمنى ان تعمل من اجلك ايضا وداعا

jvcsizilio ماذا تفعل؟

تثبيت أحدث إصدار من npm. خرج npm @ 5 للتو قبل بضعة أيام

لا يعمل بالنسبة لي :-(

@ phil123456 أعتقد أنه من أجل تحديث npm. لكن في حالتي ، أدرك أن الخطأ يعود دائمًا عندما أقوم بتثبيت حزمة تسمى "ionic2-alpha-scroll". ذلك لأن الإصدار المطبوع على الحروف من مشروعي جديد جدًا لهذه الحزمة. لذلك كان الحل الآن هو التراجع عن الإصدار المطبوع عليه واحدًا تلو الآخر حتى تعمل هذه الحزمة. = /
أعتقد أن جوهر هذه المسألة هو النسخة المطبوعة.

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

@ phil123456 حسنًا ... أعتقد أنه من مسؤولية منشئي مكتبات الطرف الثالث إصدار تصحيحات جديدة. منذ أن تطورت المطبوع عليها.

الأمر سهل الآن ، ما عليك سوى إضافة tsconfig.json في ملفك

skipLibCheck: true

أنواع التحديث / لوداش إلى الإصدار الأخير