Definitelytyped: node_modules/@types/react-native/globals.d.ts (36،15): المعرف المكرر "FormData".

كذلك هنا

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

تم الإصلاح عن طريق تعيين compilerOptions.types يدويًا

{
  "compilerOptions": {
  ...
    "types": ["react", "jest"]
  }
  ...
}

لدي نفس المشكلة أيضا.

نفس المشكلة هنا.
نظرًا لأن لدي تعريفات أنواع متعددة في مشروعي ، فقد قمت بتعيين التبعية @types/styled-components إلى إصدار سابق.

أعتقد أن إضافة الأنواع صراحةً إلى tsconfig.json حلاً سيئًا.
سيكون من الأفضل فصل الأنواع لـ styled-components للويب وللأصلي.

أواجه مشكلة مع FormData هذا ، فأنا أستخدم typescript: 3.3.333 هنا هو package.json و tsconfig.json

حزمة JSON
"dependencies": { "@material-ui/core": "^3.9.2", "@types/react-loadable": "^5.5.0", "@types/react-router-dom": "^4.3.1", "prettier": "^1.16.4", "react": "^16.8.4", "react-dom": "^16.8.4", "react-loadable": "^5.5.0", "react-router-dom": "^5.0.0", "react-scripts-ts": "3.1.0", "styled-components": "^4.1.3" }, "devDependencies": { "@types/jest": "^24.0.11", "@types/node": "^11.11.3", "@types/react": "^16.8.8", "@types/react-dom": "^16.8.2", "@types/styled-components": "^4.1.12", "eslint": "5.3.0", "eslint-config-airbnb-base": "13.1.0", "eslint-plugin-import": "^2.14.0", "typescript": "^3.3.3333" }

TSCONFIG JSON
{ "compilerOptions": { "baseUrl": ".", "outDir": "build/dist", "module": "esnext", "target": "es5", "lib": ["es6", "dom"], "sourceMap": true, "allowJs": true, "jsx": "react", "moduleResolution": "node", "rootDir": "src", "forceConsistentCasingInFileNames": true, "noImplicitReturns": true, "noImplicitThis": true, "noImplicitAny": true, "importHelpers": true, "strictNullChecks": true, "suppressImplicitAnyIndexErrors": true, "noUnusedLocals": true, "esModuleInterop": true, "types": ["styled-components", "react", "react-dom", "jest"] }, "exclude": [ "node_modules", "build", "scripts", "acceptance-tests", "webpack", "jest", "src/setupTests.ts" ] }

لدي نفس المشكلة. لحسن الحظ ، تمكنت من التغلب على المشكلة عن طريق قفل إصدار @types/styled-components في 4.1.8

بالمثل هنا ، كان علي إما العودة إلى إصدار سابق ، أو إضافة برنامج نصي لما بعد التثبيت لإزالة رد الفعل الأصلي من node_modules

كيف يُفترض بك حتى استخدام مكونات نمطية على الويب على الإطلاق إذا كانت التبعيات تتعارض افتراضيًا مع dom libs؟!
هذا جنون!

لدي نفس المشكلة ولاحظت أيضًا أنه لم يتم إخطار جميع المؤلفين. هذان الشخصان مفقودان: @ eps1lonflavordaaave

ArthurBrito شكرا ، تم تحديث قائمة المؤلفين.

هذه القضية تحدث لي أيضًا. يجب ألا تكون @ أنواع / رد فعل أصلي تبعية في مشاريع الويب. يجب فصل هذه الأنواع

بقدر ما أستطيع أن أقول أن هذا كان بسبب # 32843 الذي تم إصداره كـ 4.1.9 . هذا التعليق يدعم ذلك.

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

/ ccminestarks

إصلاح الإصدار إلى 4.1.8 يعمل بالنسبة لي

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

حصلت على نفس المشكلة ، إنها بالفعل حوالي @types/styled-component .

my-app git:(master) ✗ npm ls @types/react-native
[email protected] /Users/devniel/dev/electron/my-app
└─┬ @types/[email protected]
  └── @types/[email protected]

أي تحديث للقضية؟

قم بإنشاء ملف .yarnclean بالمحتوى التالي:

@types/react-native

يصلح المشكلة 🎉

