[تم النقل إلى typecript.main في package.json في وصف المشكلة أعلاه]

: +1:
أعتقد أن http://nodejs.org/api/modules.html#modules_folders_as_modules قاعدة شائعة جدًا في Node.js.

مثال آخر.

./test/index.ts

export function hello() { return "Hello, world"; }

./main.ts

import test = require("./test/");
console.log(test.hello()); // print "Hello, world"

[تم النقل إلى typecript.definition في package.json في وصف المشكلة أعلاه]

سيكون أحد الحلول هو حلها باستخدام أدوات أفضل. على سبيل المثال ، يمنحك import foo = require('foo') تلميحًا للبحث عن بعض node_module + package.json المحلية (foo هو مشروع ts) أو تعريف DT (foo هو مشروع js حيث لا يرغب مؤلفو المكتبة في الحفاظ على ts def) .

لمعلوماتك؛ أنا في الواقع أختبر شيئًا مشابهًا لهذا في TSD ؛ طريقة لعرض وربط التعريفات المجمعة في حزم npm (أو bower).

إنه موجود في إصدار dev الخاص بي لـ 0.6 ، ويعمل عن طريق إضافة عنصر typescript إلى package.json (أو bower.json) ، مع عنصر فرعي definition (عنصر فرعي ربما يكون واحدًا اليوم سيكون هناك source أيضًا ، أو أيًا كان).

{
    ...
    "main": "./index.js",
    "typescript": {
        "definition": "./foo.d.ts"
    }
    ...
},

ثم يمكنك تشغيل أمر على TSD ، حاليًا tsd link وسيقوم بفحص جميع ملفات package.json في node_modules (أو bower أو أيًا كان) ، ابحث عن هذه الخاصية إذا تم تعريفها وأضف مرجعًا إليها إلى tsd.d.ts المركزي حزمة

مثال: تم تعريفه هنا واستخدامه هنا

تضمين التغريدة يمكن أن تكون الخطوة الأولى لوجود .d.ts في حزم npm. تعجبني بنية package.json مع "تعريف" في "نص مطبوع" ، فهي أكثر تنظيماً.

إذا كان مترجم TypeScript نفسه يمكنه قراءته تلقائيًا ، فسيكون رائعًا جدًا.

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

ناقش أيضًا # 207 - البحث تحت "الفهرس"

: +1:

chanon tsMain ليس ضروريًا إذا استخدمنا إنشاء الإقرارات.

نعم ، هذه المشكلة مهمة للغاية حتى بالنسبة للمتصفحات - تستخدم الكثير من المشاريع browserify / packify وبالتالي تخطيطات الدليل المتوافقة مع العقدة

: +1:

كان هناك بعض العمل بالفعل في هذا المجال مرة أخرى في codeplex repo ، طلب سحب واحد بواسطة leebyron وآخر بواسطة kayahr .

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

لقد كتبت اقتراحًا حول كيفية إضافة هذا إلى مترجم TypeScript . يتضمن هذا أيضًا البحث في الدليل typings حيث سيكون ذلك مهمًا عند العمل مع وحدات جافا سكريبت التي لن تحتفظ بتعريفات الحروف المطبوعة الخاصة بها. لسوء الحظ ، لجعل كل هذا العمل بشفافية مع tsd سيستمر القليل من العمل لأن متطلبات /// <reference d الملفات تجعل الأمور صعبة بعض الشيء. سوف ألقي نظرة على تنفيذ هذا على أحد الفروع وتقديم بعض نماذج الوحدات النمطية التي تستخدمه.

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

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

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

joewood أيضًا ستكون هناك مشاكل بين الإصدارات المختلفة من A

├── [email protected]
└── [email protected]
    └── [email protected]

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

مهتم بسماع الحلول لنفسه. يحتوي TypeScript على نطاق متغير على مستوى global للإعلانات المحيطة

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

joewood Yep ، هذا ما آمل أن يتم إصلاحه في معظم الحالات بتغيير require لتحميل التعريفات الصحيحة ، وتجنب /// reference كلما أمكن ذلك. سيتم تحديد الوحدات الخارجية من خلال مساراتها المطلقة بدلاً من وجود إعلانات محيطة ، لذا من المفترض أن يكون تحميل العديد من نفس الاسم من مسارات مختلفة وفي إصدارات مختلفة أمرًا ممكنًا.

نعم ، هذا ما آمل أن يتم إصلاحه في معظم الحالات عن طريق تغيير يتطلب تحميل التعريفات الصحيحة ، وتجنب /// المرجع حيثما أمكن ذلك.

: +1:

: +1: شكرًا @ Nemo157 والجميع على المناقشة.

لقد قمت بتحديث نص العدد الأعلى لدمج إضافات package.json وربطها بمقترح @ Nemo157 .

: +1:

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

: +1:

المجلدات كوحدات نمطية مع index.ts: +1:

: +1:

: +1:

: +1:

: +1:

: +1:: +1:: +1:

: +1:: +1:: +1:: +1:

تعليقًا على إعادة هذا إلى الرادار الخاص بنا.

لقد حققت نجاحًا جيدًا مع اقتراح Bartvds :

ثم يمكنك تشغيل أمر على TSD ، رابط tsd حاليًا وسيقوم بفحص جميع ملفات package.json في node_modules (أو bower أو أيًا كان) ، والعثور على هذه الخاصية إذا تم تحديدها وإضافة مرجع إليها إلى حزمة tsd.d.ts المركزية في مشروعك.

لذا فكر بالتأكيد في دعم typescript بـ package.json لأن هذه هي الطريقة التي ذهب بها المجتمع.

نحتاج بالتأكيد إلى tsc لتكون على دراية بالمجلد node_modules إذا كان TypeScript سيُستخدم على نطاق واسع في مجتمع node.js. أستخدم حاليًا ارتباطات رمزية للوحدات النمطية التي تعد جزءًا من مشروع التطوير الخاص بي (باستخدام مساحة عمل npm) ، ولدي خياران في الوقت الحالي:

• الاستيراد مباشرة من node_modules ، والذي يبدو خاطئًا: import Foo = require("node_modules/mymodule/Foo");
• الحصول على tsc لإنشاء ملفات التصريح ثم تجميعها معًا باستخدام ملف إعلان الوحدة الذي يتم الاحتفاظ به يدويًا والذي يقوم بالتبديل عبر أسماء وحدات السلسلة

هل يمكن أن يتحقق tsc من اسم الوحدة الخارجية في إقرارات الاستيراد ثم أثناء دقة المسار ، يطبق أيضًا node_modules بنفس الطريقة التي يستخدمها وقت تشغيل node.js؟ يمكن لخيار المترجم أيضًا تشغيل هذا أو إيقاف تشغيله.

