Definitelytyped: @ type / خطأ superagent TS2304: لا يمكن العثور على الاسم "XMLHttpRequest".

تم إنشاؤها على ١٧ أكتوبر ٢٠١٦  ·  31تعليقات  ·  مصدر: DefinitelyTyped/DefinitelyTyped

  • [] حاولت استخدام أحدث ملف xxxx/xxxx.d.ts في هذا الريبو وكان لدي مشاكل.
  • [] حاولت استخدام أحدث إصدار مستقر من tsc. https://www.npmjs.com/package/typescript
  • [] لدي سؤال غير مناسب لـ StackOverflow . (يرجى طرح أي أسئلة مناسبة هناك).
  • [] أريد أن أتحدث عن xxxx/xxxx.d.ts .

    • مؤلفو تعريف هذا النوع هم cc / @ ....

اليوم بدأت بنياتي بالفشل بسبب أخطاء في @ type / superagent. بدأت في خفض رقم الإصدار حتى اكتشفت أن المشكلة تبدأ بالإصدار 2.0.34. قبل ذلك ، لم ينتج عن برنامج التحويل البرمجي Typescript أي خطأ (باستخدام الإصدار 2.1.0-dev.20161017)

مع @ types / [email protected] الخطأ هو:
node_modules/@types/superagent/index.d.ts (79،12): خطأ TS2304: لا يمكن العثور على اسم 'XMLHttpRequest'.

ومع @ types / [email protected] الخطأ هو:
node_modules/@types/superagent/index.d.ts (79،12): خطأ TS2304: لا يمكن العثور على اسم 'XMLHttpRequest'.

آمل أن تساعدك هذه المعلومات يا رفاق.

@types

التعليق الأكثر فائدة

المشكلة الوحيدة التي أواجهها مع إضافة "dom" إلى tsconfig.json هي أنني أكتب كود جانب الخادم. لذلك ليس من المنطقي بالنسبة لي إضافة هذا lib. لم يتم شحن XMLHttpRequest مع Node.js ولم يتم طرح حزمة superagent وخطأ في Node.js. تكمن المشكلة في أن حزمة typings لا تستخدم XMLHttpRequest بشكل مشروط على ما أعتقد. إذا كانت الحزمة تعمل بشكل جيد على Node.js والمتصفح ، فيجب أن تعمل typings بشكل جيد أيضًا.

ال 31 كومينتر

هل تستخدم الخيار --lib dom لـ tsc؟

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

vvakame - أدت إضافة "dom" إلى مصفوفة compilerOptions.lib في tsconfig.json إلى تنفيذ الحيلة. هذا يبدو غير بديهي بعض الشيء. هل يجب أن يكون هذا هو السلوك المتوقع أم أن هذا مجرد حل مؤقت؟

إخلاء المسؤولية: أنا لست مستخدم وكيل.
أعتقد أنه سلوك متوقع.

https://www.npmjs.com/package/superagent

متصفح / عقدة HTTP أنيقة ومميزة غنية بواجهة برمجة تطبيقات بطلاقة

حول العمل.

interface XMLHttpRequest {}

المشكلة الوحيدة التي أواجهها مع إضافة "dom" إلى tsconfig.json الخاصة بي هي أنه لم يكن لدي قسم lib في ملفي ، والآن بعد أن أصبح لدي ذلك ، أحتاج إلى تضمينه libs أخرى بشكل افتراضي مثل "es2016" .

ربما هناك طريقة آلية لإصلاح هذا؟ التي لا تتطلب تعديل tsconfig.json ؟

إضافة ["dom", "es2017"] إلى lib تم إصلاح ذلك.

المشكلة الوحيدة التي أواجهها مع إضافة "dom" إلى tsconfig.json هي أنني أكتب كود جانب الخادم. لذلك ليس من المنطقي بالنسبة لي إضافة هذا lib. لم يتم شحن XMLHttpRequest مع Node.js ولم يتم طرح حزمة superagent وخطأ في Node.js. تكمن المشكلة في أن حزمة typings لا تستخدم XMLHttpRequest بشكل مشروط على ما أعتقد. إذا كانت الحزمة تعمل بشكل جيد على Node.js والمتصفح ، فيجب أن تعمل typings بشكل جيد أيضًا.

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

يمكنك إضافة ملف superagent.d.ts بهذه المحتويات:

// error TS2304: Cannot find name 'XMLHttpRequest'
declare interface XMLHttpRequest {}
// error TS2304: Cannot find name 'Blob'
declare interface Blob {}

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