نصف عام وما زلت لا تحديثات لهذه القضية؟

حقا لا يوجد تحديث ؟؟؟

في رأيي ، فإن أفضل حل هو جعل @ types / response-native تبعية للأقران ، لكن حسب معرفتي ، فإن types-publisher لا يدعمها في الوقت الحالي. هل يمكن لأحد المشرفين التحقق من أنني في الحقيقة على حق وأن peerDep هو الحل؟ قد أكون قادرًا على قضاء بعض الوقت في عطلة نهاية الأسبوع في إضافة دعم peerDep إلى type-publisher ، إذا كنا على ما يرام.

في رأيي ، فإن أفضل حل هو جعل @ types / response-native تبعية للأقران

حسنًا ، إذا كان @types/react-native هو وكيل نظير ، فسأحتاج إلى إعلانه على أنه تبعية من أجل استخدام @types/styled-components في مشروع غير React Native. هذا ليس مثاليًا.

من الناحية المثالية لن يكون مطلوبًا @types/react-native بواسطة مشروع غير React Native ؛ وأنا على وجه الخصوص لا يجب أن _أعلن_ أنها تبعية.

هل تقصد أن تجعلها تبعية اختيارية؟

paulmelnikow ، نعم ، أنت على حق ، لقد خلطت بين الاثنين. ما زلت لا تحتاج إلى إعلان @types/react-native تبعية من أجل استخدام @types/styled-components ، لكنك ستحصل على تحذير مزعج ، لذا تعد OptionalDeps حلاً أفضل بالطبع. types-publisher لا يدعمهم أيضًا ، وسأحاول النظر في الأمر

الرجوع إلى إصدار "@ types / Styled-components": حل "4.0.0" المشكلة.

لا ، لا يحل. يكتسح المشكلة تحت السجادة

لا ، لا يحل. يكتسح المشكلة تحت السجادة

دعنا نقول أنه تجميع مرة أخرى؟ ؛-)

قم بإنشاء ملف .yarnclean بالمحتوى التالي:

@types/react-native

يصلح المشكلة 🎉

هل يوجد أي مكافئ مع npm؟

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

عند الغوص في الكود الفعلي لهذا الريبو ، يمكنك أن ترى بوضوح أن @types/react-native مطلوب فقط في .d.ts الفعلي وملف الاختبار لتكامل React Native. أعتقد أن الحل الأكثر ملاءمة هو تقسيم أي شيء متعلق بـ React Native إلى وحدة فرعية خاصة به / اختياري / تبعية نظير ، بما يتوافق مع سلوك كيفية عمل styled-components بالفعل ، يمكنك استيراد styled-components/native إذا كنت تريد مواد React Native. أنت لا تستورد styled-components وتحصل على الغابة الكاملة لأشياء React Native أيضًا في وقت التشغيل ، لذلك من خلال استيراد styled-components لا يجب أن أحصل على الغابة بأكملها @types/react-native أنواع

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

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

عند الغوص في الكود الفعلي لهذا الريبو ، يمكنك أن ترى بوضوح أن @types/react-native مطلوب فقط في .d.ts الفعلي وملف الاختبار لتكامل React Native. أعتقد أن الحل الأكثر ملاءمة هو تقسيم أي شيء متعلق بـ React Native إلى وحدة فرعية خاصة به / اختياري / تبعية نظير ، بما يتوافق مع سلوك كيفية عمل styled-components بالفعل ، يمكنك استيراد styled-components/native إذا كنت تريد مواد React Native. أنت لا تستورد styled-components وتحصل على الغابة الكاملة لأشياء React Native أيضًا في وقت التشغيل ، لذلك من خلال استيراد styled-components لا يجب أن أحصل على الغابة بأكملها @types/react-native أنواع

👍

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

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

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

بالتأكيد تيبيد يوفر خدمة رائعة لمجتمع الحزمة وهناك مشرفون هنا ، على الرغم من أن وظيفتهم ليست صيانة جميع الأنواع. هز قبضتك في هذا المشروع (أو في TypeScript) لن يساعدك.

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

ماذا لو قمنا بإعادة التغييرات التي تم إدخالها في # 32843 ، حيث أنه كسر الكتابة لما يزيد عن 90 ٪ من المستخدمين وأجبرهم على استخدام إصدار قديم أو بعض الاختراقات المذكورة في هذا الموضوع.