: +1:: +1:: +1:

يمكن أن يتحقق tsc من اسم الوحدة الخارجية في تعريفات الاستيراد ، ثم أثناء دقة المسار ، يطبق أيضًا node_modules بنفس الطريقة التي يستخدمها وقت تشغيل node.js

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

كان هذا في قائمتي لفترة من الوقت الآن. سيحاول الحصول على هذا في الإصدار القادم.

نحن ( Booktrack ) نستخدم TypeScript لجميع عمليات تطوير الويب الخاصة بنا ، ونواجه تحديات مماثلة لمطوري node.js. أتحدث لأن صوت مطوري الويب لا يبدو مرتفعًا مثل صوت مطوري العقدة.

الحلول (بالترتيب بين الأسوأ بالنسبة لنا والأفضل لنا):

1. دقة أسماء الوحدات الخارجية ذات المستوى الأعلى عبر البحث المشفر إلى node_modules
2. لا يوجد تحكم في دقة أسماء الوحدات الخارجية ذات المستوى الأعلى
3. علامة مترجم للتحكم في الدقة الاختيارية لأسماء الوحدات الخارجية ذات المستوى الأعلى في الدليل node_modules
4. معلمة "مسار (مسارات) بحث الوحدة النمطية" للمترجم للتحكم في الدقة الاختيارية لأسماء الوحدات الخارجية ذات المستوى الأعلى في المسار (المسارات) المحدد
5. معلمة "محلل الوحدة النمطية" للمترجم لتزويد المحول البرمجي بملحق JS الذي سيحل جميع أسماء الوحدات الخارجية (وليس المستوى الأعلى فقط)
6. الخطافات المناسبة في خدمات اللغة بحيث يمكن التحكم في دقة اسم الوحدة الخارجية

الخيار 1 فظيع ، أفضل الخيار 2.

سيسمح الخياران 5 و 6 بالاستخدامات الغريبة لبيانات الاستيراد ، مثل تلك التي تم العثور عليها عند العمل مع أدوات requestjs أو webpack الإضافية. الفكرة الأساسية: يقوم المترجم بتفويض جميع عمليات البحث عن اسم الوحدة الخارجية (وليس المستوى الأعلى فقط) لطرف ثالث (مكون إضافي أو رد اتصال). المفوض ، بالنظر إلى المسار إلى الوحدة النمطية تحت الترجمة واسم الوحدة الخارجية ، يعود إلى المترجم مسار نظام الملفات أو معلومات النوع لاسم الوحدة المعطى.

سأكون سعيدًا إذا تم تنفيذ الخيار 4 ، وسأكون سعيدًا إذا تم تنفيذ الخيار 6 وفوق القمر إذا تم تنفيذ الخيار 4 والخيار 6.

ماذا عن --basePath لجذر بحث الوحدة النمطية الخاصة بك ، سيتم النظر إلى جميع واردات الوحدة النمطية بالنسبة لذلك المسار. هذا ينطبق فقط على AMD.

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

لاحظ أننا حصلنا بالفعل على تنفيذ (واختبارات) من @ Nemo157 هنا منذ فترة طويلة https://github.com/Microsoft/TypeScript/issues/247#issuecomment -57422329

اتفق مع @ mark-buer و mhegazy ، الخيار 4 يجب أن يكون مسار البحث إصلاحًا بسيطًا. مطلوب بالتأكيد حل أكثر تفصيلاً في خدمة اللغة (الخيار 6) على المدى الطويل.

_ يستحق الإضافة_: هذا وحده لن يحل مشكلة إعادة استخدام TypeScript في npm بسبب مشكلة الرمز المكرر لمراجع النوع الشائعة # 1125. نحتاج حقًا إلى تجنب ///باستخدام ملفات .tsconfig وإصلاح هذا الأمر بشكل صحيح عن طريق تجميع الحزم في وحدة نمطية خارجية واحدة مطبوعة كما هو مقترح في # 17

تصويت آخر للحصول على مجلد node_modules يتعرف عليه المترجم المنسوخ.

بالنسبة لوحدات CommonJS النمطية ، يجب أن تتبع الكتابة المطبوعة نفس دقة اسم الملف التي تتطلب حلًا (كما هو موضح بواسطة كود psuedocode في هذه الصفحة: http://nodejs.org/api/modules.html#modules_all_together.

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

أين يجب أن يكون الدليل node_modules ذو صلة بالمصادر؟

يدعم Atom-TypeScript الآن typescript.definition خارج الصندوق. التفاصيل: https://github.com/Microsoft/TypeScript/issues/2829

يمكنك أيضًا إنشاء مثل هذه الحزم بسهولة باستخدام atom-typecript: rose: مرة أخرى راجع # 2829

التقييد

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

أنا منفتح على الاقتراحات لهذه الحالة ، لكن خطتي هي:

• نقوم ببعض الأشياء الذكية في قراءة مثل d.ts لا نعطي TypeScript التعليقات الخارجية reference (على سبيل المثال node.d.ts هنا https://github.com/TypeStrong/atom-typescript-examples / blob / master / node / node_modules / example-typescript-b / definition / sample-bdts) وبدلاً من ذلك نشير إلى .d.ts إذا كان لدينا في كتاباتنا.

هل سيبقى هذا على المسار الصحيح لـ 2.0؟ يبدو أنه نوع من الميزات المهمة لاعتماد Node.js ، وهو أمر مؤلم في الوقت الحالي ، حتى مع DefinitelyTyped وإعجاباته.

يبدو أنه نوع من الميزات المهمة لاعتماد Node.js ، وهو أمر مؤلم في الوقت الحالي ، حتى مع DefinitelyTyped وإعجاباته.

LPGhatguy الرجاء مراجعة https://github.com/Microsoft/TypeScript/issues/2338. تعمل vladima على ذلك ولكن لا تعتقد أنه تم تخصيص أي معلم رئيسي لها حتى الآن: rose:

LPGhatguy نحاول الحصول على هذا في الإصدار القادم. آمل قريبا.

mhegazy تقصد 1.6؟ سيكون هذا رائعا!

هل هذا متعلق بـ # 2338؟

نعم لـ TypeScript 1.6 (على الأقل هذا ما نحاول القيام به) ، نعم لـ # 2338 ؛ هناك بعض التغييرات والمشكلات الأخرى حول هذا الأمر بما في ذلك # 3147 و # 4154

إذن ، لماذا تم وضع علامة عليها على أنها TypeScript 2.0 كمحطة رئيسية؟

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

أرغب في طلب دعم وحدة ES6 لمتابعة هذا أيضًا (وهو ما أفترض أنه سيفعل ذلك؟)

كتابة ل

import mylib = require('mylib');
mylib.foo(mylib.bar);

يجب أن تتصرف مثل

import { foo, bar } from 'mylib';
foo(bar);

أرغب في طلب دعم وحدة ES6 لمتابعة هذا أيضًا (وهو ما أفترضه؟

تضمين التغريدة البحث بين الاثنين متسق: ارتفع:

يتم التعامل مع هذا بواسطة # 4154.

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

سؤال:
أعتقد أنه من الاصطلاح الشائع أن يتم تسمية الملفات
"الفهرس" في ملفات JS و
"الرئيسي" في AMD
لمسارات قصيرة.
في السؤال على رأس المؤلف يستورد
/node_modules/concator/index.ts مثل
import concator = require('concator');

أرجو أن تسامحني - أنا الآن أحاول معرفة ما إذا كان يتم دعم دقة الفهرس الآن وماذا عن index.ts أو main.ts في AMD تتطلب الدقة؟
أقوم أيضًا بإجراء اختبار pinging على basarat لمعرفة ما إذا كان / سيتم دعمه بواسطة https://github.com/TypeStrong/atom-typescript لأنه لا يسمح لي الآن بطلب أي index.ts كما هو مذكور أعلاه.

sebilasse ، إذا كنت تستخدم typescript@next اليوم ، يجب أن يعمل هذا مع --module commonjs

import concator = require('concator'); // resolves to node_modules/concator/index.ts

لا توجد تغييرات على كيفية دقة AMD من الإصدارات السابقة.

DavidSouther يجب أن يكون في typescript@next اليوم. جربها وأخبرنا عن أسعارها.

mhegazybasarat : +1: حسنًا. ولكن ما رأيك في دقة AMD لـ main.ts أو index.ts - ألا يجب أن تكون متسقة في المستقبل؟

sebilasse ، بالنسبة إلى AMD ، أعتقد أننا بحاجة إلى القيام بشيء كما أشار vladima في # 2338 (قسم: RequireJS / ES6 محمل الوحدة).

لطيف جدا!! \ س /

mhegazy ما زلت لا تعمل تمامًا كما أتوقع.

لقد جمعت https://github.com/DavidSouther/typescript-example-using-node مع حالة الاستخدام "المثالية" الخاصة بي. tslib هي مكتبة بسيطة تصدر دالة واحدة. يعتمد tsclient على tslib ، بالإضافة إلى readline من حزم Node. يعد البرنامج النصي للإعداد ملائمًا للتثبيت والربط والتنفيذ. لقد قمت بتضمين عملية تشغيل ، وقمت بتعليق الأجزاء غير المتوقعة مع التعليقات المضمنة.

% ./setup
...
> [email protected] build ~/ts-node/tslib
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
...
> [email protected] build /Users/southerd/devel/tmp/ts-node/tsclient
> tsc --version ; tsc -p src/

message TS6029: Version 1.7.0-dev.20150831
# Expect this to find tslib, but fail type checking.
# See tsclient/app.ts for details
src/app.ts(4,21): error TS2307: Cannot find module 'tslib'.

+ node ./dist/app.js # This works as expected!
What would you ask? What is the meaning of life?
42
+ set +x

لا أحصل أيضًا على دعم اللغة لواردات tslib في tsclient (VSCode الإصدار 0.7.0 (0.7.0)) ، على الرغم من أنني لست متأكدًا تمامًا من TSC الذي يستخدمه ، أو كيفية تغيير ذلك.

DavidSouther برنامج التحويل البرمجي TypeScript تحقق من حقل "الكتابة" في package.json للعثور على ملفات ".d.ts". من خلال هذا التغيير ، أحصل على src/app.ts(13,7): error TS2322: Type 'string' is not assignable to type 'number'. ويبدو أنه خطأ مشروع

آه ، لابد أنني فاتني هذا الجزء من المستندات. ما زلت أواجه المشكلة الثانية - كيف يمكنني تغيير إصدار VSCode tsc؟

يمكنك توفير موقع TypeScript SDK مخصص لـ VSCode عبر إعداد "typescript.tsdk" - يجب أن يشير إلى المجلد الذي يحتوي على ملفات tsserver.js وملفات '.d.ts' القياسية. في حالة تثبيت TypeScript كحزمة npm ، فسيكون شيء مثل

// Place your settings in this file to overwrite the default settings
{   
    "typescript.tsdk": "C:\\Sources\\bugs\\node\\typescript-example-using-node\\tslib\\node_modules\\typescript\\lib"       
}

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

error TS2307: Cannot find module

في الوقت الحالي ، يكون الرمز في node_modules / my-module /. وقمت بتحديد index.ts الذي يهتم بتصدير كل شيء ، وقمت بالإشارة إليه في package.json تحت typecript.main. في مشروع المستهلك حاولت استيراد {AClass} من "my-module" ؛ واستيراد وحدتي = تتطلب ('my-module') ؛ كلاهما يؤدي إلى نفس الخطأ في الكتابة المطبوعة 1.7.0-dev.20150901.

عند حل وحدة ذات اسم غير نسبي ، باستخدام --module commonjs ، سيبحث المترجم عن .d.ts الذي يتطابق مع الاسم الموجود في node_modules\name\index.d.ts أو يبحث في package.json لخاصية typings ، وقم بتحميل ملف d.ts الذي يشير إليه.

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

لقد قمت بتحديث الخطوات في خوارزمية دقة وحدة العقدة لتعكس التنفيذ: https://github.com/Microsoft/TypeScript/issues/2338

DavidSouther لدي نفس المشكلة على ما يبدو. عندما أقوم بالتجميع باستخدام تبعية في node_modules ، لا يمكنني حل الوحدة وإخراج خطأ ، ولكن بعد ذلك ، لا يزال يولد js ، وإذا قمت بتشغيله ، فإنه يعمل. ربما يكون ذلك بسبب الإعداد الخاص بي لا أعرف. غالبًا ما تكون d.ts الخاصة بي فارغة ، ولدي index.ts يهتم باستيراد وإعادة تصدير جميع فئات الوحدات النمطية الخاصة بي المحددة في العديد من ملفات .ts. ثم يشير ملف d.ts الخاص بي فقط إلى هذا index.ts ويصدر كل شيء من index.ts مثل هذا:

/// <reference path="index.ts" />

declare module 'my_module' {
    export * from 'index';
}

أيضًا ، لا يزال يقوم بطريقة ما بتجميع ts من node_modules ، لذلك يجب أن أضيف مهمة نظيفة لحذفها بعد التجميع. هل يوجد وصف للميزة في مكان ما يلخص العملية؟

تحرير: لقد نجحت في العمل ، لكنها فائقة الاختراق ولا تزال تنتج أخطاء. لقد أنشأت d.ts باستخدام dts-generator ، ثم قمت باستيراد فصولي مثل هذا:

import MyClass from '../../node_modules/my_module/dist/MyClass';

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

لا تزال تواجه مشكلات في الاستيراد من الوحدات الفرعية (على سبيل المثال npm install angular2، import { Inject, Binding } from 'angular2/di' . ستعمل على الحصول على حالة اختبار محتواة الليلة.

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

من المحتمل أن يكون هذا صحيحًا ؛ سأعمل معهم وأرى أين سينتهي الأمر.

تعمل هذه الميزة بشكل جيد على typecript 1.1 ، على سبيل المثال https://github.com/Nemo157/typescript_w_node_modules_example

ولكن تفشل في الكتابة المطبوعة 1.5.3 ، هل تغير أي شيء؟

------ تحديث ---------

أعلم أنه سيصدر في 1.6 ، شكرًا

يمكنني الحصول على "نصف العمل" فقط في 1.6.2

أولاً ، أقوم بتجميع مكتبة بها my-lib.d.ts في الدليل dist ، وأشير إلى هذا الملف في السمة package.json file typings (على سبيل المثال ، "typings" : "dist/my-lib.d.ts" )

ثم أقوم باستيراد هذه المكتبة في ملف Test.ts TypeScript باستخدام

import { MyObject } from "my-lib"

يتم استيراد MyObject بشكل صحيح ويتم إرسال كود js عند التحويل.
يوفر Visual Studio Code إكمالًا على MyObject

ومع ذلك ، أحصل على تحذيرات من المجمع بما يلي:
Test.ts(10,60): error TS2306: File '[]/node_modules/my-lib/dist/my-lib.d.ts' is not a module.

سيُظهر Visual Studio Code بالفعل الاستيراد كخطأ فادح

يجب أن تكون أية وحدات نمطية مستوردة من حزمة العقدة "وحدات خارجية" وليست "إعلانات وحدة نمطية محيطة". على سبيل المثال ، لا توجد إعلانات declare module "foo" {.. } ، ولكن بدلاً من ذلك ، إعلانات استيراد أو تصدير من المستوى الأعلى في الملف.

لذلك إذا كانت الحزمة الخاصة بك "my-lib" مكتوبة بخط مطبوع ، فقط قم ببنائها باستخدام --declarations واضبط الكتابة على الملف .d.ts للوحدة النمطية الرئيسية الخاصة بك. إذا لم يكن الأمر كذلك ، وكانت كتاباتك عبارة عن شيء كتبته يدويًا ، أو حصلت عليه من كتابته بالتأكيد ، فستحتاج إما إلى تغييره إلى وحدة خارجية ، أو الانتظار حتى يتم حل # 4665 (نأمل قريبًا).

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

فيما يلي بعض الوثائق لعمليات البحث المستقبلية: https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

mhegazy شكرًا لك على ردك السريع الذي ساعدني حقًا في سعيي لأتمتة بناء مكتبة Commonjs librairies ، المكتوبة في Typescript ، والتي يمكن استهلاكها بواسطة كل من Javascript و TypeScript code.
يتحرك بناء الجملة والدقة في import/export بسرعة كبيرة في الآونة الأخيرة لدرجة أن ما أعتقد أنه مفقود الآن هو دليل نهائي حول كيفية إنشاء واحد.

لقد نجحت في العمل ... مع تحذير واحد (ومن ثم سؤال آخر)

هنا عرض مبسط للإعداد.

تتكون المكتبة من ثلاثة كائنات A1 ​​و A2 و B في ملفين من الحروف المطبوعة A.ts و B.ts ؛ شيء مثل

مصادر

A.ts

class A1{}
class A2{}
export { A1, A2 }

B.ts

class B{}
export { B }

ما نريد كشفه يتم جمعه في index.ts :

export * from './A'
export * from './B'

يبني
تم إجراء الإصدار بمساعدة grunt وتم تعيين علامتي --module commonjs و --declaration على tsc 1.6.2
النتيجة النهائية للبناء هي شجرة تشبه

    package.json
    dist/
        js/
             A.js
             B.js
             index.js
        typings/
             A.d.ts
             B.d.ts
             index.d.ts

يحتوي package.json على هذين الإدخالين:

"main": "dist/js/index.js",
"typings": "dist/typings/index.d.ts"

استخدام هذه المكتبة في TypeScript 1.6.2 مع import {A1, A2, B} from "mylib" بسيط يعمل بشكل جيد تمامًا. تعمل التبعيات متعددة المستويات (على سبيل المثال ، librairies التي تستورد بعضها البعض) بشكل جيد أيضًا.

حيث تنشأ المشاكل عندما تعتمد المكتبة على مكتبة أخرى ليست مكتبة TypeScript.
لنفترض أن المكتبة تعتمد على Node.js.
في أحد الملفات المصدر ، سيكون هناك إشارة إلى أنواع NodeJS على سبيل المثال
///<reference path="../typings/node/node.d.ts"/>

عند الترجمة ، سينتهي الأمر بتعليمات <reference > في ملف الإقرار المقابل ؛ المشكلة هي أن المسار إلى node.d.ts من المحتمل أن يكون خاطئًا أو غير موجود.
هل هناك طريقة موصى بها للقيام بذلك؟

_Note_: تم تخفيف هذه المشكلة عن طريق استخدام ملف index.ts لفضح الأجزاء المثيرة للاهتمام من المكتبة ، نظرًا لأن index.ts ليس لديه سبب لاحتواء تعليمات <reference > ومع 1.6 .2 ، لا يبدو أن المترجم يهتم بأن Adts لديه مسار غير صالح في التعليمات المرجعية

bgrieder نتعامل مع هذا في الفوسفور باستخدام tsconfig.json :
https://github.com/phosphorjs/phosphor-widget/blob/master/src/tsconfig.json

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

sccolbert نعم!
كنت قلقًا من أن إزالة تعليمات <reference ...> ستؤدي إلى تعطيل الإكمال التلقائي لجميع IDEs ، ولكن مهلا ، لا: على الأقل يبدو أن Visual Studio Code 0.8.0 ذكي بما يكفي لاختيار هذه التعريفات من tsconfig.json ملف

تمت مع reference . ممتاز !

تضمين التغريدة

ماذا لو كنت تستخدم مشروعًا عاديًا Node.js بداخله و * .d.ts له ، كيف يساعدك الحل tsconfig ؟

heycalmdown ، ما عليك سوى إضافة d.ts إلى الحقل files في tsconfig ، إليك مثال على ذلك:

https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/tsconfig.json#L11
https://github.com/phosphorjs/phosphor-widget/blob/master/test/src/index.ts#L10

لاحظ أنه يتعين علينا استخدام require هنا بدلاً من import فقط بسبب كيفية كتابة ملف d.ts لـ يتوقع.js داخليًا.

حسنا حصلت عليه. تبدو مستودعاتك كنوع من الأمثلة الجيدة.

هل تم تنفيذ هذا بالفعل في TypeScript 1.6.2؟

إذا كان الأمر كذلك ، فهل يمكن لأي شخص أن يقول لي ما الخطأ الذي أفعله هنا ؟:
https://github.com/chanon/typescript_module_example

ربما تريد صيغة الاستيراد es6.

في الأربعاء ، 4 نوفمبر 2015 ، 6:10 صباحًا كتب chanon [email protected] :

هل تم تنفيذ هذا بالفعل في TypeScript 1.6.2؟

إذا كان الأمر كذلك ، فهل يمكن لأي شخص أن يقول لي ما الخطأ الذي أفعله هنا ؟:
https://github.com/chanon/typescript_module_example

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/Microsoft/TypeScript/issues/247#issuecomment -153688004
.

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

chanon على حزم package.json لـ node_modules تحتاج إلى مفتاح typings الذي يشير إلى ملف d.ts ، _not_ a typescript يشير المفتاح ملفات .ts مثل الموجودة لديك الآن.

نحن نستخدم دقة وحدات العقدة في PhosphorJS حصريًا (في TS 1.6.2) وهي تعمل بشكل جيد. هذا مثال: https://github.com/phosphorjs/phosphor-widget/blob/f908341cb1d46ada8ad8149e695a75e7ea2fde57/package.json#L6

شكرًا لك sccolbert ، ولكن اقتراحي الأولي (في الجزء العلوي من هذه المشكلة) كان السماح لخاصية typescript.main في package.json والتي من شأنها أن تشير إلى نقطة إدخال TypeScript الرئيسية لحزم وحدة العقدة المكتوبة في TypeScript.

سيسمح هذا باستيراد وحدات TypeScript النمطية في كود TypeScript دون الحاجة إلى ملفات كتابة d.ts (لن تكون هناك حاجة لإنشاءها).

chanon كنت أشير للتو إلى ما عليك القيام به لتشغيل الكود الخاص بك.

sccolbert أرى شكرا.

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

يبدو أن المشكلات الرئيسية المتعلقة بمنطق حل الوحدة النمطية (بخلاف هذا) هي # 2338 وهي مغلقة و # 5039 والتي يبدو أنها تتعلق بدعم دقة مسار نمط SystemJS الذي يبدو معقدًا للغاية.

ولكن يبدو أن مجرد استيراد أسلوب CommonJS البسيط كما هو مطلوب في البداية في هذه المشكلة قد تم نسيانه؟ على الأقل الجزء المتعلق بـ typecript.main والمجلدات كوحدات نمطية؟

لا أفهم الحاجة إلى وجود (والرغبة في الحصول على) ملفات d.ts إذا تمت كتابة كل من الوحدة النمطية ومستهلك الوحدة النمطية بالفعل في TypeScript.

إنه في الواقع لا يختلف كثيرًا عن استيراد ملف TypeScript سابقًا نسبيًا .

بدلاً من الاضطرار إلى القيام بما يلي:
import * as lib from '../relative/path/to/typescriptFile.ts'

أو:
import * as lib from '../../node_modules/myModule/index.ts'

ما عليك سوى السماح لـ TSC بالقدرة على العثور على ملف الكتابة المطبوعة للاستيراد باستخدام دقة مسار node_modules العادي. واسمح على الأقل باستيراد المجلدات كوحدات نمطية (مع index.ts) بحيث يمكنني في المثال الثاني القيام بما يلي:

import * as lib from 'myModule'

أم أنه بسبب "أنك لا تريد حقًا تجميع تبعياتك ، فأنت تريد فقط أن تستهلك كتاباتها"؟

chanon السلوك الذي تحدده هو ما هو رئيسي الآن. هل يمكنك إعطاء typescript@next في محاولة؟

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

ومع ذلك ، إذا كنت تقوم ببناء كلتا الحزمتين ، فقد ترغب في القيام بذلك أثناء التكرار عليهما. تمت إزالة التقييد في # 5278.

يرجى إلقاء نظرة على صفحة wiki لمشاركة الكتابة من خلال حزمة npm لمزيد من المعلومات: https://github.com/Microsoft/TypeScript/wiki/Typings-for-npm-packages

شكرا لك على التوضيحmhegazy! سأحاول ذلك.

mhegazy حاولت للتو باستخدام typescript@next ، يعمل كما هو متوقع!

هذا عظيم!!

وشكرًا لكم جميعًا على المشاركة في هذا والقضايا ذات الصلة: +1:

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

في ظل خطر الدخول في حقل ألغام ، كيف يُتوقع أن يعمل هذا مع وحدات npm القديمة البسيطة التي لا تحتوي على خاصية typings في package.json؟ محاولة استخدام إما tape أو get-parameter-names مع typescript@next تتسبب في انفجارها في وجهي لأنها غير قادرة على العثور على هذه الحزم بسبب حقيقة أنها لا تملك ذلك منشأه.

بالتأكيد ، إنها ليست وحدات مطبوعة ، لكن لا يمكنني العثور على حل بديل يؤدي إلى تأمين جزء كبير من النظام البيئي npm.

@ danpantry عادة ما تستخدم ملف d.ts عادي مكتوبًا خصيصًا لتلك الوحدة. يحتوي مشروع DefinitelyTyped على ملفات .d.ts للعديد من الوحدات النمطية الشائعة. هناك أداة tsd يمكن أن تساعد في تثبيت وإدارة ملفات .d.ts من موقع DefinitelyTyped لك.

يمكنك استخدام الوحدات النمطية العادية دون الحاجة إلى الكتابة بمجرد استخدام القواعد الشائعة العادية التي تتطلب بناء الجملة.

على سبيل المثال
var moduleName = تتطلب ("moduleName")

يبدو أنchanon هو نوع من الاختراق لاستخدام بناء الجملة "الكلاسيكي" require عند استخدام بناء جملة ES6 مع TypeScript حتى أتمكن من استخدام تبعيات JavaScript ، ولكن شكرًا لك. لقد سمعت عن الأداة المساعدة tsd ولكني لست متأكدًا من كيفية تأثير ذلك في استخدام واردات ES6 .. إلا إذا كنت مضطرًا لبدء استخدام /// <reference path=... لهذه الأنواع من الوحدات؟

نعم هذه طريقة واحدة. هناك طريقة أخرى تتمثل في ملفات tsconfig.json ووضع ملف الجذر tsd.d.ts كملف أول.

قد تكون مهتمًا أيضًا بقراءة هذا ، وتغطية tsd والكتابة https://angularclass.com/the-state-of-typescript-packages/

joewood شكرًا على المعلومات ، المرة الأخيرة التي بحثت فيها في الكتابة المطبوعة كانت في أيام الملفات الفردية .d.ts . مقال ممتاز

chanon @ danpantry من المؤسف أن import foo = require('foo') (مع foo تحت node_modules) لا يعمل عندما لا يكون لدى package.json طباعة.

wmono حسنًا ، نظرًا لأنه ربما كان TypeScript 0.80 أو ربما قبله import foo = require('foo') لبناء الجملة فقط لاستيراد الوحدات النمطية ذات الكتابة. إذا لم يكن به كتابات ، فستستخدم var foo = require('foo') بدلاً من ذلك. لذلك أود أن أقول إنها كما هي.

chanon عفواً ؛ خطأ المستخدم. يبدو أن webpack كان يكافح مع require لكن المشكلة تكمن في مكان آخر.

آسف يمكن لشخص ما توضيح السبب
var foo = require('foo');
يعمل مع node_module قياسي بدون كتابة ولكن
import foo from 'foo';
لا؟ هل كان هذا مجرد تعريف تعسفي؟ لا أفهم لماذا لا يجب أن يعمل هذا الأخير - لا يهمني ما إذا كانت مكتبة JS الخارجية تحتوي على كتابات أم لا.

آسف يمكن لشخص ما توضيح السبب
var foo = يتطلب ('foo') ؛
يعمل مع node_module قياسي بدون كتابة ولكن
استيراد foo من "foo" ؛
لا؟ هل كان هذا مجرد تعريف تعسفي؟ لا أفهم سبب عدم عمل هذا الأخير - لا يهمني ما إذا كانت مكتبة JS الخارجية بها كتابات أم لا.

harangue لأن var require كان أحد تراكيب الوحدات المنافسة (هذه الصيغة commonjs والبعض الآخر في القائمة تتضمن amd ) التي تم دعمها _ خارج نظام فحص النوع_. إذا أراد المرء استخدام نظام النوع ، فربما يفعله import require . مع أخذ ES6 لـ: hammer: والقول أن بناء جملة واحد (: ring :) لحكمهم جميعًا ... من المنطقي أن يكون بناء جملة الوحدة هذا مدعومًا بنظام فحص النوع خارج الصندوق: rose:

basarat شكرا على التوضيح. كانت الرموز مفيدة أيضًا. ؛) ما زلت غير متأكد من سبب فحص نوع القواعد اللغوية ES6. ما الذي يمنع المترجم من أن يقول - "أوه ، لم أتمكن من العثور على أي نوع من البيانات لتلك الوحدة لكنني سأستوردها على أي حال". ما الآثار الجانبية التي قد تترتب على هذا السلوك (الحدسي إلى حد ما ، IMO)؟

هذا محير لأولئك (مثلي) القادمين من ES6 إلى TypeScript. أتوقع أن يتصرف بناء جملة استيراد الوحدة النمطية ES6 بنفس الطريقة في TypeScript ، ولكن للأسف لا يعمل على الإطلاق مع معظم حزم npm ...

لكن للأسف لا يعمل على الإطلاق مع معظم حزم npm ...

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

import koa from 'koa';

يعطي Cannot find module 'koa'. (2307) عندما يكون target es6

koa هو (بالطبع) في node_modules

ومع ذلك ، لا تنشر koa طباعات مطبوعة مع مشروعها. هذا فقط للحزم التي تنشر ملف .d.ts مع مشروعها ، وقم بإدراجها في package.json الخاصة بها. نظرًا لأن koa لا تفعل ذلك ، فستحتاج إلى تثبيت تعريفات الأنواع هذه بالإضافة إلى ذلك من Defin definitely Typed.

يبدو هذا قرارًا سيئًا حيث يتوقع المرء أن يعمل بيان import كما هو الحال في وحدات ES6 العادية. (نعم أعلم ، أن معظم حزم npm هي وحدات CommonJS لكن دعمها هنا سيظل هو الشيء المعقول الذي يجب القيام به.)

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

لا يعد التبديل إلى صيغة استيراد وحدة TS القديمة خيارًا لأنه غير مسموح به عند استخدام الهدف es6 .

أنا جديد على TypeScript لذا ربما لدي فهم خاطئ ، لكن أليست تعريفات النوع اختيارية؟

هذا غير صحيح. يمكن أن تكون تعريفات النوع _في الكود الخاص بك_ ضمنية ، مما يعني أن المترجم الإنشائي سوف "يكتشفها". لن تقوم أبدًا بتمرير مكتبة تابعة لجهة خارجية من خلال برنامج التحويل البرمجي Typescript ، لذلك لا يعرف المترجم أبدًا ما هي هذه الأنواع. إذا كنت تخطط لاستخدام رمز تابع لجهة خارجية ، فيجب أن تتعلم حقًا كيفية استخدام أداة Definitely Typed وأداة tsd .

ماذا عن جوابbasarat؟

http://stackoverflow.com/a/27434010/1529493

لماذا لا يمكن استيراد الوحدات النمطية التي ليست من نوع TypeScript بدون تعريفات النوع على هذا النحو؟

يمكنهم: const koa = require(‘koa’)

في 21 كانون الثاني (يناير) 2016 ، الساعة 14:47 ، كتب Teoh Han Hui [email protected] :

لماذا لا يمكن استيراد الوحدات التي لا تحتوي على تعريفات النوع على هذا النحو؟

-
قم بالرد على هذه الرسالة الإلكترونية مباشرةً أو اعرضها على GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173574234.

bgrieder أشير إلى صيغة الاستيراد ES6.

(أي أنك تستخدم Commonjs) ، إذا لم يكن الأمر كذلك ، فاستخدم إجابة البصارات declare var

في 21 كانون الثاني (يناير) 2016 ، الساعة 14:48 ، برونو جريدر برونو. كتب [email protected] :

يمكنهم: const koa = require(‘koa’)

في 21 كانون الثاني (يناير) 2016 ، الساعة 14:47 ، كتب تيو هان هوي < [email protected] [email protected] >:

لماذا لا يمكن استيراد الوحدات التي لا تحتوي على تعريفات النوع على هذا النحو؟

-
قم بالرد على هذه الرسالة الإلكترونية مباشرةً أو اعرضها على GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173574234.

أعتقد أن النقطة التي يتم توضيحها هي أن أحد أهداف TypeScript هو أن JS الصالحة يجب أن تكون TS صالحة. بالنسبة إلى بناء جملة الوحدة النمطية ES6 ، يجب أن يجمع TS هذا مع وجود إعلانات النوع أو بدونه. بدون إقرارات النوع ، يجب أن يتم حل بيان import فقط إلى any .

وأنا أتفق تماما مع ذلك.

تضمين التغريدة

في 21 كانون الثاني (يناير) 2016 ، الساعة 14:52 ، كتب Joe Wood [email protected] :

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

وأنا أتفق تماما مع ذلك.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو اعرضها على GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173575301.

FWIW هذا السلوك (توقع كتابة جميع مكتبات الطرف الثالث مسبقًا) هو ما يجعلني أستخدم Flow over TypeScript. على الرغم من أن TypeScript يدعم IDE ، فإن توقع كتابة كل شيء في وقت مبكر ليس بالأمر المعقول حقًا ، خاصةً عندما يكون هناك الكثير من المكتبات التي:

• ليست على DefinitelyTyped
• ليس لديك مجلد ./typings
• ليس لدي الوقت لأكتبها بنفسي

أفضل ألا أضطر إلى محاربة شيء من المفترض أن يساعد في تطوري.

@ danpantry ، لماذا لا تعلن فقط عن نقطة دخول lib الخاصة بك كأي نقطة ، وسيكون المترجم راضيًا عن ذلك:

declare var $: any;

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

أفضل أن يفشل المترجم مبكرًا وبصوت عالٍ (السلوك الحالي) ، بدلاً من السماح لقضايا وقت التشغيل بالتسلل دون أن يلاحظها أحد. أفضل استخدام سطر declare var foo: any للإشارة إلى "هذا غير آمن ، وأنا أعلم ما أفعله".

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

في 21 كانون الثاني (يناير) 2016 ، الساعة 18:42 ، كتب S. Chris Colbert [email protected] :

أفضل أن يفشل المترجم مبكرًا وبصوت عالٍ (السلوك الحالي) ، بدلاً من السماح لقضايا وقت التشغيل بالتسلل دون أن يلاحظها أحد. أفضل أن يكون لدي تصريح var foo صريحًا: أي سطر للإشارة إلى "هذا غير آمن ، وأنا أعلم ما أفعله".

-
قم بالرد على هذه الرسالة الإلكترونية مباشرةً أو اعرضها على GitHub https://github.com/Microsoft/TypeScript/issues/247#issuecomment -173649845.

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

^ ^ ^ هذا ألف مرة. لم يكن هناك ما يشير إلى أنني كنت أفعل شيئًا خاطئًا عندما واجهت هذه المشكلة لأول مرة. استغرق الأمر بعض الوقت الشاق من البحث على Google لمعرفة ما حدث أخيرًا (بالمناسبة ، أعتقد أن هذه المشكلة هي واحدة من الأماكن الوحيدة التي يمكن العثور عليها والتي توثقها). إنه غير ضروري للغاية. ومع Angular 2 الذي أدخل TypeScript بشكل أكبر في الاتجاه السائد ، يمكنني فقط أن أتخيل عدد أسئلة Stack Overflow التي ستأتي من هذا السلوك.

أتفق كثيرًا مع وصف معالجة الخطأ الضعيف واجعله يستورد كأي شيء!

sccolbert أوافق على أنه يجب أن يكون هناك إشعار لكنني لست متأكدًا من أنه يجب أن يكون فاشلاً - تحذير بدلاً من ذلك ، perhap

أتفق مع mhegazy وsccolbert.

أنا أفضل نصوص بناء الإنتاج لدينا (أي خادم CI) للشكوى بصوت عالٍ إذا كان هناك شيء خاطئ.

أهلا يا أصدقاء،
هذا السلوك يدفعني للجنون. ملفات التعريفات غير محدثة أو غير مسجلة في package.json .
في النهاية ، ينتج $ TypeScript JavaScript ، لذا ، حتى نذهب جميعًا إلى هذه اللغة ، يرجى أن تكون لطيفًا مع بقية العالم الذي يوفر مكتبات للغة الأم في أي لغات أخرى مترجمة ، مثل لغتك .
أريد حقًا أن أعرف ما إذا كان TypeScript يريد البقاء (أود أن أقول "للتكامل" كما يبدو غير موجود ، حتى الآن) في النظام البيئي JavaScript أو يريد أن يعيش حياة منفصلة ، مثل الخيار الثاني سيجعلني أذهب إلى شيء آخر.
لتحقيق أن التبديل في الملف .tsconfig سيفي بالغرض ، لذلك يمكننا القول إننا نريد عمليات استيراد صارمة أم لا.
بالنسبة لشكوى CI الصاخبة ، هناك أطر اختبار لذلك في JavaScript . على أي حال ، لن تحصل على فحص الكتابة في وقت التشغيل ، فإن تدقيق الاستيراد السيئ هو المشكلة الأقل أهمية.
أتمنى لك كل خير.

@ devel-pa ، يُقصد من الأخطاء إخبارك أن المترجم ليس لديه فكرة عن ماهية الاستيراد. لا يمكن التحقق من أي استخدام لاحق للاستيراد.

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

أما بالنسبة للمولدة JS. لا يؤدي أي من أخطاء نوع TS إلى إيقاف إنشاء الإخراج. إذا كنت لا تهتم بأخطاء النوع ، فما عليك سوى تجاهلها جميعًا. لا يزال المترجم ينشئ ملفات .js المطابقة.

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

declare module "myLibrary" {
    var a: any;
    export = a;
}

كما هو موضح في # 6615 ، يجب أن يدعم TypeScript شكلاً أقصر من هذا قريبًا.

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

أستطيع أن أفهم الالتباس هنا للأشخاص الجدد في TS. إذا كانوا قد استخدموا بنية الوحدة النمطية ES6 بنشاط في JS ، فلماذا لا يعمل فقط في TS؟ ما هو مميز حول import from أكثر من var x = require - والذي _ يتم التعامل معه على أنه أي ضمني. في الأصل ، كان الاستيراد كلمة رئيسية محددة لـ TS ، لذلك كان يعني ضمنيًا أن المطور يريد أن يتم التعامل مع الوحدة على أنها وحدة نمطية مكتوبة. الآن بما أنه ليس حصريًا لـ TS ، لا أعتقد أنه يمكن إجراء هذا الافتراض.

ضمني - أي أخطاء في التصريحات المتغيرة دون نوع. لكن استخدام متغير غير معرّف لا يزال يمثل خطأ اليوم. بالنسبة إلى jquery ، ما زلت بحاجة إلى declare var $; في مكان ما لكي يعرف المترجم أنك تقصد حقًا أن يكون لديك متغير عام يسمى $ وليس مجرد كتابته بشكل خاطئ. إنه مشابه إلى حد ما للوحدات النمطية ، يحتاج المترجم إلى معرفة أن هناك وحدة تسمى "myLibrary" وهذا ليس اسمًا مكتوبًا بشكل خاطئ. لذا فقط أضف تصريحًا عنها.

على أي حال ، يجب أن يدعم # 6615 إضافة declare module "*"; لمطابقة جميع الوحدات في نظامك ، على الرغم من أنني أعتقد أنك إذا فعلت ذلك ، فلن تحصل على أي مساعدة من أدواتك ، وأنت تهيئ نفسك لمواجهة مؤلمة الانتقال لاحقًا عندما تقرر إزالته.

mhegazy أنا أفهم أسبابك ولكن لدي مشكلة مع هذا الأساس المنطقي

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

يزداد الوضع سوءًا مع الوحدات النمطية المكتوبة (تلك التي تحتوي على الإدخال typings في package.json) التي نفترض أنها تمت كتابتها بشكل صحيح يمكن أن تستخدم بالفعل تلك العناصر النائبة داخليًا.

أفهم أنه لا يمكن منع هذه العناصر النائبة ، لكنني أفضل كثيرًا ألا يتم تشجيعهم على الأقل.
ما يجب الدفاع عنه هو أنه افتراضيًا ، يتحول الاستيراد إلى any وأن المترجم يصدر تحذيرًا في كل عملية تجميع. لذلك على الأقل ، بالبحث في سجلات المترجم / CI ، نعلم أن شيئًا ما قد يكون مريبًا ويحتاج إلى تحسين.

(كجانب ليس ، كما هو مذكور في الصفحة الرئيسية linkscriptlang.org ، تعد Typescript عبارة عن "مجموعة شاملة" من Javascript ، ويجب فقط ابتلاع أي صيغة ES6 صالحة لـ IMHO كما هي)

الحلول البديلة وإخفاء القمامة تحت السجادة هي أسوأ ما يمكن أن يحدث (بجانب ES6 super).
أنا أعمل مع JS libs طوال الوقت ، وعادةً مع الإصدارات الأخيرة كجزء من وظيفتي والترميز الإضافي في المنزل. 90٪ لم تتم كتابتهم أو لديهم ملفات تعريف قديمة ، و 9٪ لم تتم كتابتهم جيدًا (حيث لا يعرف المترجم كيفية إنشاء معرف واحد لجميع الملفات). لا يوجد لديّ دلالات جيدة جدًا ، لنفس السبب السابق ولسبب أن هدفي هو JS ، لا أعتقد أنني يجب أن أهتم باللغة الأصلية.
أيضًا ، لقد رأيت سبب وجود شفرات "غير معروفة". لا ، على الإطلاق ، إذا كان المطورون لا يعرفون ويفهمون ماهية libs المستخدمة ، ولماذا يزعجهم ، فأنا أعرف لماذا أستخدم الأشياء ولماذا أضيف إلى المكدس. التحذير والاختبارات (في حال وجودها) كافية لذلك.
الرجاء ، جافا سكريبت أولاً ، هذا هو الهدف والنظام البيئي. TS هو مجرد ملحق لتحسين الترميز والتحقق من الكتابة في وقت الترجمة ، ولكن فقط لما نقوم ببنائه. الباقي ليس من الأعمال المطبوعة.
أريد أن أذكر أنني كنت ضد nmps peerDependencies أيضًا ، أنا من اختار وليس البرنامج. البرمجة الحتمية ، حبيبي.

ماذا عن استيراد الوحدات من دليل JSPM بدلاً من node_modules؟

تحرير: لقد وجدت تذكرة موجودة -> https://github.com/Microsoft/TypeScript/issues/6012

واجهت للتو مشكلة في دقة وحدة Node ، عند استخدام SystemJS لتحميل دليل:

على ما يبدو ، بينما تدرك Node (وبالتالي TypeScript) أن المسار هو في الواقع دليل وبالتالي يتم تحميل index.ts بدلاً من ذلك ، فإن SystemJS لا يفعل شيئًا من هذا القبيل ، مما يعني أن رمز TS الصحيح سيفشل بالفعل في التحميل في المتصفح.

هذا صحيح أيضًا بالنسبة للوحدات النمطية للعقدة التي تحتوي على نقطة إدخال index.ts / js أو حتى تستخدم خاصية package.json main . هذا أسهل في التعامل معه ، لأنه من السهل (على الرغم من التكرار) إضافة تكوين حزمة إلى SystemJS. هذا ليس بالأمر السهل عند العمل مع الدلائل العشوائية.

ما هو الحل المناسب لذلك؟

دقة الوحدة التلقائية لـ JSPM غير مدعومة حاليًا. يتم تتبع ذلك من خلال https://github.com/Microsoft/TypeScript/issues/6012.

التوصية هي استخدام دعم دقة وحدة تعيين المسار ، راجع https://github.com/Microsoft/TypeScript-Handbook/blob/release-2.0/pages/Module٪20Resolution.md#path -mapping

الإرشادات المذكورة أعلاه هي بداية ، ولكن قد يحتاج بعض الأشخاص إلى القيام بشيء إضافي ... قد تضطر إلى إضافة
<Folder Include="node_modules" />
إلى .njsproj

مزيد من المعلومات

كنت أقوم بالبناء باستخدام gulp ، وكان لدي TypeScriptCompileBlocked في .nsproj. لإصلاح المشكلات في تصحيح نقاط التوقف في VS 15 Preview 5 (كنت أتلقى خطأ "الإطار ليس في الوحدة النمطية") والمشكلات التي كنت أواجهها مع intellisense كان علي إضافتها إلى .njsproj. كان هذا الدليل موجودًا بالفعل عندما قمت باستيراد المشروع ، ولكن تم ضبطه على git-ignore. هذه هي نظريتي حول سبب تجاهل Visual Studio لها (ربما يجب أن يكون لها استثناء تلقائي للوحدات node_modules؟)

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