لقد تعرضنا للعض في https://github.com/strongloop/loopback-next أيضًا. بإضافة dom lib ، فإن مساحة الاسم العالمية قد تلوثت فجأة بأنواع مثل Request غير موجودة في Node.js

نكتب مكدس خادم HTTP ، لذلك عادة ما نقوم بعمل import {ServerRequest as Request} from 'http' . ومع ذلك ، عندما يتم حذف هذا السطر عن طريق الخطأ ، أو إذا لم يتم تسمية ServerRequest باسم مستعار كـ Request ، فإن TypeScript يجمع الكود الخاص بنا بسعادة ويتم رصد الخطأ في وقت التشغيل فقط. بمعنى آخر ، لم يعد TypeScript قادرًا على اكتشاف الأخطاء في وقت الترجمة ، مما يبطل الغرض.

لقد بدأت للتو مشروعًا جديدًا ، واعتقدت أنني سأكون ذكيًا وأتغلب على هذا من خلال التبديل من supertest إلى chai-http ، لكن chai-http يستخدم @ types / supertest. -_-

سنقدم ، إليك حلًا من نوع ما: https://github.com/jwalton/node-supertest-fetch

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

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

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

{
  "extends": "./tsconfig.prod.json",
  "compilerOptions": {
    "lib": ["dom", "..."] // supertest requires dom for type definitions to work
  }
}

(بدلاً من ذلك ، يمكنك فقط تعيين علامة المترجم skipLibCheck:true بدلاً من التغيير والتبديل في libs وسيؤدي ذلك إلى تخطي التحقق من الكتابة لجميع node_modules )

إذا كنت تستخدم ts-jest ، فيمكنك إخباره باستخدام التكوين الخاص بك عبر

"jest": {
        "globals": {
            "ts-jest": {
                "tsConfig": "tsconfig.test.json"
            }
        }
}

بهذه الطريقة لا تضحي بأمان النوع في التعليمات البرمجية العادية ، وهو بالتأكيد أمر محظور (سأفعل ذلك بأعلى دقة قبل القيام بذلك).

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517 يعمل على إصلاح هذه المشكلة ولكن يتم منع العلاقات العامة هذه عن طريق الدمج عن طريق خطأ

chai-http depends on superagent but has a lower required TypeScript version

أفسر هذا على أنه يعني أنه لا يمكن لـ @ types / superagent تحديث متطلبات TypeScript الخاصة بها إلى 3.0+ حتى تقوم جميع حزمtypes التي تعتمد على @ types / superagent أيضًا بتحديث متطلبات TypeScript الخاصة بها إلى 3.0+. بالنسبة لي ، يبدو هذا وكأنه خطأ في نظام types لأنه يربط إصدار TypeScript الخاص بي بأقدم إصدار TypeScript لجميع الأشياء التي تعتمد علي.

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

في حالة عدم وجود إصلاح دائم أفضل كما في تلك العلاقات العامة ، قمت بحل المشكلة في طلبي بالقيام بذلك على النحو التالي:

/// <reference lib="dom" />
import request = require('supertest');

سيعمل توجيه lib "الثلاثي المائل" في TypeScript الإصدار 3.0+.

لقد مضى ما يقرب من 2.5 عام منذ أن تم فتح هذا الإصدار! كيف يمكننا حل هذا.

FWIW ، تختفي المشكلة عند تمكين خيار مترجم TypeScript skipLibCheck .

عند تمكين skipLibCheck ، لن يتحقق TypeScript من أي ملفات .d.ts - كلاهما من تبعيات مثل @types/superagent ولكن أيضًا أي ملفات .d.ts قد تكون لديك في مشروعك. يمكنك إزالة dom من libs الخاص بك ولن يشكو المترجم بعد الآن.

كتأثير جانبي لطيف ، عادةً ما يعمل skipLibCheck تحسين سرعة البناء أيضًا بشكل كبير.

bajtos يمكن أن يعرضك ذلك للأخطاء ، لأنه يقلل من أمان الكتابة.

  • عمل lib: [ "es6" ]
  • target: "es2016+" يعمل أيضًا معي

@ G-Rath ما لم أسيء الفهم ، فإن skipLibCheck لن يقلل من أمان نوع الكود الخاص بك ، فقط من ملفات d.ts ، والتي من المحتمل أن تكون جزءًا من وحدات العقدة وليس الكود الخاص بك على أي حال.

فيما يتعلق بـ skipLibCheck ، هذا ليس حلاً قابلاً للتطبيق IMO. من https://stackoverflow.com/questions/52311779/usage-of-the-typescript-compiler-argument-skiplibcheck "بناءً على ماهية الأخطاء ، قد يتعافى المترجم منها بطريقة تسبب مشاكل في مكان آخر في الكود عدم ملاحظته (على سبيل المثال ، عن طريق استبدال نوع خاطئ بأي نوع) ، وبالتالي فإن قمع أخطاء النوع (سواء عن طريق --skipLibCheck أو // @ ts-ignore أو أي وسيلة أخرى) يعد ممارسة محفوفة بالمخاطر "