ماذا لو قمنا بإعادة التغييرات التي تم إدخالها في # 32843 ، حيث أنه كسر الكتابة لما يزيد عن 90 ٪ من المستخدمين وأجبرهم على استخدام إصدار قديم أو بعض الاختراقات المذكورة في هذا الموضوع.

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

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

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

IMO ، يجب التراجع عن هذا - بشكل أساسي لأن النظام البيئي للمكونات المصممة على غرار الويب أكبر.

لا أعرف كل التفاصيل الخاصة بكيفية عملها بعد الآن ، ولكن كان الأمر كذلك بالنسبة لـ React Native ، ستحصل على مجموعة مختلفة من الأنواع باستخدام مسار مختلف بدا وكأنه حل وسط جيد بالنسبة لي. هرم ، يبدو أن هذا هو ما يجلب. هذا يعود إليه.

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

+1 هنا ، ولكن ليس فقط تقديم شكوى ، إذا كانت هناك خطة عمل أريد المشاركة فيها والمساعدة في حل هذه المشكلة.

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

وهذا هو السبب في أنني توسلت إلى مديري المكتبات الآخرين للاحتفاظ بأنواعهم. يجبر المكتبة على التحديث بما يتماشى مع أنواعها. أنا أحب أن التعريف المكتوب ساعد المجتمع بعدة طرق ، ولكن عندما يكون لدى المشرفين على lib القدرة على كتابته بأنفسهم (أو حتى إعادة كتابته في ts) ، فإن ذلك يجعل العالم أكثر أمانًا.

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

هل هناك أي علاقات عامة بانتظار الموافقة؟ هل يجب أن أضع سطرًا واحدًا من تغيير الرمز يزيل react-native التبعية العالمية غير الصالحة (كما فعلت داخل الريبو الخاص بي في الدقيقة)؟

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

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

بينما أعتقد أنه يجب التراجع عن هذا التغيير ، لم نكن بحاجة إلى تمكين skipLibCheck لإنجاز هذا العمل: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33311#issuecomment -466731156. من فضلك لا.

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

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

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

يمكن للأشخاص الذين يستخدمون react-native تثبيتها يدويًا.
لماذا هم بحاجة على الإطلاق؟

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

يجب على الأشخاص الذين يحتاجون إلى كتابات مقابل react-native الحصول عليها عن طريق تثبيت @types/react-native .

ما زلت أؤمن بشدة بالموقف الذي مفاده أن كل ما يتعلق بـ react-native يجب حذفه من @types/styled-components ونقله إلى حزمة / مسار مختلف ، على سبيل المثال @types/styled-components/native ليكون متسقًا مع طريقة الأشخاص في الواقع استخدم styled-components ؛ الأشخاص الذين يريدون دعم react-native يحصلون عليه صراحة باستخدام import styled from 'styled-components/native' ، لن تحصل على كامل الغابة react-native عن طريق القيام بـ import styled from 'styled-components' في الويب مشروع ، لذلك لا ينبغي أن تتصرف حزم @types/ المرتبطة بشكل مختلف

لقد اتخذت خطوة في إصلاح هذا بطريقة أكثر منهجية خلال عطلة نهاية الأسبوع ، والتي يمكن أن تعمل مع أي ريبو يلف الأنواع لكل من الويب + التفاعل الأصلي. https://github.com/microsoft/types-publisher/pull/655

كيف لم يتم معالجة هذا ...

عنجد؟ لا يزال هناك حل؟

givethemheller @ sanex3339 هناك إصلاح في الأعمال والمناقشة على https://github.com/microsoft/types-publisher/pull/655

كحل مؤقت ، ما عليك سوى إزالة @types/react-native من node_modules:
rm -rf node_modules/@types/react-native
وأضفه إلى .yarnclean
@types/react-native

مع إصدار TypeScript 3.7 ، نجد أنفسنا الآن في موقف يتم فيه إجبار 3.7 مستخدم على ترقية تعريفات الأنواع الخاصة بهم ، حيث أن الإصدار 4.1.8 الذي كان يعمل سابقًا غير متوافق الآن مع TS 3.7 ، ولكن الإصدار الوحيد المتوافق مع TS 3.7 معطل تمامًا لكل مطور ويب React (والذي يجب أن يكون بالتأكيد الغالبية العظمى). 😕

ربما يكون الحل البديل .yarnclean كافياً لأولئك الذين يستخدمون الغزل ، والذي يتضمن أقل من الجميع. كما أن تعديل compilerOptions ليس حلاً قابلاً للتطوير على الإطلاق.

لا أعرف ما هو الحل الأفضل هنا. كحل مؤقت ، أنا بالتأكيد أؤيد نشر إصدار منفصل يستبعد على وجه التحديد الأشياء react-native .

بصفتك مستخدمًا لا يستخدم الغزل ، يمكنك التغلب عليه عن طريق إضافة هذا إلى البرامج النصية لـ npm:

    "postinstall": "rm -rf node_modules/@types/react-native"

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

أضيف نفسي هنا أيضا. نحن بحاجة إلى حل أفضل من تحرير الكثير من البرامج النصية بعد التثبيت ...

تؤثر هذه المشكلة بشكل أساسي على جميع مستخدمي النصوص المطبوعة للمكونات المصممة لأكثر من عام (!!!).
هل لدينا أي حل رسمي لهذا (بدون احتساب الاختراقات بامتداد .yarnclean)؟ هل هناك أي حاصرات؟

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

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

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

صدم! يجب أن يكون هناك تطبيق أفضل لتعريف النوع ...

لقد قمت بإزالة @types/react-native من node_modules وما زلت أتلقى نفس الخطأ. لماذا حتى مع الاختراق؟

ArnaudJeannin إذا حذفته يدويًا ، فستتم إضافته مرة أخرى في كل مرة تقوم فيها بتشغيل npm i / yarn

لجعل الحذف مستمرًا من خلال التثبيتات ، إما إزالته عبر NPM postinstall حسب تعليقي السابق أو إضافته إلى .yarnclean إذا كنت تستخدم Yarn يجب أن تعمل بشكل جيد.

ما فعلته لن يكون مناسبًا للجميع ، لكنني "قمت بحل" هذه المشكلة بالتبديل من المكونات المصممة إلى العاطفة . يعد استخدامي لأي من المكتبتين أساسيًا جدًا - فقط أغلف المكونات باستخدام CSS وأنماط وراثية - لكنني وجدت أن Emotion لديها واجهة برمجة تطبيقات مشابهة للمكونات المصممة للميزات التي أحتاجها. لقد كان انتقالاً سهلاً. لم أواجه أي مشاكل كبيرة حتى الآن بعد 6 أشهر. يتضمن Emotion كتابات TS مضمنة ، لذلك لا توجد مشكلات غير متزامنة مع @types .

كما هو مذكور أعلاه ، لن يكون تبديل مكتبات CSS مناسبًا للعديد من المشاريع ، ولكن بالنسبة لي كان التبديل أسهل من الخوض في مشكلات TS الخاصة بالمكونات المصممة. YMMV.

حل أبسط لمستخدمي yarn ، سيتيح لك استخدام الإصدار الحالي من المكونات المصممة. في package.json:

  "resolutions": {
    "@types/react-native": "link:./empty-package"
  },

قم بإعداد حزمة لا تفعل شيئًا يكون هدف الدقة أعلاه:

mkdir empty-package
cd empty-pacakge
yarn init -y
touch index.d.ts

يعمل لدي.

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

jamietre أعتقد أن التصويتات السلبية هي أنه على الرغم من أن هذا قد ينجح ، إلا أن هذا ليس هو الحل الصحيح ولا يغير حقيقة أن الأنواع بحاجة إلى الانقسام (أو ربما تبعيات الأقران) للتفاعل الأصلي

jamietre أعتقد أن التصويتات السلبية هي أنه على الرغم من أن هذا قد ينجح ، إلا أن هذا ليس هو الحل الصحيح ولا يغير حقيقة أن الأنواع بحاجة إلى الانقسام (أو ربما تبعيات الأقران) للتفاعل الأصلي

لم أدرك أن الحلول كانت مستهجنة. أجدهم دائمًا مفيدًا جدًا أثناء انتظار الإصلاح الحقيقي. كانت هذه مشكلة لأكثر من عام. ولا يزال العمل بحاجة إلى إنجاز. 🤷‍♂

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

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

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

في Appsome Solutions ، واجهنا نفس المشكلة وقمنا بحلها باستخدام قاعدة "skipLibCheck": true, في ملف tsconfig.json.

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

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

إعادة نشر تعليقي من https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32843#issuecomment -605921101

الحل هو أن يكون لديك مصفوفة compilerOptions.types في tsconfig.json تمنع الكتابة المطبوعة من القراءة التلقائية لكل حزمة @types/* عند فحص الكتابة. سوف يستورد Typescript تلقائيًا أنواع الحزم المسماة في المصفوفة types ؛ على سبيل المثال ، "types": ["node"] (إذا كنت تستخدم وحدات مدمجة مثل buffer أو path ، لتحميل @types/node ) ، "types": ["node", "jest"] (إذا كنت ' إعادة كتابة اختبارات الدعابة أيضًا) ؛ أو حتى "types": [] لمنع الطباعة التلقائية لأية حزمة لم يتم استيرادها مباشرة أو /// <reference types="..." /> من شفرتك.

لا أستطيع حقاً أن أقول ما إذا كان الحصول على @types/styled-components-native سيكون أفضل ؛ سيكون غير معتاد على الأقل ، وربما يزيل الحاجة إلى "الحل البديل" compilerOptions.types ، لكن IMO حدد compilerOptions.types للحزم التي تحتاج إلى تحميل أنواعها تلقائيًا فقط (بدون import s) من أفضل الممارسات.

للتلخيص ، فإن المشكلة هي أن TypeScript يقوم تلقائيًا بتحميل أنواع @types/react-native ، على الرغم من أنك لا تقوم بالإحالة إليها بشكل مباشر أو غير مباشر على الإطلاق ، لأن السلوك الافتراضي هو تحميل جميع حزم @types/* . تعيين compilerOptions.types يمنع هذا الإعداد الافتراضي ولا يحمّل سوى الحزم التي تسردها + الحزم التي لديك import .

لا أصدق أن هذا لا يزال يمثل مشكلة! ركضت في هذه المشكلة في الصيف الماضي ، لقد قمت للتو بتحديث الحزمة لأنني افترضت أن هذا قد تم إصلاحه منذ ذلك الحين 😠

من هو المشرف على أنواع @ / مكوّنات الأنماط؟ لأننا بحاجة إلى شخص جديد

اقتراح Jessidhia compilerOptions.types يعمل معي. شكرا جزيلا! أنا أيضا أرى أن هذا هو أفضل ممارسة. حتى الآن لم أعاني من أي عيوب. يمكنني أن أتخيل أنه أسرع أيضًا.

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

نعم ، إدراج جميع الأنواع في الأنواع ليس خيارًا.

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

انظر على سبيل المثال https://stackoverflow.com/a/59030291

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

كما قال sbush ، هذا ليس صحيحًا. هذا الخيار مخصص فقط للأنواع العالمية ، سيتم استخدام كتابات import ed libs دون أي مشاكل. اقتراح Jessidhia غير ضار.

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

لست متأكدًا مما إذا كان شخص ما قد أجاب بالفعل على الحالة عندما يكون لديك إعادة شراء أحادي Lerna + yarn workspaces (العديد من الإجابات). في هذه الحالة ، يمكنك الاستفادة من مزيد من المعلومات عن الخاصية no-hoist في موقع الغزل

في الممارسات في ملفك package.json :

"workspaces": {
  "packages": ["packages/*"],
  "nohoist": ["**/react-native", "**/react-native/**"]
}

🙏🏻 @types/styled-components": "4.1.8" 🙏🏻

الحل الذي يقترحه nahumzs يعمل إذا كنت تستخدم الغزل monorepos. في هذه الحالة ، نحافظ على رد الفعل الأصلي من تلويث مجلد node_packages العالمي ، مما يمنع التكرارات التي بدورها تلقي بالأخطاء.

في أي نقطة نقول فقط أن هناك عددًا أكبر من مستخدمي React Web مقارنة بمستخدمي React Native ونزع دعم React Native؟

هل كان هناك أي تقدم في هذه القضية؟ نحن حاليًا في الإصدار 4.1.8 من @ types / Styled-components لأننا غير قادرين على التحديث بدون حل أو استخدام حل بديل ، مثل حذف node_modules / @ types / رد فعل أصلي في أمر تثبيت ما بعد npm.

أوه f ** k ، هذه المشكلة تسبب لي الكثير من الألم.

الآن أنا أتحمل المشكلة الموضحة هنا . لذلك ، إذا قمت بالترقية إلى Typecript الأحدث ، فلا يمكنني حتى استخدام @types/[email protected] . 😡😡😡 WTH.

على أي حال ، يبدو أن هذه نسخة مكررة من https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33015.

في Appsome Solutions ، واجهنا نفس المشكلة وقمنا بحلها باستخدام قاعدة "skipLibCheck": true, في ملف tsconfig.json.

في حال شعر أي شخص بالشيء نفسه: لم أرغب في تمكين skipLibCheck فقط للتغلب على هذه المشكلة. لكنني غيرت رأيي الآن بعد أن مكّن التغيير الأخير skipLibCheck لمشروعات TypeScript الجديدة - على ما يبدو لأسباب تتعلق بالأداء ، ولكن

ربما يكون شخص ما على ما يرام مع اختراق سيئ للغاية ، يمكنك فقط إضافة إلى قسم البرنامج النصي package.json :

"postinstall": "rm -rf node_modules/@types/react-native"

ليس حلاً رائعًا ، لكن هذا يجب أن ينجح.

OMG ، لا تزال هذه المشكلة فعلية حتى بالنسبة لـ 5.1.1

1- أضف .yarnclean في جذر المشروع.
2- أدخل المحتوى التالي: @types/react-native .

تم حل هذا هنا على الأقل أثناء انتظار حل رسمي.

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

tsconfig.json

{
  "compilerOptions": {
    "allowJs": true,
    "baseUrl": ".",
    "esModuleInterop": true,
    "isolatedModules": true,
    "jsx": "react",
    "module": "CommonJS",
    "moduleResolution": "Node",
    "noEmit": true,
    "sourceMap": true,
    "target": "ES6"
  },
  "include": [
    "src/**/*"
  ],
}

نتيجة التحويل البرمجي إلى tsc :

المجموع: 38 خطأ. 2 منهم فقط من مصدر مشروعي الفعلي src/**.* ملفات. الأخطاء الـ 36 الأخرى هي من تعارض .d.ts تسبب فيه @types/styled-components .

ملاحظة: إذا أضفت العلامة "skipLibCheck": true ، فستختفي الأخطاء. أيضًا إذا قمت بإزالة @types/styled-components ، فستختفي الأخطاء أيضًا.

لن أنشر السجل الكامل هنا ، ولكن إليك بعض الأمثلة.

error TS2300: Duplicate identifier 'AbortController'.
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1939:11
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1950:13 
node_modules/@types/react-native/globals.d.ts:363:15

error TS2300: Duplicate identifier 'AbortSignal'. 
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1960:11 
node_modules/@types/react-native/globals.d.ts:350:15
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1972:13

error TS2300: Duplicate identifier 'FormData'. 
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:5548:11
node_modules/@types/react-native/globals.d.ts:40:15
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:5558:13

error TS2300: Duplicate identifier 'URL'.
error TS2300: Duplicate identifier 'URLSearchParams'.
error TS2300: Duplicate identifier 'RequestInfo'.
error TS2300: Duplicate identifier 'XMLHttpRequestResponseType'.

error TS2717: Subsequent property declarations must have the same type.  Property 'body' 
must be of type 'string | ArrayBuffer | ArrayBufferView | Blob | FormData | URLSearchParams | ReadableStream<Uint8Array> | null | undefined', 
but here has type 'string | ArrayBuffer | DataView | Int8Array | Uint8Array | Uint8ClampedArray | Int16Array | ... 8 more ... | undefined'. 

error TS2717: Subsequent property declarations must have the same type.  Property 'signal' must be of type 'AbortSignal | null | undefined', but here has type 'AbortSignal | undefined'.

error TS2300: Duplicate identifier 'RequestInfo'.

الحل الذي أتبناه في هذه المرحلة هو إزالة @types/styled-components والمضي قدمًا في مشروعي (وهو تطبيق ويب React).