@ carnesen ، لقد راهنتني بذلك - كان هذا هو السؤال الدقيق الذي كنت سأقتبس من stackoverflow: الفرح:

rjmunro هناك تذهب 😃

إنه ليس سيئًا مثل // @ts-ignore ، لكن أي شيء يمنع أخطاء الكتابة ، بغض النظر عن ندرة ذلك ، يؤدي تقنيًا إلى إضعاف نوع أمان الكود الخاص بك ، خاصة وأن مجلد node_modules يتكون من .d.ts ملفات

أعتقد أن الحل الأنظف حقًا هو PR # 33517 بواسطة carnesen الذي يضيف مكتبة dom كمرجع خارجي لتعريف النوع superagent ، منذ الإشارات إلى Blob و XMLHttpRequest مطلوب # superagent ولكن ليس من خلال تنفيذه ، اعتمادًا على طريقة استخدامه (_browser vs node_).

الجانب السلبي الحقيقي الوحيد هو أن مرجع lib يتطلب الإصدار 3.0.0 الذي تم إصداره منذ 9 أشهر تقريبًا الآن.
لست متأكدًا مما إذا كان هذا سيؤثر فقط على chai-http (انظر Travis-CI ) أو إذا كانت هناك تبعيات أخرى قد تحتاج إلى أن يتم رفع نسخة الحروف المطبوعة إلى 3.0.0

أي تحديثات؟ إنها مرة أخرى بعد شهرين ...

بعد قراءة كل هذا ، فإن أنظف حل متاح حاليًا هو من carnesen ولكنه لا يعمل بالنسبة لي :-(

/// <reference lib="dom" />
import request = require('supertest');

لقد تحققت أيضًا من العلاقات العامة الخاصة به (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33517) لكن خطأ TravisCI لا معنى له لأن chai-http لا يتطلب إصدار TS أقل من 3.0 ...

أنا جديد تمامًا على TypeScript ، لذا إذا كنت أفعل شيئًا خاطئًا فأعلمني بذلك. لقد قدمت للتو نفس الكود بالضبط الذي استخدمته @ carnesen في العلاقات العامة الجديدة للتعمق أكثر في سجلات Travis CI (https://github.com/DefinitelyTyped/DefinitelyTyped/pull/36282)

تعديل:

يبدو أن chai-http لم يعد هو المشكلة بعد الآن ولكن promisify-supertest ... يبدو أنه حزمة مهجورة غير مشهورة (https://github.com/ariporad/promisify-supertest/blob /master/test/index.js)

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

تحرير 2:

لقد بحثت بشكل أعمق ووجدت أن تعريفات الأنواع التالية بحاجة إلى التحديث:

  • وعد- supertest
  • عقدة بسيطة cw
  • وكيل بنيان
  • وكيل فائق لا مخبأ
  • وكيل سوبر
  • فوق

// خطأ TS2304: لا يمكن العثور على الاسم "XMLHttpRequest"
التصريح عن واجهة XMLHttpRequest {}
// خطأ TS2304: لا يمكن العثور على الاسم "Blob"
إعلان Blob للواجهة {}

JasonKleban أين يذهب هذا الملف؟ في node_modules > superagent ؟ لقد كنت أحاول معرفة ذلك وأنا في ذكاء.

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

يمكنك أيضًا تجربة إعداد مجلد الكتابة tsconfig.json؟

تحرير: فتح عددًا جديدًا لتتبع هذا: # 41425


بدمج # 36282 توجد مشكلة جديدة. عند استخدام superagent في مشروع عقدة فقط ، يتم إدخال توجيه الشرطة المائلة الثلاثية

/// <reference lib="dom" />

يؤدي إلى إضافة كتابات DOM بشفافية إلى المشروع. نظرًا لأن هذا مشروع عقدة فقط ، فلا يوجد DOM ، وبالتالي لا يوجد رمز مثل

window.setTimeout()

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

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

تأثير جانبي آخر لوجود التبعية هو dom وهو أنه يمنع استخدام supertest ( superagent ) في مشروع lib: webworker ، المرجع: https: //github.com/microsoft/TypeScript/issues/20595. بقدر ما أستطيع أن أرى ، هذا لم يذكر من قبل.

$ npm i @ types / superagent @ latest -D

يجب أن تفعل الحيلة!

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات