Typescript: मॉड्यूल विनिर्देशों के अंत में '.js' फ़ाइल एक्सटेंशन जोड़ने का एक तरीका प्रदान करें

यह सिर्फ #13422 से संबंधित नहीं है, यह वही मुद्दा है। लेकिन प्रतिक्रियाएं काफी नकारात्मक रही हैं, इस तथ्य के बावजूद कि मुझे लगता है कि यह एक महत्वपूर्ण मुद्दा है, इसलिए आशा है कि आपके मुद्दे को बेहतर तरीके से प्राप्त किया जाएगा।

ठीक है, मुझे उम्मीद है कि यह जोड़ा गया है, हम वास्तव में अपने अगले टाइपस्क्रिप्ट पॉडकास्ट में इसका उपयोग करके अपने पीओसी पर चर्चा करने के लिए उत्सुक थे, लेकिन ऐसा लगता है कि हमें टाइपस्क्रिप्ट का उपयोग करने के लिए बिना किसी बिल्ड टूल के इंतजार करना होगा।

फिलहाल टाइपस्क्रिप्ट पथों को फिर से नहीं लिखता है। यह निश्चित रूप से कष्टप्रद है, लेकिन आप वर्तमान में .js एक्सटेंशन स्वयं जोड़ सकते हैं।

@justinfagnani @rictic

टिप के लिए धन्यवाद, मैं ऐसा करने के लिए एक शेल/नोड स्क्रिप्ट लिखूंगा।

@DanielRosenwasser एक लेबल के तहत देशी ES6 मॉड्यूल मुद्दों को इकट्ठा करना समझ में आता है?

साथ ही, इस मुद्दे को थोड़ा सामान्य करने के लिए, मुझे नहीं लगता कि यह वास्तव में .js एक्सटेंशन जोड़ने के बारे में है, लेकिन मॉड्यूल विनिर्देशक को वास्तविक पथ पर हल करना, जो भी एक्सटेंशन है।

मैं एक और मुद्दे पर आया हूं जो वास्तव में टाइपस्क्रिप्ट का डोमेन नहीं है लेकिन यह मेरे उपयोग के मामले के लिए है।

मुझे यकीन नहीं है कि node_modules को कैसे संभालना है। आम तौर पर वेबपैक उन्हें ts-loader के माध्यम से कोड में बंडल करता है लेकिन जाहिर है, यह ब्राउज़र द्वारा नहीं समझा जाता है:

import { KeyCodes } from 'vanilla-typescript;
https://github.com/quantumjs/vanilla-typescript/blob/master/events/KeyCodes.ts#L3

यहां जेएस एक्सटेंशन जोड़ना व्यर्थ है।

मुझे लगता है कि टाइपस्क्रिप्ट या सर्वर पर चल रहे यूआरएल रिज़ॉल्वर द्वारा पथ विस्तार करना होगा।

मैं इसके बजाय एक विशिष्ट मामले की सराहना करता हूं, लेकिन मुझे लगता है कि यह एक ऐसा तरीका होगा जिससे टीएस इस क्षेत्र में जल्दी चमक सके। शायद यह tsc कंपाइलर के लिए एक प्लगइन हो सकता है?

इस पर आने वाले किसी भी व्यक्ति के लिए और अंतरिम समाधान चाहता है, मैंने बयान आयात करने के लिए एक जेएस फ़ाइल एक्सटेंशन जोड़ने के लिए एक स्क्रिप्ट लिखी है:

"use strict";

const FileHound = require('filehound');
const fs = require('fs');
const path = require('path');

const files = FileHound.create()
  .paths(__dirname + '/browserLoading')
  .discard('node_modules')
  .ext('js')
  .find();


files.then((filePaths) => {

  filePaths.forEach((filepath) => {
    fs.readFile(filepath, 'utf8', (err, data) => {


      if (!data.match(/import .* from/g)) {
        return
      }
      let newData = data.replace(/(import .* from\s+['"])(.*)(?=['"])/g, '$1$2.js')
      if (err) throw err;

      console.log(`writing to ${filepath}`)
      fs.writeFile(filepath, newData, function (err) {
        if (err) {
          throw err;
        }
        console.log('complete');
      });
    })

  })
});

मैं इसे एक क्ली टूल में बना सकता हूं ..

@justinfagnani की टिप्पणी सिर पर कील ठोकती है।

साथ ही, इस मुद्दे को थोड़ा सामान्य करने के लिए, मुझे नहीं लगता कि यह वास्तव में एक .js एक्सटेंशन जोड़ने के बारे में है, लेकिन मॉड्यूल विनिर्देशक को वास्तविक पथ पर हल करना, जो भी एक्सटेंशन है।

जब तुम लिखते हो

import { KeyCodes } from 'vanilla-typescript';

या उस बात के लिए

import { KeyCodes } from 'vanilla-javascript';

आप एक मॉड्यूल विनिर्देशक से आयात कर रहे हैं, यह एक फ़ाइल हो भी सकती है और नहीं भी हो सकती है लेकिन इस मामले में अंत में .js जोड़ने से एक वैध समाधान होने की संभावना नहीं है।

यदि आप एक NodeJS एप्लिकेशन लिख रहे हैं तो NodeJS आवश्यकता एल्गोरिथ्म विभिन्न प्रस्तावों का प्रयास करेगा, लेकिन यह संभवतः _not_ इसे 'vanilla-typescript.js' तक हल करने का प्रयास करेगा क्योंकि यह एक सार नाम और वसीयत का संदर्भ देता है, सम्मेलन और कॉन्फ़िगरेशन द्वारा, हल किया जाएगा ( शायद विभिन्न प्रयासों पर) '../../../node_modules/vanilla_typescript/index.js' जैसी किसी चीज़ के लिए।

अन्य वातावरण, जैसे कि एएमडी में अंतर है कि वे इस संकल्प को कैसे करते हैं, लेकिन एक चीज जो इन सभी वातावरणों में समान है, वह है एक अमूर्त मॉड्यूल विनिर्देशक की कुछ धारणा।

मैं इसे लाता हूं क्योंकि विभिन्न ब्राउज़रों में ईएस मॉड्यूल कार्यान्वयन शिपिंग कुछ ऐसा लागू करता है जो अधूरा है। यदि हम अपनी सरलतम निर्भरता पर भी विचार करें, और जैसे ही हम सकर्मक लोगों के विषय पर चर्चा करते हैं, तो यह स्पष्ट हो जाता है कि डॉगगोन चीज़ को कॉन्फ़िगर करने का एक तरीका होना चाहिए।

यह बहुत दूर हो सकता है, लेकिन जैसा कि आप खोज रहे हैं, यह (विनम्रता से) अवधारणा कार्यान्वयन का प्रमाण हमें दिया गया है, यह लिखना यथार्थवादी नहीं है।

इसके अलावा, मैं यह नहीं देखता कि टाइपस्क्रिप्ट संभवतः यहां कैसे मदद कर सकता है क्योंकि यह मुद्दा पर्यावरण विशिष्ट है।

@QuantumInformation पथों में .js जोड़ने के लिए आपका प्रोग्राम अच्छा, हल्का, सुरुचिपूर्ण दिखता है, लेकिन आप अंततः अपना मॉड्यूल बंडलर लागू कर रहे हैं। यह मजेदार और दिलचस्प काम है लेकिन यह ब्राउज़र में उपलब्ध मौजूदा कार्यान्वयन में कमियों को प्रदर्शित करता है। यहां तक ​​​​कि अगर आप शुद्ध जावास्क्रिप्ट में लिखते हैं, तब भी आपको अपनी संक्रमणीय रूप से आयातित निर्भरताओं को संकलित और पैकेज करने के लिए कुछ चाहिए।

मैं मूल रूप से केवल इस तथ्य के बारे में शेखी बघार रहा हूं कि जारी किए गए ES मॉड्यूल का कार्यान्वयन पर्याप्त से काफी दूर है।

फिर से NodeJS, RequJS AMD, Dojo AMD, Sea Package Manager, CommonJS, Browserify, Webpack, SystemJS, सभी के काम करने के अपने अलग तरीके हैं लेकिन वे सभी अमूर्त नाम समाधान प्रदान करते हैं। उन्हें इसे प्रदान करना होगा क्योंकि यह _मौलिक_ है।

मेरा व्यंग्य पढ़ने के लिए धन्यवाद।

सुनिश्चित नहीं है कि TS के किस संस्करण ने इसे जोड़ा है, लेकिन ' ./file.js' जैसे आयात अब काम करते हैं (भले ही फ़ाइल वास्तव में file.ts हो)।
टाइपस्क्रिप्ट फ़ाइल को ठीक से हल करता है, और लक्ष्य के लिए संपूर्ण .js आयात को आउटपुट करता है।
lit-html इसका उपयोग करें: https://github.com/PolymerLabs/lit-html/blob/master/src/lib/repeat.ts#L15

टीएस 2.0 के बाद से यह संभव है। लेकिन वेबपैक जैसे उपकरण इसका समर्थन नहीं करते हैं इसलिए अंत में यह बेकार है।

यह बेकार है अगर कोई स्रोतों पर ts-loader का उपयोग कर रहा है (सबसे आम उपयोग-मामला)।
लक्ष्य (आमतौर पर "डिस्ट" फ़ोल्डर) को बंडल करना अभी भी संभव है, क्योंकि वास्तविक जेएस फ़ाइल वहां मौजूद है और संकल्प प्रक्रिया द्वारा पाई जा सकती है।

मुझे आश्चर्य है कि क्या मैं ts-loader में एक त्वरित परिवर्तन लागू कर सकता हूं जो लक्ष्य कोड से .js एक्सटेंशन को स्ट्रिप करता है, जिससे कोई सीधे स्रोतों से बंडल कर सकता है।

ऐसा करने के लिए स्वतंत्र महसूस करें, यह बहुत अच्छा होगा। मैंने कुछ महीने पहले मुख्य वेबपैक टीएस लोडर, जैसे टीएस लोडर पर इस मुद्दे को पोस्ट किया था, और मुझे काफी बुरी तरह से प्राप्त किया गया है ...

जानकारी के लिए, रोलअप टाइपस्क्रिप्ट प्लगइन में कोई समस्या नहीं है, एक प्रमाण के रूप में यह संभव है।

मैं यह देखने में विफल रहता हूं कि ब्राउज़र लोडर कार्यान्वयन और WGATWG लोडर स्पेक कम से कम _some_ कॉन्फ़िगरेशन का समर्थन करने तक यह क्या अच्छा करता है क्योंकि अधिकांश निर्भरताएं सही ढंग से लोड नहीं होंगी।

मेरे दृष्टिकोण से, इनमें से कोई भी तब तक मायने नहीं रखता जब तक कि आयात पर देशी लोडर का उपयोग करना व्यावहारिक न हो, जो एक मनमाना स्ट्रिंग शाब्दिक विनिर्देशक को संदर्भित करता है, कुछ ऐसा जो अभी तक एक URL नहीं हो सकता है, और जो एक परिवर्तन से गुजरता है जो पैदावार देता है वास्तविक यूआरएल।

तब तक हम SystemJS और Webpack जैसे टूल्स पर निर्भर रहेंगे।

मैंने एक छोटा ट्रांसफॉर्मर बनाया जो आयात/निर्यात विवरणों से '.js' को अलग करता है।
मैंने tsutils टाइप गार्ड का इस्तेमाल किया, इसलिए yarn add tsutils --dev । (पैकेज आमतौर पर वैसे भी स्थापित किया जाता है यदि आपके प्रोजेक्ट में tslint है, तो अतिरिक्त निर्भरता)

https://gist.github.com/AviVahl/40e031bd72c7264890f349020d04130a

इसका उपयोग करके, कोई उन ts फ़ाइलों को बंडल कर सकता है जिनमें .js ( webpack और ts-loader का उपयोग करके) के साथ समाप्त होने वाली फ़ाइलों से आयात होता है, और अभी भी esm मॉड्यूल में स्रोतों को ट्रांसपाइल करता है जो इसमें लोड हो सकते हैं ब्राउज़र ( tsc का उपयोग करके)।

संभवत: सीमित संख्या में उपयोग-मामले हैं जहां यह उपयोगी है।

संपादित करें: मैंने निर्यात के साथ काम करने के लिए जिस्ट को अपडेट किया है। यह अनुभवहीन है और अनुकूलित नहीं है, लेकिन काम करता है।

इस मुद्दे पर कोई आंदोलन?

विस्तार का यह मामला हमें टाइपस्क्रिप्ट की शुरुआत में वापस ले जाता है और tsconfig.json की आवश्यकता क्यों थी और compilerOptions सेटिंग में module विकल्प क्यों जोड़ा गया था।

चूंकि extension के विस्तार का मामला केवल ES2015+ के लिए मायने रखता है क्योंकि आवश्यकता काफी अच्छी तरह से हल करने में सक्षम है, इसे संकलक द्वारा जोड़ा जाना चाहिए जब लक्षित कोड ES2015+ हो।

1. .js के लिए .ts
2. .jsx के लिए .tsx

हैलो, मैं इतनी देर से आ रहा हूं लेकिन मदद करना चाहता हूं। मुझे यह समझने में परेशानी हो रही है कि यहां क्या समस्या है। ओपी उदाहरण से यह है:

import { ModalBackground } from './ModalBackground';

क्या समस्या यह है कि हम नहीं जानते कि './ModalBackground' क्या है? यह एक फ़ोल्डर या कुछ और हो सकता है?

अगर हम पूरे प्रोजेक्ट पर tsc चलाते हैं और हम जानते हैं कि ModalBackground.ts मौजूद है, तो हमें पता चलेगा कि एक्सटेंशन जोड़ना सुरक्षित है, नहीं?

यह मुद्दा भी कुछ ऐसा है जिसमें RxJS समुदाय बहुत रुचि रखता है। इसके समाधान की समय-सीमा क्या है? क्या इसे भी प्राथमिकता दी जाती है? क्या कोई तीसरा पक्ष परिवर्तन है जो मदद करेगा?

मुझे सच में यकीन नहीं है कि अगर यह एक समस्या है तो आउटपुट लक्ष्य ES2015 है? यह शायद ES2015ब्राउज़र क्षमता के क्षेत्र में आ सकता है। इससे भी अधिक, @justinfagnani क्या हम चिंता करने के लिए एक मंच लक्ष्य के रूप में इसके लिए जोर नहीं दे सकते हैं? (शायद अलग धागे में कांटा करने की जरूरत है)।

इससे भी अधिक, @justinfagnani क्या हम चिंता करने के लिए एक मंच लक्ष्य के रूप में इसके लिए जोर नहीं दे सकते हैं? (शायद अलग धागे में कांटा करने की जरूरत है)।

हां, निश्चित रूप से बहुत से लोग चाहते हैं कि मंच किसी न किसी प्रकार के नंगे-विनिर्देशकों का समर्थन करे, लेकिन वर्तमान तथ्य यह है कि ऐसा नहीं है और उन्हें जोड़ने का कोई प्रस्ताव भी नहीं है। हमें उस संपूर्ण, संभावित बहु-वर्षीय, प्रक्रिया से गुजरने की आवश्यकता है।

यहां तक ​​​​कि अगर हमें अंततः नंगे-विनिर्देशक समर्थन मिलता है, तो यह अविश्वसनीय रूप से असंभव है कि यह नोड-मॉड्यूल-रिज़ॉल्यूशन के रूप में होगा। तो फाइलों को खोजने के लिए टीएससी द्वारा उपयोग किए जाने वाले रिज़ॉल्यूशन एल्गोरिदम और ब्राउज़र द्वारा उपयोग किए जाने वाले रिज़ॉल्यूशन एल्गोरिदम (और संभवतः यहां तक ​​​​कि नोड के मूल मॉड्यूल समर्थन, afaik) के बीच एक बेमेल होने जा रहा है।

यह बहुत अच्छा होगा यदि tsc किसी अन्य मॉड्यूल को खोजने के लिए उपयोग किए जाने वाले पथ को संशोधित कर सके ताकि डाउनस्ट्रीम टूल और वातावरण परस्पर विरोधी राय के साथ विनिर्देशकों की व्याख्या न करें।

@justinfagnani वे पहले से ही एक परस्पर विरोधी राय के साथ व्याख्या कर रहे हैं। TS एक JS फ़ाइल तैयार करता है जिसे वह JS कोड बनाता है जो इंगित नहीं करता है। ES6 जावास्क्रिप्ट को करने के आधिकारिक तौर पर सही तरीके से सबसे नज़दीकी चीज है, इसलिए यदि टाइपस्क्रिप्ट द्वारा निर्मित ES6 कोड गलत है, तो यह एक बग सादा और सरल है। किसी प्रस्ताव के लिए प्रतीक्षा करने की आवश्यकता नहीं है और ऐसे में, बस टाइपस्क्रिप्ट की बग को ठीक करें। लेकिन आज लोगों को लगता है कि अगर वे किसी चीज में दोष नहीं ढूंढते हैं और अभिनय से पहले प्रस्ताव की 10 परतों में डालते हैं, तो वे बौद्धिक रूप से कार्य नहीं कर रहे हैं। मुझे एक विराम दें।

@aluanhaddad यह सच है कि कई परियोजनाओं से लाभ नहीं होगा, लेकिन कुछ परियोजनाएं हैं जो एनपीएम निर्भरताओं का उपयोग नहीं करती हैं (या जो किसी भी तरह से एनपीएम निर्भरताओं को संभालने में सक्षम हैं), इसलिए उन परियोजनाओं को लाभ होगा।

यह टाइपस्क्रिप्ट पुस्तकालयों के लिए भी बहुत उपयोगी है, जिन्हें ES6 में संकलित किया गया है। अभी उन पुस्तकालयों को ब्राउज़र में मूल रूप से उपयोग नहीं किया जा सकता है, लेकिन यदि टाइपस्क्रिप्ट ने .js एक्सटेंशन आउटपुट किया तो वे काम करेंगे।

@justinfagnani इसे अभी तक मानकीकृत या कार्यान्वित नहीं किया गया है, लेकिन ब्राउज़र में npm संकुल को काम करने का प्रस्ताव है।

पैकेज नाम मैप को टाइपस्क्रिप्ट कंपाइलर या किसी अन्य टूल द्वारा स्वचालित रूप से जेनरेट किया जा सकता है।

तो मैं इसे फिर से देख रहा हूं, क्या मेरी नोड स्क्रिप्ट के अलावा इसका कोई अच्छा समाधान था?

मैं इस समाधान का उपयोग कर रहा हूं:
https://github.com/Microsoft/TypeScript/issues/16577#issuecomment -343610106

लेकिन मेरा मानना ​​​​है कि यदि मॉड्यूल में फ़ाइल एक्सटेंशन नहीं है, लेकिन सही MIME प्रकार के साथ परोसा जाता है, तो इसे हल करना चाहिए।

इस पर कोई आंदोलन?

शायद https://github.com/Microsoft/TypeScript/pull/25073 इसे हल कर सकता है?

@Kingwl क्या आप कुछ अन्य फ़ाइल एक्सटेंशन का समर्थन करेंगे? जैसे .mjs .es .esm ।

शायद नहीं, यह एक और विशेषता है

यह भी कैसे बात है? टाइपस्क्रिप्ट कंपाइलर _knows_ कि लक्ष्य आउटपुट एक JS फ़ाइल है। मैं इन थ्रेड्स को 15 मिनट से ब्राउज़ कर रहा हूं और मुझे अभी भी समझ में नहीं आया कि यह एक्सटेंशन को क्यों छोड़ देता है।

इस मुद्दे के संदर्भों की संख्या से, मुझे लगता है कि यह सही दिशा में आगे बढ़ रहा है। मैं जल्द ही एक और कोशिश करूंगा।

यह भी कैसे बात है? टाइपस्क्रिप्ट कंपाइलर _knows_ कि लक्ष्य आउटपुट एक JS फ़ाइल है। मैं इन थ्रेड्स को 15 मिनट से ब्राउज़ कर रहा हूं और मुझे अभी भी समझ में नहीं आया कि यह एक्सटेंशन को क्यों छोड़ देता है।

ऐसे आम उपयोग के मामले हैं, जिनका लोग उपयोग करते हैं, जहां विस्तार की कमी अधिक लचीली बुनियादी ढांचे की अनुमति देती है। नोड को हुक की आवश्यकता होती है और वेबपैक लोडर ऐसे दो मामले हैं।

यह भी कैसे बात है? टाइपस्क्रिप्ट कंपाइलर _knows_ कि लक्ष्य आउटपुट एक JS फ़ाइल है। मैं इन थ्रेड्स को 15 मिनट से ब्राउज़ कर रहा हूं और मुझे अभी भी समझ में नहीं आया कि यह एक्सटेंशन को क्यों छोड़ देता है।

ऐसे आम उपयोग के मामले हैं, जिनका लोग उपयोग करते हैं, जहां विस्तार की कमी अधिक लचीली बुनियादी ढांचे की अनुमति देती है। नोड को हुक की आवश्यकता होती है और वेबपैक लोडर ऐसे दो मामले हैं।

इनमें से कोई भी ब्राउज़र मॉड्यूल की परवाह नहीं करता है।

क्या यह .js एक्सटेंशन निकालने के लिए ऑप्ट-इन फ़्लैग जोड़ने के लिए टाइपस्क्रिप्ट टीम को मार देगा? हम जानते हैं कि हम यहां क्या कर रहे हैं, या एक दर्जन धागे (खुले और बंद दोनों) अभी भी उत्तर और भ्रमित प्रश्न नहीं होंगे। हम समझते हैं कि यह TS की कमी नहीं है, लेकिन अगर TS हमारे JS संकटों को हल करने के लिए यहाँ है, तो कृपया इस दुःख को सूची में जोड़ें।

अस्वीकरण:

हां, मैं समझता हूं कि इससे एक टन लोग यहां समस्याएं पोस्ट कर सकते हैं कि "आपने वेबपैक की शुरुआत की" लेकिन वास्तव में, उन लोगों के लिए कठिन स्तन। यह ऑप्ट-इन होना चाहिए।

बीटीडब्ल्यू, टाइपस्क्रिप्ट स्रोत के माध्यम से खुदाई करते हुए, मुझे importModuleSpecifierEnding दिखाई देता है - क्या यह (ab) एमिटर को .js अंत का उपयोग करने के लिए उपयोग किया जा सकता है?

हो सकता है कि इस प्रस्ताव को tsconfig स्कीमा के साथ मश करें? https://github.com/domenic/package-name-maps

इस बिंदु पर मुझे खुशी होगी अगर टाइपस्क्रिप्ट केवल tsconfig में निर्दिष्ट paths का उपयोग करके आयात को स्वचालित रूप से फिर से लिख सकता है। ब्राउज़र समर्थन के बिना भी जो शायद मेरे लिए अधिकांश दर्द बिंदुओं को हल कर देगा।

कोई अपडेट्स? इस मुद्दे को हल करने का कोई प्रयास? हमारे पास डिफ़ॉल्ट रूप से es मॉड्यूल का समर्थन करने वाले सभी प्रमुख ब्राउज़र हैं, उनके लिए मानक के लिए एक्सटेंशन की आवश्यकता होती है। मैं समझता हूं कि हम इसे मैन्युअल रूप से जोड़ सकते हैं और टीएससी इसे समझ जाएगा, लेकिन यह अनिवार्य नहीं होना चाहिए, यह सिर्फ काम क्यों नहीं कर सकता?
रोने के लिए खेद है लेकिन यह मुद्दा अब बहुत पुराना है और अभी तक कुछ भी नहीं किया गया है...

यह भी कैसे बात है? टाइपस्क्रिप्ट कंपाइलर _knows_ कि लक्ष्य आउटपुट एक JS फ़ाइल है। मैं इन थ्रेड्स को 15 मिनट से ब्राउज़ कर रहा हूं और मुझे अभी भी समझ में नहीं आया कि यह एक्सटेंशन को क्यों छोड़ देता है।

ऐसे आम उपयोग के मामले हैं, जिनका लोग उपयोग करते हैं, जहां विस्तार की कमी अधिक लचीली बुनियादी ढांचे की अनुमति देती है। नोड को हुक की आवश्यकता होती है और वेबपैक लोडर ऐसे दो मामले हैं।

फिर, हो सकता है कि टाइपस्क्रिप्ट कंपाइलर एक्सटेंशन जोड़ने का विकल्प स्वीकार कर सके या नहीं। हो सकता है कि यह एक्सटेंशन जोड़ने (या नहीं) करने के लिए रेगेक्स का एक सेट भी स्वीकार कर सके, जैसे विकल्प शामिल करें (https://www.typescriptlang.org/docs/handbook/tsconfig-json.html)।

हाँ, यह कम से कम एक बार पहले ही प्रस्तावित किया जा चुका है, क्यों न इसे ध्यान में रखा जाए? TS में पहले से ही कुछ प्रायोगिक विशेषताएं हैं जो भविष्य में एक बार ब्राउज़र में लागू होने के बाद बदल सकती हैं, लेकिन TS में पहले से ही उन अस्थिर चश्मे के लिए झंडे हैं। क्यों न केवल एक प्रयोगात्मक ध्वज addImportsExtensions है, जहां यह केवल module += '.js' करेगा, बस! कोई फंकी लॉजिक नहीं, कोई अतिरिक्त फीचर नहीं। यदि आप इसे एक अलग लक्ष्य के रूप में रखना पसंद करते हैं तो यह एक अलग लक्ष्य हो सकता है। इसके अलावा, यदि आप उपरोक्त में से किसी को भी स्वीकार करते हैं, तो मैं व्यक्तिगत रूप से tsc कोड के माध्यम से खोदूंगा और उसके लिए एक PR बनाऊंगा, बस अपना समय बर्बाद नहीं करना चाहता अगर इसे वैसे भी स्वीकार नहीं किया जाएगा।

आप उत्सर्जित कोड में आयात को फिर से लिखने के लिए बस एक कस्टम ट्रांसफ़ॉर्म का उपयोग कर सकते हैं ('.js' जोड़कर या मॉड्यूल आयात के हल किए गए पथ का उपयोग करके)।

टाइपस्क्रिप्ट ट्रांसफॉर्म कैसे लिखें
ttypescript: tsc के लिए रैपर जो संकलन के दौरान परिवर्तन लागू करता है

हो सकता है कि पहले से ही एक मौजूदा परिवर्तन हो जो आपको चाहिए।

मुझे पता है कि यह संभव है, मैंने कंपाइलर एपीआई के साथ काफी कुछ खेला है (हालांकि जितना मैं चाहता हूं उतना नहीं)। बात यह है कि, यह परियोजना के लिए अतिरिक्त उपकरण जोड़ता है और अतिरिक्त उपकरणों में अतिरिक्त अनुरक्षक होते हैं जो मुद्दों पर तेजी से प्रतिक्रिया कर सकते हैं या नहीं कर सकते हैं (अक्सर उनकी गलती से नहीं, हम सभी के पास जीवन और काम है)। छोटी परियोजनाओं को अक्सर छोड़ दिया जाता है, और सब कुछ स्वयं करने से केवल हमारे ऊपर जिम्मेदारी बढ़ जाती है इसलिए व्यापार कोड का ध्यान रखने के बजाय हम टूलिंग पर समय व्यतीत करते हैं।
उपरोक्त को ध्यान में रखते हुए, बहुत सी परियोजनाएं इसे समाधान के रूप में भी नहीं मानतीं और इसके बजाय रोलअप इत्यादि जैसे अतिरिक्त बिल्ड चरण जोड़ती हैं, जो अतिरिक्त कॉन्फ़िगरेशन ओवरहेड जोड़ती है और हमें अतिरिक्त रखरखाव लागत पर वापस लाती है।
संक्षेप में: मैं अपना समय एक पीआर पर आधिकारिक टीएस के लिए बिताना पसंद करता हूं, जहां मुझे और समुदाय दोनों को इससे लाभ होगा, इसे एक कस्टम समाधान पर खर्च करने के बजाय जिसे मैं अंततः छोड़ सकता हूं (समय या कई अन्य कारणों से नहीं होने के कारण) ), या जो दुनिया में किसी और के द्वारा इस्तेमाल नहीं किया जा सकता है।

@ajafff ​​यह एक समाधान हो सकता है, लेकिन मुझे लगता है कि मुख्य समस्या निम्नलिखित है: टाइपस्क्रिप्ट ट्रांसपिलर ब्राउज़र में गलत स्रोत कोड उत्पन्न करता है। परिवर्तन होना अच्छा है, लेकिन मैं इसे वर्कअराउंड के रूप में देखता हूं। मुझे आश्चर्य है कि क्या मुझे ट्रांसपिलेशन विवरण की परवाह है और मुझे अपना खुद का परिवर्तन लागू करने की आवश्यकता है या ऐसा कुछ है जिसे संकलक द्वारा प्रबंधित किया जाना चाहिए।

परिवर्तन वास्तव में एक शक्तिशाली उपकरण हैं, हम एक परिवर्तन के रूप में एक नया ट्रांसपिलर लिख सकते हैं, लेकिन मुझे लगता है कि यह सही तरीका नहीं है।

हाँ, यह कम से कम एक बार पहले ही प्रस्तावित किया जा चुका है, क्यों न इसे ध्यान में रखा जाए? TS में पहले से ही कुछ प्रयोगात्मक विशेषताएं हैं

टाइपस्क्रिप्ट में ठीक एक प्रयोगात्मक ध्वज है जिसे 3 साल पहले जोड़ा गया था, और यह एक ईसीएमएस्क्रिप्ट प्रस्ताव के लिए था जो अब वर्तमान प्रस्ताव के साथ संगत नहीं है।

टाइपप्रति ट्रांसपिलर ब्राउज़र में गलत स्रोत कोड उत्पन्न करता है

मैं आपकी अपेक्षाओं को समझता हूं, लेकिन यह देखते हुए कि संकलक आपके द्वारा लिखे गए पथों को फिर से नहीं लिखता है, मुझे आश्चर्य है कि आप अपने कोड के आयात को "गलत" नहीं मानते हैं। मैं

मुझे खेद है @DanielRosenwasser , क्या आपने npm नाम की चीज़ के बारे में सुना है? लोग अपने पैकेज वहां पोस्ट करते हैं ताकि हम सभी इसका इस्तेमाल कर सकें। मैं समझता हूं कि आप मेरे बारे में बहुत अधिक सोच सकते हैं, लेकिन दुख की बात है कि मैं उनमें से अधिकांश का लेखक नहीं हूं इसलिए मैं उन्हें एक्सटेंशन जोड़कर संपादित नहीं कर सकता।
अगर मेरी परियोजनाओं ने केवल मेरे कोड का उपयोग किया है, तो मैं टाइपस्क्रिप्ट लाने के लिए और अधिक आभारी रहूंगा, क्योंकि यह वास्तव में कोडिंग (वेबस्टॉर्म के अलावा) में मेरा दाहिना हाथ है। हालांकि मैं तीसरे पक्ष के पैकेज का उपयोग कर रहा हूं जैसे मुझे लगता है कि हम में से अधिकांश और उनमें जरूरी नहीं कि एक्सटेंशन शामिल हों। कुछ प्रोजेक्ट, जैसे rxjs, सचमुच इस उम्मीद के साथ प्रतीक्षा करते हैं कि टाइपस्क्रिप्ट एक्सटेंशन जोड़ने का तरीका प्रदान करेगा, अन्यथा इसके लिए उन्हें पूरी बिल्ड प्रक्रिया को बदलने की आवश्यकता होगी, इसलिए हम उत्पाद के बजाय टूल पर अतिरिक्त समय बिताने के लिए वापस आ गए हैं।
अब कृपया, क्या आप केवल 3 प्रश्नों के उत्तर दे सकते हैं?

1. क्या टाइपप्रति टीम इस सुविधा को भेजने के लिए तैयार है?
2. यदि हाँ, तो क्या आप पीआर स्वीकार करेंगे?
3. यदि नहीं, तो आप इसे कब जारी करने की योजना बना रहे हैं?

यदि पहले प्रश्न का उत्तर 'नहीं' है, तो कृपया इस मुद्दे को आधिकारिक रूप से घोषित करते हुए बंद करें कि आप इस सुविधा को शिप करने के लिए तैयार नहीं हैं, अगर यह नहीं आता है तो दूसरों को प्रतीक्षा न करें।

हाँ, यह कम से कम एक बार पहले ही प्रस्तावित किया जा चुका है, क्यों न इसे ध्यान में रखा जाए? TS में पहले से ही कुछ प्रयोगात्मक विशेषताएं हैं

टाइपस्क्रिप्ट में ठीक एक प्रयोगात्मक ध्वज है जिसे 3 साल पहले जोड़ा गया था, और यह एक ईसीएमएस्क्रिप्ट प्रस्ताव के लिए था जो अब वर्तमान प्रस्ताव के साथ संगत नहीं है।

टाइपप्रति ट्रांसपिलर ब्राउज़र में गलत स्रोत कोड उत्पन्न करता है

मैं आपकी अपेक्षाओं को समझता हूं, लेकिन यह देखते हुए कि संकलक आपके द्वारा लिखे गए पथों को फिर से नहीं लिखता है, मुझे आश्चर्य है कि आप अपने कोड के आयात को "गलत" नहीं मानते हैं। मैं

यह एक अच्छा बिंदु है @DanielRosenwasser , मैंने अभी अपना कोड सही माना है क्योंकि यह टाइपस्क्रिप्ट स्पेक (https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#11.3) को पढ़ना सही लगता है।

मुझे पूरा यकीन है कि आपने ईसीएमएस्क्रिप्ट स्पेक्स पढ़ लिए हैं। कल्पना में यह निर्धारित नहीं किया जाता है कि मॉड्यूल को एक्सटेंशन के साथ समाप्त होना चाहिए या नहीं। चश्मे में, मॉड्यूल आयात को HostResolveImportedModule एल्गोरिदम का उपयोग करके हल किया जाता है, लेकिन परिभाषा अस्पष्ट है। समस्या ईसीएमएस्क्रिप्ट स्पेक नहीं है। समस्या यह है कि ब्राउज़र मॉड्यूल को इस तरह हल करते हैं जैसे कि ऐनक में परिभाषित [ModuleRequest] संसाधनों के लिए एक पथ था।

इसे ध्यान में रखते हुए, बस भाषा के होम पेज पर जाएं: https://www.typescriptlang.org/ ।

पृष्ठ के पाद लेख में आप निम्नलिखित पंक्तियाँ पढ़ सकते हैं:

जावास्क्रिप्ट के साथ शुरू और समाप्त होता है

टाइपस्क्रिप्ट उसी सिंटैक्स और शब्दार्थ से शुरू होता है जिसे आज लाखों जावास्क्रिप्ट डेवलपर्स जानते हैं। मौजूदा जावास्क्रिप्ट कोड का उपयोग करें, लोकप्रिय जावास्क्रिप्ट पुस्तकालयों को शामिल करें, और जावास्क्रिप्ट से टाइपस्क्रिप्ट कोड को कॉल करें।

टाइपस्क्रिप्ट स्वच्छ, सरल जावास्क्रिप्ट कोड को संकलित करता है जो किसी भी ब्राउज़र पर, Node.js में, या किसी भी जावास्क्रिप्ट इंजन में चलता है जो ईसीएमएस्क्रिप्ट 3 (या नया) का समर्थन करता है।

आप एक कोड का वादा करते हैं जो हर ब्राउज़र पर चलता है, लेकिन यह सच नहीं लगता है, इसलिए यह समस्या एक वर्ष से अधिक समय तक बनी रहती है।

जैसा कि @Draccoz बताता है, हम सिर्फ यह जानना चाहते हैं कि आप इस मुद्दे पर क्या कर रहे हैं। लेकिन इस अंक में अपने होम पेज में एक बात और इसके विपरीत पढ़ने के लिए थोड़ा निराशा होती है।

नहीं, हम इससे संबंधित कुछ भी शिप करने के लिए तैयार नहीं हैं, जब तक कि नोड में ES इंटरऑप जैसी चीज़ों के बारे में कम से कम स्पष्टता न हो और ट्रांज़िटिव डिपेंडेंसीज़ को शिपिंग करने के लिए एक उचित रणनीति जो आप पहली बार में npm से उपयोग करेंगे। यदि आप टाइपस्क्रिप्ट का उपयोग नहीं कर रहे थे, तो आपको निर्भरता प्रबंधन और संकल्प के आसपास एक ही समस्या होगी, इसलिए हमारे लिए कुछ ऐसा करने का कोई मतलब नहीं है कि जेएस पारिस्थितिकी तंत्र बड़े पैमाने पर स्वतंत्र रूप से विकसित हो सके। लेकिन अगर उन मुद्दों का समाधान भी हो जाता है, तो भी मैं इस बात की गारंटी नहीं दे सकता कि हम यहां इस अवधि में कोई बदलाव करेंगे।

आप एक कोड का वादा करते हैं जो हर ब्राउज़र पर चलता है, लेकिन यह सच नहीं लगता है, इसलिए यह समस्या एक वर्ष से अधिक समय तक बनी रहती है।

मुझे लगता है कि यह व्याख्या बहुत शाब्दिक है। जब आप इसे ब्राउज़र में चलाते हैं तो var fs = require('fs') काम नहीं करता है, HTMLDivElement नोड में परिभाषित नहीं है, और String.prototype.startsWith पुराने ब्राउज़र पर काम नहीं करता है। इसे हल करने के लिए, लोगों ने टाइपस्क्रिप्ट के बाहर टूल और लाइब्रेरी/पॉलीफिल बनाए हैं क्योंकि वे व्यापक जावास्क्रिप्ट पारिस्थितिकी तंत्र पर लागू होते हैं।

तो क्या आप कृपया इस मुद्दे को बंद कर सकते हैं? यह अन्य परियोजनाओं के लिए एक अवरोधक है जो टीएस द्वारा इसे करने की प्रतीक्षा कर रहे हैं या घोषणा करते हैं कि आप इसे नहीं कर रहे हैं। यदि आप केवल एक साधारण झंडा नहीं जोड़ सकते हैं, तो इस मुद्दे को बंद करें और दूसरों को अपने निर्णयों से अवगत कराएं।

@DanielRosenwasser आपकी त्वरित प्रतिक्रिया के लिए धन्यवाद, मैं वास्तव में इसकी सराहना करता हूं। मुझे लगता है कि यह एक बुद्धिमान विकल्प है।

मुझे लगता है कि यह व्याख्या बहुत शाब्दिक है। जब आप इसे ब्राउज़र में चलाते हैं तो var fs = आवश्यकता ('fs') काम नहीं करता है, HTMLDivElement को नोड में परिभाषित नहीं किया गया है, और String.prototype.startsWith पुराने ब्राउज़र पर काम नहीं करता है। इसे हल करने के लिए, लोगों ने टाइपस्क्रिप्ट के बाहर टूल और लाइब्रेरी/पॉलीफिल बनाए हैं क्योंकि वे व्यापक जावास्क्रिप्ट पारिस्थितिकी तंत्र पर लागू होते हैं।

बेशक यह है, लेकिन टाइपस्क्रिप्ट के बारे में कुछ नहीं जानने वाला कोई और क्या सोच सकता है? तथ्य यह है कि मेरी व्याख्या बहुत शाब्दिक है, यह तथ्य उतना ही सच है कि यह पाठ किसी को भी "भ्रमित" कर सकता है जो टाइपस्क्रिप्ट के बारे में कुछ नहीं जानता है।

हो सकता है कि आप वास्तविक व्यवहार को दर्शाने के लिए अपने दस्तावेज़ (https://www.typescriptlang.org/docs/handbook/modules.html) अपडेट कर सकें।

@DanielRosenwasser आपकी प्रतिक्रिया के लिए फिर से धन्यवाद। मैं एक साल से कुछ इसी तरह का इंतजार कर रहा हूं।

मुझे यह सुविधा इसलिए चाहिए थी ताकि मैं देख सकूं कि मैं बिना किसी बिल्ड टूल के किस तरह का वेब ऐप बना सकता हूं। तब तक मैं उस स्क्रिप्ट का उपयोग कर सकता हूं जो मैंने पहले लिखी थी।

मेरे जैसे लोगों के लिए आज ब्राउज़र में ES मॉड्यूल और टाइपस्क्रिप्ट का उपयोग करने में सक्षम होने के समाधान की तलाश में, मुझे https://github.com/guybedford/es-module-shims मिला। यह पैकेज नाम के नक्शे के लिए एक प्रकार के पॉलीफिल के रूप में कार्य करता है, जबकि हम कल्पना को अंतिम रूप देने और ब्राउज़र के कार्यान्वयन की प्रतीक्षा करते हैं। टाइपस्क्रिप्ट (टीएस कंपाइलर से अलग) में एक साधारण वेब ऐप को लिखते समय यह किसी भी बिल्ड टूल्स (मेरी समस्या भी) का उपयोग नहीं करने की @QuantumInformation की समस्या हल करता है।

import 'knockout'

export class MyViewModel {
    greeting: KnockoutObservable<string>
    target: KnockoutObservable<string>
    constructor() {
        this.greeting = ko.observable('hello')
        this.target = ko.observable('world')
    }
}

<!DOCTYPE html>


md5-f28d4b503a1603c40bfeb342f341bfbe


<main>
    <span data-bind='text: `${greeting()} ${target()}`'></span>
    <script type='module-shim'>
        import 'knockout'
        import { MyViewModel } from 'index'
        ko.applyBindings(new MyViewModel())
    </script>
</main>

सिद्धांत रूप में, एक बार जब पैकेज नाम मानचित्र ब्राउज़र द्वारा समर्थित हो जाते हैं, तो आप अपनी HTML फ़ाइलों में type='module-shim' को type='module' $ के साथ ढूंढ/बदल सकते हैं और पैकेजमैप स्क्रिप्ट को पैकेजमैप में शामिल करने के लिए अंतिम रूप देने के लिए जो कुछ भी समाप्त होता है उसे बदल सकते हैं। कल्पना

शायद यह भी ध्यान देने योग्य है कि .js एक्सटेंशन ब्राउज़र या किसी भी चीज़ द्वारा अनिवार्य नहीं है - आप हमेशा अपने वेबसर्वर को अधिक unpkg के समान कॉन्फ़िगर कर सकते हैं और .js फ़ाइलों की सेवा कर सकते हैं एक्सटेंशन रहित अनुरोध URL। यह सब वेबसर्वर पक्ष पर विन्यास योग्य है।

@weswigham हालांकि बहुत समस्याग्रस्त हो सकता है, क्योंकि tsc (और क्लासिक नोड मॉड्यूल रिज़ॉल्यूशन) को पता चल जाएगा कि ./foo और ./foo.js एक ही फ़ाइल को संदर्भित करते हैं, लेकिन ब्राउज़र उनके साथ अलग व्यवहार करेंगे, भले ही वेबसर्वर रीडायरेक्ट करता है। आपको यह सुनिश्चित करना होगा कि आप प्रत्येक आयात पर ठीक उसी तरह एक फ़ाइल का संदर्भ लें।

वैसे, यह समस्या टाइपस्क्रिप्ट उत्पन्न मॉड्यूल को आज ब्राउज़र में उपयोग होने से नहीं रोकती है। बस हमेशा .js एक्सटेंशन वाली फ़ाइलें आयात करें। tsc सही काम करता है और .ts फ़ाइल से प्रकारों को हल करता है, और आपको ब्राउज़र संगतता मिलती है।

@weswigham ध्यान रखें कि ऐसी स्थितियां हैं जहां आप वेबसर्वर तक पहुंच के बिना फाइलों की सेवा कर रहे हैं। गिटहब पेज, आईपीएफएस, एस 3, आदि। सिंगल पेज ऐप फ्रेमवर्क के आगमन के साथ, "सर्वरलेस" चलाने के लिए यह अधिक से अधिक आम होता जा रहा है (जहां सर्वर रहित का मतलब सर्वर के बिना आप अपनी संपत्ति की सेवा को नियंत्रित/कॉन्फ़िगर नहीं करते हैं), इसलिए आप apple के लिए अनुरोध किए जाने पर apple.js की सेवा के लिए सर्वर साइड फ़िल्टर पर भरोसा नहीं कर सकता।

आपको यह सुनिश्चित करना होगा कि आप प्रत्येक आयात पर ठीक उसी तरह एक फ़ाइल का संदर्भ लें।

आपकी संलेखन वरीयता के आधार पर हमेशा एक या अन्य 404 बना सकते हैं। यदि आपने अपनी परियोजना के भीतर सिम्लिंक का उपयोग किया है तो वे एक समान समस्या का कारण बनेंगे जिससे आपको यह भी चुनना होगा कि कैसे निपटना है।

बस हमेशा .js एक्सटेंशन वाली फ़ाइलें आयात करें

हाँ, यह भी ठीक काम करता है।

@QuantumInformation क्या यहां इस्तेमाल किया गया आपका स्निपेट खुले इस्तेमाल के लिए है? क्या मैं इसे किसी प्रोजेक्ट में उपयोग कर सकता हूं? मैं

@distante हाँ आप इसका उपयोग कर सकते हैं

FYI करें यदि आप परीक्षण के लिए जेस्ट का उपयोग कर रहे हैं और स्रोत में .js में एक्सटेंशन में परिवर्तन कर रहे हैं - यह टूट जाता है
लेकिन आप इसे ठीक करने के लिए अपने जेस्ट कॉन्फिगर में निम्नलिखित जोड़ सकते हैं:

  "jest": {
    ...
    "moduleNameMapper": {
      "(.*)\\.js": "$1"
    }
  }

हैलो @MrAntix ,

मुझे लगता है कि जेस्ट वह पुस्तकालय है जिसे टाइपस्क्रिप्ट के अनुकूल होना चाहिए, न कि विपरीत।

मेरे पास एक और साइट है जिसके साथ मैं एक बिल्ड टूल का उपयोग नहीं करना चाहता हूं। क्या हम यहां सबसे अच्छे हैं:

https://github.com/microsoft/TypeScript/issues/16577#issuecomment -452312753

वर्कअराउंड के रूप में, आप इसे इस तरह से कर सकते हैं (भले ही इसकी एक ts फ़ाइल, जेएस नहीं)

अगर कोई इसे आजमाना चाहता है:
https://github.com/QuantumInformation/web-gen-bot

हालांकि, मैं वर्तमान tsconfig के साथ काम करने के लिए स्रोत डिबगिंग नहीं प्राप्त कर सकता, वापस रिपोर्ट करूंगा।

अंत में मैं वेबपैक पर वापस गया, ब्राउज़र में बिल्ड टूल्स से दूर जाने की कोशिश करते समय नोड_मॉड्यूल्स हत्यारा था।

यह केवल जेस्ट नहीं है - यदि आप प्रकाशन से पहले टाइपस्क्रिप्ट को संकलित करने के लिए tsc का उपयोग करते हैं, तो परिणामी पैकेज को आयात करने वाला कोई भी JS मॉड्यूल मॉड्यूल रिज़ॉल्यूशन में अंतर के कारण टूट जाएगा।

ऐसा लगता है कि यहाँ चर्चा दो संबंधित लेकिन अंततः अलग-अलग मुद्दों में बदल गई है:

• टाइपस्क्रिप्ट को ऐसी फाइलें उत्पन्न करनी चाहिए जिन्हें मूल रूप से एक ब्राउज़र में लोड किया जा सकता है
• टाइपस्क्रिप्ट को इस तथ्य को हल करना चाहिए कि नोड मॉड्यूल पथ हमेशा मान्य URL नहीं होते हैं।

मुझे लगता है कि हमें पहले मुद्दे पर ध्यान देने की जरूरत है, क्योंकि दूसरा स्पष्ट रूप से कुछ ऐसा है जिसे टाइपस्क्रिप्ट अपने आप हल नहीं कर सकता है।

पहला मुद्दा, हालांकि, बिल्कुल कुछ ऐसा है जिसे टाइपस्क्रिप्ट हल कर सकता है और उसे प्राथमिकता देनी चाहिए, क्योंकि यह अधिकांश लोगों के लिए एक प्रमुख अवरोधक है जो आधुनिक ब्राउज़रों पर लक्षित वेबएप बनाने के लिए टाइपस्क्रिप्ट का उपयोग करना चाहते हैं।

मेरी राय में, यह मुद्दा यहीं तक उबलता है:

यदि tsc चलाने से $ .js एक्सटेंशन वाली एक फ़ाइल बनती है और फिर दूसरी फ़ाइल जो पहली .js फ़ाइल आयात करती है, तो इस बारे में कोई अस्पष्टता नहीं है कि किस एक्सटेंशन का उपयोग करना है, और एक होना चाहिए एक्सटेंशन शामिल करने का विकल्प।

टाइपस्क्रिप्ट जेनरेट की गई फाइलों के अलावा अन्य फाइलों को इंगित करने वाले सभी आयात विवरणों के लिए, मुझे लगता है कि उन्हें अपरिवर्तित छोड़ना ठीक है (जैसा कि टाइपस्क्रिप्ट आज करता है)।

पहले विकल्प के अनुसार, मुझे लगता है कि एक कमांड लाइन तर्क सबसे अच्छा होगा, और यह डिफ़ॉल्ट रूप से बंद हो जाएगा। मैं ऐसा इसलिए कह रहा हूं क्योंकि, अगर मैं वेबपैक का उपयोग करता हूं, तो मैं नहीं चाहता कि .js आयात में जोड़ा जाए क्योंकि वेबपैक मॉड्यूल बंडलिंग का ख्याल रखता है।

वैसे भी, node_modules वह हत्यारा था जिसने मुझे देशी मॉड्यूल ब्राउज़र ऐप्स के लिए हैक का उपयोग करके रोक दिया।

मैं ऐसा इसलिए कह रहा हूं क्योंकि, अगर मैं वेबपैक का उपयोग करता हूं, तो मैं नहीं चाहता कि .js आयात में जोड़ा जाए क्योंकि वेबपैक मॉड्यूल बंडलिंग का ख्याल रखता है।

हालांकि वेबपैक .js एक्सटेंशन को पूरी तरह से ठीक करता है, इसलिए इसमें कोई अंतर नहीं है।

वास्तव में कभी-कभी वेबपैक के साथ .js का उपयोग करना आवश्यक होता है (ऐसी स्थितियों में जहां एक ही नाम के साथ कई फाइलें होती हैं लेकिन अलग-अलग एक्सटेंशन)।

तो क्या आप इस बारे में अधिक बता सकते हैं कि आप वेबपैक के साथ .js आयात क्यों नहीं चाहते हैं?

जब मैं I don't want कहता हूं तो मेरा मतलब था कि मुझे अपने उपयोग के मामलों की आवश्यकता नहीं है।

मुझे एक अनिवार्य कारण नहीं दिख रहा है कि यह डिफ़ॉल्ट व्यवहार क्यों नहीं होना चाहिए (हमेशा एक और कॉन्फ़िगरेशन ध्वज जोड़ने के लिए अनिच्छुक ...)

आयात को .js पर सेट करने से ts-नोड फ़ाइल के लिए ठीक से काम करना बंद कर देता है। ऐसा इसलिए है क्योंकि ts-नोड एक समय में केवल एक फ़ाइल को संकलित करता है और यदि उत्सर्जित फ़ाइल सामग्री require('./foo.js') के साथ समाप्त होती है तो जब नोडज उस फ़ाइल को संसाधित करता है तो वह ./foo.js लोड करने का प्रयास करेगा जो मौजूद नहीं है डिस्क पर कहीं भी और इस प्रकार यह विफल हो जाएगा। जब कोड की आवश्यकता होती है ( ./foo ) दूसरी ओर, ts-नोड के हैंडलर को कॉल किया जाएगा जिस बिंदु पर वह ./foo.ts को JS में संकलित कर सकता है और उसे वापस कर सकता है।

यदि टाइपस्क्रिप्ट सभी मामलों में .js एक्सटेंशन उत्सर्जित करता है, तो ts-node उसी समस्या में चलेगा। हालांकि, अगर कोई एक्सटेंशन स्वचालित रूप से जोड़ा गया है या नहीं, टॉगल करने का कोई विकल्प है तो ts-नोड उस कंपाइलर विकल्प को बंद कर सकता है, जो मौजूदा सिस्टम को काम करना जारी रखने की अनुमति देगा।

चूंकि Node.js --experimental-modules के लिए अनिवार्य फ़ाइल एक्सटेंशन की आवश्यकता होती है, इसके लिए एपीआई निर्भरता विश्लेषण की आवश्यकता के बिना सीधा है - --jsext जैसा विकल्प किसी भी .ts एक्सटेंशन को .js में फिर से लिख सकता है .ts जैसे import 'npmpkg.ts' में समाप्त होता है। यह मामला अत्यंत दुर्लभ है, लेकिन संकल्प में इसे व्यापक रूप से संभालने के लिए नियम _bare विनिर्देशों_ के लिए अपवाद बनाने के लिए हो सकता है - यदि नंगे विनिर्देशक (यूआरएल नहीं, या सापेक्ष पथ) एक वैध एनपीएम पैकेज नाम है ( मिलान /^(@[-_\.a-zA-Z\d]+\/)?[-_\.a-zA-Z\d]+$/ , https://github.com/npm/validate-npm-package-name से), फिर पुनर्लेखन में .ts एक्सटेंशन को अनदेखा करें।

मैंने एक टाइपस्क्रिप्ट कंपाइलर ट्रांसफॉर्मर बनाया है जो किसी भी सापेक्ष आयात पथ पर .js फ़ाइल एक्सटेंशन जोड़ देगा। इसका मतलब है कि अगर आपकी .ts फ़ाइल में import { Foo } from './foo' है तो यह import { Foo } from './foo.js' उत्सर्जित करेगी। यह एनपीएम पर उपलब्ध है, और इसका उपयोग करने के निर्देश प्रोजेक्ट रीडमी में पाए जा सकते हैं।

https://github.com/Zoltu/typescript-transformer-append-js-extension

अगर ऐसा कुछ टाइपस्क्रिप्ट कंपाइलर (एक कंपाइलर विकल्प के रूप में) में एकीकृत किया जाना था, तो शायद यह तय करने के बारे में होशियार होना चाहिए कि .js एक्सटेंशन को कब जोड़ना है और कब नहीं। अभी यह ./ या ../ से शुरू होने वाले किसी भी पथ की तलाश में है और उसके पास पथ में कहीं भी . नहीं है। इसका मतलब है कि यह कई एज केस परिदृश्यों में सही काम नहीं करेगा, हालांकि मैं सवाल करता हूं कि कोई भी _actually_ उन किनारे के मामलों में चलेगा या नहीं।

@MicahZoltu इसके लिए यूजरलैंड समाधान देखने के लिए बहुत अच्छा है। मुझे लगता है कि यह काफी महत्वपूर्ण है कि मानसिक मॉडल में हमेशा फ़ाइल एक्सटेंशन शामिल होते हैं , जैसे कि टाइपस्क्रिप्ट एक्सटेंशन विकल्प _turn .ts एक्सटेंशन में .js एक्सटेंशन में कंपाइल_ बन सकता है। यह संकल्प किनारे के मामलों से बचा जाता है, केवल एनपीएम पैकेज नामों के मामले को छोड़कर जो ".ts" में समाप्त होता है, जिसे मैंने अपनी पिछली टिप्पणी में चर्चा की है।

@guybedford .js एक्सटेंशन को .ts फ़ाइल में शामिल करने से यह फ़ाइल ts-node में निष्पादित नहीं हो सकती है। जिस तरह से NodeJS फ़ाइल रिज़ॉल्यूशन करता है, उसके कारण ts-नोड में समस्या का समाधान गैर-तुच्छ से बहुत दूर है। इसका अर्थ यह है कि यदि आप हार्ड कोडित .js एक्सटेंशन वाली लाइब्रेरी प्रकाशित करते हैं, तो लाइब्रेरी ts-नोड का उपयोग करने वाले किसी भी व्यक्ति के लिए काम नहीं करेगी। इस पर https://github.com/TypeStrong/ts-node/issues/783 पर चर्चा देखें।

@MicahZoltu मेरा मतलब है कि इसके बजाय .ts फ़ाइल में .ts एक्सटेंशन शामिल करना।

@guybedford एक .ts फ़ाइल में .js एक्सटेंशन सहित इसे बनाता है इसलिए फ़ाइल ts-नोड में निष्पादित नहीं हो सकती है।

यह अभी तक एक और कारण है कि नोड और ब्राउज़र में ऑटो-एक्ज़ीक्यूटिंग टाइपस्क्रिप्ट एक बुरा विचार है।

@MicahZoltu मेरा मतलब .ts फ़ाइल में .ts एक्सटेंशन को शामिल करना है।

मुझे लगता है कि इसके साथ समस्या यह है कि यह .ts फ़ाइल और .js / .d.ts जोड़ी के बीच समानता को तोड़ता है। इसका मतलब यह है कि यदि आप एक फ़ाइल आयात कर रहे हैं जो वर्तमान प्रोजेक्ट के साथ संकलित है तो आप .ts का उपयोग करते हैं, और यदि आप फ़ाइल को किसी भिन्न प्रोजेक्ट में ले जाते हैं तो आपको .js का उपयोग करने के लिए इसमें आयात बदलने की आवश्यकता है। .

इसका मतलब यह भी है कि आउटपुट ट्रांसफॉर्मर के बिना मानक वातावरण में काम नहीं करता है। यह देखते हुए कि .tsconfig फ़ाइल से ट्रांसफॉर्मर स्थापित करने का कोई तरीका नहीं है, इसका मतलब है कि आपको हमेशा एक कस्टम कंपाइलर का उपयोग करना होगा। $#$ .js $#$ के बजाय .ts का उपयोग करने के छोटे लाभ के लिए यह एक बहुत बड़ी बाधा है।

इसका अर्थ यह है कि यदि आप .ts का उपयोग करने वाले वर्तमान प्रोजेक्ट के साथ संकलित एक फ़ाइल आयात कर रहे हैं, और यदि आप फ़ाइल को किसी भिन्न प्रोजेक्ट में ले जाते हैं, तो आपको .js का उपयोग करने के लिए इसमें आयात को बदलना होगा।

बाहरी/आंतरिक आयात सीमाएं अच्छी तरह से परिभाषित चीजें हैं। यदि एक निर्भरता मौजूदा समान-बिल्ड की आंतरिक .ts फ़ाइल से चलती है, तो किसी अन्य पैकेज आयात की बाहरी .js फ़ाइल होने के लिए जिसका अपना अलग निर्माण है या शायद टाइपस्क्रिप्ट भी नहीं है , तो हाँ, आपको एक्सटेंशन बदलना होगा क्योंकि यह एक पूरी तरह से अलग अवधारणा है।

इसका मतलब यह भी है कि आउटपुट ट्रांसफॉर्मर के बिना मानक वातावरण में काम नहीं करता है।

जबकि एक ट्रांसफॉर्मर हमें इसका पता लगाने में मदद कर सकता है, इस मुद्दे को हल करने के लिए --ts-to-js या इसी तरह के कंपाइलर फ्लैग/विकल्प की बहुत आवश्यकता है।

@guybedford आपने मुझे आश्वस्त किया कि प्लगइन के लिए .ts डालना सही काम था। हालाँकि, इसे लागू करने की कोशिश करने पर मैंने सीखा कि टाइपस्क्रिप्ट वास्तव में इसकी अनुमति नहीं देता है!

// foo.ts
export function foo() { console.log('foo') }

// bar.ts
import { foo } from './foo.ts' // Error: An import path cannot end with a '.ts' extension. Consider importing './foo' instead
foo()

हैलो, इसके बारे में क्या?

इनपुट:

// src/lib.js.ts
export const result = 42;

// src/index.js.ts
import { result } from "./lib.js";

console.log(result);

आउटपुट:

// build/lib.js
export const result = 42;

// build/index.js
import { result } from "./lib.js";

console.log(result);

मुद्दा #30076

टाइपस्क्रिप्ट फ़ाइल पर एकमात्र .ts एक्सटेंशन मेरे लिए सबसे उपयुक्त लगता है। अक्सर आप संकलन समय तक नहीं जानते कि लक्ष्य क्या है। उदाहरण के लिए, मेरी कई पुस्तकालय परियोजनाओं में मेरे पास कई tsconfig.json फाइलें हैं जो विभिन्न वातावरणों को लक्षित करती हैं, जैसे आधुनिक ब्राउज़रों को लक्षित करना जो .js फाइलों को उत्सर्जित करना चाहिए और .js के लिए आयात पथ मैप करना चाहिए। , या आधुनिक नोड को लक्षित करना, जो .mjs फ़ाइलें उत्सर्जित करता है और आयात पथ को .mjs पर मैप करता है।

@MicahZoltu कि .ts में समाप्त होने वाली फ़ाइलों को आयात करना एक त्रुटि है, संभवतः वास्तव में हमारे लाभ के लिए है। क्योंकि इसका मतलब है कि .ts से .js संकलन पर विस्तार पुनर्लेखन जोड़ा जा सकता है जब भी .ts एक्सटेंशन ध्वज की आवश्यकता के बिना उपयोग किए जाते हैं :)

संभवतः .ts एक्सटेंशन को समर्थित करने और .js एक्सटेंशन (संभवतः इस सुविधा को सक्षम करने के लिए एक ध्वज के नीचे, लेकिन एक ध्वज जिसे समय पर हटाया जा सकता है) को फिर से लिखने के लिए एक पीआर एक शानदार तरीका होगा इस रास्ते से शुरू करने के लिए।

//cc @DanielRosenwasser

यह मुद्दा वास्तव में पहले से ही लंबा है इसलिए किसी ने पहले ही यह कह दिया होगा, इसलिए जो पहले ही कहा जा चुका है उसे दोहराने का जोखिम है:

टाइपस्क्रिप्ट को डेवलपर्स को import s में एक्सटेंशन निर्दिष्ट करने की अनुमति देनी चाहिए क्योंकि यह जावास्क्रिप्ट को मान्य करता है। और यह केवल JS/TS एक्सटेंशन के बारे में नहीं है! ESM में, कोई भी एक्सटेंशन तब तक मान्य है जब तक कि MIME प्रकार सही है।

import actuallyCode from './lookLikeAnImage.png';

... तब तक मान्य होना चाहिए जब तक सर्वर उस फ़ाइल में मान्य जावास्क्रिप्ट परोसता है और सही MIME प्रकार सेट करता है। यह और आगे जाता है क्योंकि TS के लिए भी यही सच हो सकता है! एक TS फ़ाइल JS MIME प्रकार के साथ परोसा जाने वाला JS स्रोत कोड हो सकता है और इसलिए ESM मॉड्यूल आयात के लिए एक मान्य पथ हो सकता है।

आईएमओ टाइपस्क्रिप्ट को केवल एक एक्सटेंशन के बिना आयात पर विचार करना चाहिए (जैसे यह आज आपको चाहता है) और अकेले छोड़ दें, कोई त्रुटि, चेतावनी इत्यादि नहीं। अन्यथा यह वैध जावास्क्रिप्ट कोड को अस्वीकार कर देता है जो जेएस के सुपरसेट होने का दावा करने वाले किसी चीज़ के लिए बहुत दुर्भाग्यपूर्ण है।

क्षमा करें यदि यह इसे उठाने के लिए सही जगह नहीं है, तो मैंने कुछ अन्य मुद्दे देखे: #18971, #16640, #16640 लेकिन इस विषय पर मुद्दे बाएं और दाएं बंद हो रहे हैं इसलिए मुझे लगता है कि यह "मुख्य" है चूंकि इसे खुला रहने दिया गया था।

NodeJS v12.7.0 . के साथ खेलना

salathiel@salathiel-genese-pc:~/${PATH_TO_PROJECT}$ node --experimental-modules dist/spec/src/ioc
(node:15907) ExperimentalWarning: The ESM module loader is experimental.
internal/modules/esm/default_resolve.js:59
  let url = moduleWrapResolve(specifier, parentURL);
            ^

Error: Cannot find module '${PROJECT_ROOT}/dist/spec/src/ioc' imported from ${PROJECT_ROOT}/
    at Loader.resolve [as _resolve] (internal/modules/esm/default_resolve.js:59:13)
    at Loader.resolve (internal/modules/esm/loader.js:73:33)
    at Loader.getModuleJob (internal/modules/esm/loader.js:149:40)
    at Loader.import (internal/modules/esm/loader.js:133:28)
    at internal/modules/cjs/loader.js:830:27
    at processTicksAndRejections (internal/process/task_queues.js:85:5) {
  code: 'ERR_MODULE_NOT_FOUND'
}

salathiel@salathiel-genese-pc:~/${PATH_TO_PROJECT}$ node --experimental-modules dist/spec/src/ioc.js
(node:16155) ExperimentalWarning: The ESM module loader is experimental.
internal/modules/esm/default_resolve.js:59
  let url = moduleWrapResolve(specifier, parentURL);
            ^

Error: Cannot find module '${PROJECT_ROOT}/dist/spec/src/observe' imported from ${PROJECT_ROOT}/dist/spec/src/ioc.js
    at Loader.resolve [as _resolve] (internal/modules/esm/default_resolve.js:59:13)
    at Loader.resolve (internal/modules/esm/loader.js:73:33)
    at Loader.getModuleJob (internal/modules/esm/loader.js:149:40)
    at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:43:40)
    at link (internal/modules/esm/module_job.js:42:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

अब, मुझे यकीन नहीं है कि यह परेशान क्यों है ...

फिलहाल टाइपस्क्रिप्ट पथों को फिर से नहीं लिखता है। यह निश्चित रूप से कष्टप्रद है, लेकिन आप वर्तमान में .js एक्सटेंशन स्वयं जोड़ सकते हैं।

@DanielRosenwasser https://github.com/microsoft/TypeScript/issues/16577#issuecomment-309169829

एक विकल्प के पीछे लागू करने के बारे में क्या? --rewrite-paths ( rewritePaths: true ) की तरह?

https://github.com/microsoft/TypeScript/issues/13422#issuecomment -521169737

@viT-1 फिलहाल के लिए एक समाधान है: https://github.com/microsoft/TypeScript/issues/16577#issuecomment -507504210

@MicahZoltu मैं सिस्टमजेएस बंडलिंग (tsconfig outFile विकल्प) द्वारा अपना उपयोगकेस हल करता हूं

मैंने इस बारे में लोगों द्वारा लिखी गई हर टिप्पणी को नहीं पढ़ा है, लेकिन मुझे समझ में नहीं आता कि मुझे .js एक गजियन बार क्यों लिखना है। मैं चाहता हूं कि कंप्यूटर मेरे लिए यह करे।

@richardkazuomiller हम सब करते हैं, लेकिन @DanielRosenwasser ने https://github.com/microsoft/TypeScript/issues/16577#issuecomment -448747209 में कहा है कि वे अभी के लिए ऐसा करने को तैयार नहीं हैं (मुझे आश्चर्य है कि यह मुद्दा अभी भी भ्रामक रूप से खुला है) उपरोक्त कथन के बाद इतने लंबे समय के लिए)। यदि आप चाहते हैं कि कंप्यूटर आपके लिए ऐसा करे, तो आयात पथ पुनर्लेखन को संभालने के लिए बंडलर या किसी तृतीय पक्ष टूल का उपयोग करने पर विचार करें।

कौन चाहता है कि मैं इस मुद्दे को बंद कर दूं?

कृपया बंद न करें, मैं अभी भी यह देखने के लिए इंतजार कर रहा हूं कि टाइपस्क्रिप्ट टीम कैसे प्रतिक्रिया देगी कि वे ईएसएम आयात के लिए कैसे जा रहे हैं जो किसी भी एक्सटेंशन का उपयोग करने की अनुमति देता है और इसके बजाय एमआईएमई प्रकार पर भरोसा करता है। फिलहाल यह जावास्क्रिप्ट में संभव है लेकिन टाइपस्क्रिप्ट में नहीं। (कृपया विवरण के लिए मेरी पिछली टिप्पणी देखें।)

@TomasHubelbauer यही कारण है कि मैंने कॉन्फ़िगरेशन फ़ाइल में एक ध्वज प्रस्तावित किया है, यह संकेत दे सकता है कि सभी एक्सटेंशन-कम आयातों में .js (या कोई अन्य कॉन्फ़िगर किया गया) एक्सटेंशन जोड़ा जाना चाहिए। यह ऑप्ट-इन होगा, इसलिए डिफ़ॉल्ट गलत हो सकता है, मौजूदा परियोजनाओं या विभिन्न जरूरतों वाली परियोजनाओं को ठीक वैसे ही काम करना।

जैसा कि पहले कहा गया था:

सुनिश्चित नहीं है कि TS के किस संस्करण ने इसे जोड़ा है, लेकिन ' ./file.js' जैसे आयात अब काम करते हैं (भले ही फ़ाइल वास्तव में file.ts हो)।
टाइपस्क्रिप्ट फ़ाइल को ठीक से हल करता है, और लक्ष्य के लिए संपूर्ण .js आयात को आउटपुट करता है।

यह समझ में आता है क्योंकि कोई भी वैध जावास्क्रिप्ट वैध टाइपस्क्रिप्ट है। चूंकि आप कर सकते हैं:

import foo from './bar.js'

... JS में, आपको इसे TS में भी करने में सक्षम होना चाहिए। यदि आप ऐसा करते हैं, तो आप मूल ES6 मॉड्यूल का उपयोग करने की समस्या का समाधान करते हैं क्योंकि आपने अपने एक्सटेंशन सही कर लिए हैं।

आइए यह भी न भूलें कि जब ब्राउज़र ./foo/bar के लिए आयात देखता है, तो वह वास्तव में इसके लिए अनुरोध करता है। तथ्य यह है कि सर्वर के कारण कुछ भी नहीं परोसा गया था। आप इसे इस तरह से कॉन्फ़िगर कर सकते हैं कि /foo/bar के अनुरोध /foo/bar /foo/bar.js संतुष्ट हों। यह नहीं कहना कि यह एक अच्छा समाधान है, या एक अच्छा विचार भी है , लेकिन यह तकनीकी रूप से काम करेगा।

कॉन्फ़िग फ़ाइल में ध्वज, यह संकेत दे सकता है कि सभी एक्सटेंशन-रहित आयातों में .js (या कोई अन्य कॉन्फ़िगर किया गया) एक्सटेंशन जोड़ा जाना चाहिए

इससे अधिकांश मामलों का समाधान हो जाएगा। क्या टाइपस्क्रिप्ट टीम इस कॉन्फ़िगरेशन विकल्प के लिए पीआर पर विचार करने को तैयार होगी?

जब सापेक्ष पथ मॉड्यूल रिज़ॉल्यूशन की बात आती है तो NodeJS अब _by default_ ब्राउज़र के समान व्यवहार करता है। यह अब डिफ़ॉल्ट रूप से .js एक्सटेंशन का अनुमान नहीं लगाएगा। इसका मतलब है कि टीएससी के वर्तमान व्यवहार के परिणामस्वरूप जेएस उत्सर्जित होता है जो सभी रनटाइम संदर्भों में अमान्य है। ऐसा लगता है कि इस मुद्दे को अब संबोधित किया जाना चाहिए क्योंकि ईएसएम के लिए ब्राउज़र और नोडजेएस व्यवहार दोनों पर स्पष्टता है।

https://nodejs.org/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm

ईएसएम के लिए नए रिज़ॉल्वर को एक नए रिज़ॉल्यूशन मोड की आवश्यकता है - moduleResolution: node वास्तव में केवल सीजेएस रिज़ॉल्वर है जिसे मैं अब "नोड के पुराने संस्करण" कह सकता हूं। यदि आप नए ईएसएम रिज़ॉल्वर को लक्षित करना चाहते हैं, तो हमें अधिक उपयुक्त मिलान के लिए एक नए समाधान मोड की आवश्यकता होगी। विशेष रूप से चूंकि नोड अभी भी सभी मौजूदा कॉन्फ़िगरेशन में पुराने रिज़ॉल्वर का पूरी तरह से समर्थन करता है। (ध्यान दें: ऐसा नया रिज़ॉल्वर _हमारा डिफ़ॉल्ट_ बनाना मुश्किल होगा)

यद्यपि! जबकि इसके बारे में _असहमति_ है और _कुछ लोग तथ्य_ के रूप में राज्य की राय का चयन करेंगे, अभी भी एक --es-module-specifier-resolution=node ध्वज है जो अपेक्षित विस्तार व्यवहार देता है और फिर भी डिफ़ॉल्ट बन सकता है - जैसा कि दस्तावेज़ कहते हैं, ध्वजांकित होने के बावजूद , नोड में es मॉड्यूल _अभी भी प्रकृति में प्रयोगात्मक_ हैं।

साथ ही, मूल अनुरोध के लिए एक अनुस्मारक के रूप में: हम आयात को फिर से नहीं लिखते हैं। कभी। बिलकुल। निर्दिष्टकर्ता === निर्दिष्टकर्ता बाहर। विनिर्देशक संरचनात्मक आशय का वर्णन करते हैं, और यह हमारा लक्ष्य नहीं है कि हम एक इच्छित संरचना से दूसरी संरचना में परोक्ष रूप से मैप करें। आप इसके बारे में इस तरह भी सोच सकते हैं: यदि आपने const varFoo = "./Foo"; import(varFoo) लिखा है, तो क्या हम जरूरत पड़ने पर किसी तरह वहां एक्सटेंशन जोड़ देंगे? नहीं - यह हास्यास्पद है - गतिशील इनपुट के सभी रूपों को संभालने के लिए हमें रनटाइम पर गतिशील आयात को लपेटने की आवश्यकता होगी, और अचानक हम अपने स्वयं के मॉड्यूल लोडर बन गए हैं, बिल्टिन प्लेटफॉर्म लोडर के ऊपर परत। इसके बजाय, हम एक रिज़ॉल्वर मोड प्रदान करेंगे जो आपके द्वारा एक्सटेंशन को छोड़ देने पर उचित त्रुटियाँ प्रदान करता है (जो कि, आप निस्संदेह पहले से ही लिंट नियम ढूंढ सकते हैं)।

यदि आपको यह धागा मिल जाता है और आप _वास्तव में चाहते हैं कि आपके इनपुट स्रोतों में एक्सटेंशन न हों, और आपको _वास्तव में जरूरत_ आपके आउटपुट को अभी भी उस के साथ काम करने के लिए जब लक्ष्यीकरण (नोड एस) मॉड्यूल, तो आपको https://github.com/ पर फीडबैक देना चाहिए।

अचानक हम खुद के मॉड्यूल लोडर बन गए हैं

क्या tsc को एक कार्यात्मक मॉड्यूल लोडर नहीं होना चाहिए, इससे कोई फर्क नहीं पड़ता? यदि आप उस मॉड्यूल को नहीं ढूंढ पा रहे हैं जिससे यह आया है, तो आप किसी आयात के विरुद्ध टाइप-चेक नहीं कर सकते। मैं बस यह देखना चाहता हूं कि सभी विभिन्न मॉड्यूल लोडर व्यापक रूप से संगत तरीके से व्यवहार करते हैं, या कम से कम अनुमानित रूप से अलग तरीके से जो समायोजित करने के लिए उचित रूप से दर्द रहित है।

जब सापेक्ष पथ मॉड्यूल रिज़ॉल्यूशन की बात आती है तो NodeJS अब डिफ़ॉल्ट रूप से ब्राउज़र के समान व्यवहार करता है। यह अब डिफ़ॉल्ट रूप से .js एक्सटेंशन का अनुमान नहीं लगाएगा। इसका मतलब है कि टीएससी के वर्तमान व्यवहार के परिणामस्वरूप जेएस उत्सर्जित होता है जो सभी रनटाइम संदर्भों में अमान्य है।

क्या टाइपस्क्रिप्ट पहले से ही समर्थित विशिष्टताओं में .js फ़ाइल एक्सटेंशन का उपयोग करने का यह एक और कारण नहीं है? यह सब कुछ हल करता है सिवाय इसके कि यह बहुत अच्छा होगा यदि tsc विस्तारहीन आयात पर त्रुटिपूर्ण हो।

क्या टीएससी को एक कार्यात्मक मॉड्यूल लोडर नहीं होना चाहिए, इससे कोई फर्क नहीं पड़ता? यदि आप उस मॉड्यूल को नहीं ढूंढ पा रहे हैं जिससे यह आया है, तो आप किसी आयात के विरुद्ध टाइप-चेक नहीं कर सकते। मैं बस यह देखना चाहता हूं कि सभी विभिन्न मॉड्यूल लोडर व्यापक रूप से संगत तरीके से व्यवहार करते हैं, या कम से कम अनुमानित रूप से अलग तरीके से जो समायोजित करने के लिए उचित रूप से दर्द रहित है।

हमारा लक्ष्य रनटाइम लोडर कार्यान्वयन प्रदान करना नहीं है - केवल एक संकलन समय विश्लेषण जो आपके द्वारा लक्षित रनटाइम लोडर को दर्शाता है। हम रनटाइम घटक के बिना सभी आयातों को संभवतः रीमैप नहीं कर सकते हैं, जो हमारे पास नहीं है, और न ही इसका लक्ष्य है।

क्या टीएससी को एक कार्यात्मक मॉड्यूल लोडर नहीं होना चाहिए, इससे कोई फर्क नहीं पड़ता?

रनटाइम पर नहीं। tsc को यह समझने की जरूरत है कि पसंद का रनटाइम कैसे निर्दिष्टकर्ताओं को हल करेगा और निर्माण समय पर इसे लागू करेगा, लेकिन रनटाइम पूरी तरह से पर्यावरण पर छोड़ दिया गया है।

आप इसके बारे में इस तरह भी सोच सकते हैं: यदि आपने const varFoo = "./Foo" लिखा है; import(varFoo) क्या जरूरत पड़ने पर हम किसी तरह वहां एक्सटेंशन जोड़ेंगे?

@weswigham यह गतिशील आयात के संबंध में एक मजबूत तर्क है, लेकिन मुझे नहीं लगता कि आप स्थिर आयात के साथ ऐसा कर सकते हैं? मैं इस तर्क की सराहना कर सकता हूं कि रणनीति दोनों के लिए समान होनी चाहिए, लेकिन मुझे लगता है कि यह उल्लेखनीय है कि स्थिर आयात गतिशील आयात से बहुत अलग भूमिका निभाते हैं और मुझे नहीं लगता कि स्थिर के लिए एक अलग रणनीति रखने के लिए यह एकमुश्त _अनुचित_ है आयात पुनर्लेखन और गतिशील आयात पुनर्लेखन।

क्या यह एक और कारण नहीं है कि टाइपस्क्रिप्ट जैसे विनिर्देशकों में .js फ़ाइल एक्सटेंशन का उपयोग पहले से ही समर्थन करता है? यह सब कुछ हल करता है सिवाय इसके कि यह बहुत अच्छा होगा यदि tsc ने विस्तारहीन आयात पर त्रुटि की।

@justinfagnani इसके साथ दो समस्याएं हैं:

1. यदि आप अपने आयात पर .js एक्सटेंशन निर्दिष्ट करते हैं तो एक रनटाइम जो TS को मूल रूप से निष्पादित करता है (जैसे TS-Node) काम करने में विफल रहेगा।
2. यदि आप अपने आयात में .js एक्सटेंशन शामिल करते हैं तो आप कंपाइलर (IMO) से झूठ बोल रहे हैं।

(2) के संबंध में, यदि मेरे पास दो TS फ़ाइलें हैं a.ts और b.ts और a.ts करता है import ... from './b.js' , तो मैं संकलक को बता रहा हूं" मेरे पास एक सहोदर फ़ाइल है नामित b.js । यह कथन सत्य नहीं है। मामले को बदतर बनाने के लिए, यदि आपके पास .b.ts और b.js (जो वास्तव में एक दूसरे के व्युत्पन्न नहीं हो सकते हैं) हैं, तो यह अब अस्पष्ट हो जाता है कि आप किसका उल्लेख कर रहे हैं _भले ही आपने स्पष्ट रूप से एक एक्सटेंशन_ शामिल किया हो।

मेरी राय है कि उपयोगकर्ता को संकलक को बताना चाहिए कि वे वास्तव में क्या चाहते हैं (एक उपयोगकर्ता के रूप में) और वह है या तो "X और किसी भी एक्सटेंशन के नाम से कोई फ़ाइल आयात करें" ( import ... from './foo' के मामले में) ) या "विशेष रूप से इस फ़ाइल को आयात करें" ( import ... from './foo.ext' के मामले में)। यदि संकलक यह पता लगाता है कि आप एक TS फ़ाइल आयात कर रहे हैं, और संकलक एक .js फ़ाइल का उत्सर्जन करने के लिए आगे बढ़ता है, तो मेरा मानना ​​​​है कि संकलक को उचित फ़ाइल को सही ढंग से आयात करने के लिए आयात को अद्यतन करना चाहिए। इसका मतलब आयात विवरण में .ts को .js में बदलना हो सकता है।

@justinfagnani इसके साथ दो समस्याएं हैं:

1. यदि आप अपने आयात पर .js एक्सटेंशन निर्दिष्ट करते हैं, तो एक रनटाइम जो TS को मूल रूप से निष्पादित करता है (जैसे TS-Node) काम करने में विफल रहेगा।

यह टीएस-नोड में एक बग है। यह tsc के व्यवहार से मेल नहीं खा रहा है।

1. यदि आप अपने आयात में .js एक्सटेंशन शामिल करते हैं तो आप कंपाइलर (IMO) से झूठ बोल रहे हैं।

यह वास्तव में विपरीत है - आप सच कह रहे हैं कि वास्तव में क्या आयात किया जाएगा। आप _not_ .ts फ़ाइल आयात कर रहे होंगे, लेकिन एक .js फ़ाइल। .d.ts / .js जोड़ी और .ts फ़ाइल के बीच कोई दृश्यमान अंतर नहीं होना चाहिए। वे विनिमेय हैं। इसे पूरा करने का एकमात्र उचित तरीका .js फ़ाइल आयात करना है - संकलन के बाद .ts फ़ाइल क्या होगी।

@justinfagnani

.d.ts/.js जोड़ी और .ts फ़ाइल के बीच कोई दृश्य अंतर नहीं होना चाहिए

यह हमेशा सही नहीं होता। आप अपने सर्वर को JS MIME प्रकार के साथ JS, TS और DTS की सेवा के लिए कॉन्फ़िगर कर सकते हैं और फिर उन सभी को जावास्क्रिप्ट में अलग से आयात कर सकते हैं और रनटाइम उन सभी को JS के रूप में कर्तव्यपूर्वक निष्पादित करेगा। ESM एक्सटेंशन की बिल्कुल भी परवाह नहीं करता है।

इसलिए मुझे लगता है कि TS उपयोगकर्ताओं को वास्तव में .ts एक्सटेंशन शामिल करने के लिए मजबूर होना चाहिए और जब तक वास्तव में एक एक्सटेंशन रहित फ़ाइल या उस नाम को आयात नहीं किया जाता है, तब तक एक्सटेंशनलेस एक त्रुटि होगी। और TS आउटपुट में आयात को .js पर फिर से लिख देगा। और यदि कोई JS फ़ाइल मौजूद है (TS द्वारा उत्पन्न नहीं) तो यह भी एक त्रुटि होगी।

यह टीएस-नोड में एक बग है। यह टीएससी के व्यवहार से मेल नहीं खा रहा है।

यह NodeJS लोडर की एक सीमा है, TS-नोड में बग नहीं: https://github.com/TypeStrong/ts-node/issues/783#issuecomment -507437929

यह हमेशा सही नहीं होता। आप अपने सर्वर को JS MIME प्रकार के साथ JS, TS और DTS की सेवा के लिए कॉन्फ़िगर कर सकते हैं और फिर उन सभी को जावास्क्रिप्ट में अलग से आयात कर सकते हैं और रनटाइम उन सभी को JS के रूप में कर्तव्यपूर्वक निष्पादित करेगा। ESM एक्सटेंशन की बिल्कुल भी परवाह नहीं करता है।

मैं इससे अच्छी तरह वाकिफ हूं, लेकिन ब्राउजर टाइपस्क्रिप्ट को भी निष्पादित नहीं करेगा। यह लगभग सार्वभौमिक रूप से सच है कि पर्यावरण द्वारा वास्तव में लोड की जाने वाली फ़ाइल एक जावास्क्रिप्ट फ़ाइल है।

हालांकि मेरा कहना यह है कि यदि आपके पास .js / .d.ts की जोड़ी पहले से है, तो मान लीजिए कि किसी तृतीय पक्ष पैकेज से है, और .js फ़ाइल आयात करें, तो tsc .d.ts फ़ाइल देखें और प्रकारों को लोड करें। यानी, एक .js / .d.ts जोड़ी _acts_ एक .ts फ़ाइल की तरह, और यह ऐसा ही होना चाहिए, क्योंकि इस तरह से आप बिना बदले जावास्क्रिप्ट से टाइपस्क्रिप्ट में पारदर्शी रूप से पोर्ट कर सकते हैं पोर्ट की गई फ़ाइलों का आयात।

यह टीएस-नोड में एक बग है। यह टीएससी के व्यवहार से मेल नहीं खा रहा है।

यह NodeJS लोडर की एक सीमा है, TS-नोड में बग नहीं: TypeStrong/ts-node#783 (टिप्पणी)

यह अभी भी एक बग है कि TS-Node tsc व्यवहार से अलग हो रहा है। यह .ts फ़ाइलों के लिए बनाता है जो tsc और TS-Node दोनों में काम नहीं करते हैं, और मैं दृढ़ता से tsc को मानक-सेटर के रूप में मानूंगा जिसका TS-Node को पालन करना चाहिए .

हालांकि मेरा कहना यह है कि यदि आपके पास पहले से ही एक .js/.d.ts जोड़ी है, जैसे कि किसी तृतीय पक्ष पैकेज से, और .js फ़ाइल आयात करें, तो tsc .d.ts फ़ाइल देखेगा और प्रकारों को लोड करेगा। यानी, एक .js/.d.ts जोड़ी एक .ts फ़ाइल की तरह काम करती है, और यह ऐसा ही होना चाहिए, क्योंकि इस तरह आप पोर्ट की गई फ़ाइलों के आयात को बदले बिना जावास्क्रिप्ट से टाइपस्क्रिप्ट में पारदर्शी रूप से पोर्ट कर सकते हैं।

यदि आप बाहरी _package_ लोड करते हैं, तो आपको किसी प्रकार के रनटाइम पैकेज लोडर की आवश्यकता होगी (उदाहरण के लिए, ब्राउज़र में आयात मानचित्र नामित) जो नामांकित मॉड्यूल की एंट्रीपॉइंट फ़ाइल में मैपिंग करता है। हालाँकि, मुझे लगता है कि आपकी बात आम तौर पर खड़ी होती है, उस मामले में जहाँ आपके पास एक रिश्तेदार .js/.d.ts जोड़ी है। मैं बाड़ पर हूं कि क्या उस स्थिति में आपको import ... from './foo.d.ts' या import ... from './foo.js' करना चाहिए।

.d.ts फ़ाइल अनिवार्य रूप से संरचना का वर्णन करने वाला एक हेडर है जिसमें इस बारे में कोई जानकारी नहीं है कि यह किस एक्सटेंशन से मैप करता है (यह धारणा है कि आम तौर पर आपके पास एक ही नाम के साथ कई फाइलें नहीं होनी चाहिए, लेकिन एक ही स्थान पर अलग-अलग एक्सटेंशन, और यदि आप ऐसा करते हैं तो हम निर्माण में त्रुटि करते हैं) - आज भी, संबद्ध रनटाइम "स्रोत" .js या .jsx ( jsx: preserve का उपयोग करके) हो सकता है। आप, मोटे तौर पर, एक .d.ts संदर्भ को .js के साथ एमिट समय पर आयात में प्रतिस्थापित नहीं कर सकते हैं और मान लें कि यह काम करता है ...

यह बिल्कुल महत्वपूर्ण है कि टीएससी को व्यापक के रूप में बहुत अधिक राय नहीं दी जाए
निर्माण और संकल्प मान्यताओं।

यह देखते हुए कि यह एक जटिल सीमा पर एक बहु-उपकरण है, इसकी अपेक्षा की जाएगी
वह कॉन्फ़िगरेशन इसे उपयोगकर्ताओं के मनचाहे तरीके से व्यवहार करने की अनुमति दे सकता है।

संकल्प परिवर्तनों को उजागर न करने का एक बहुत ही जानबूझकर प्रयास किया गया है
टीएससी संकलन प्रक्रिया का हिस्सा - यह अपने आप में राय को बल देता है
उपयोगकर्ता और उनके वर्कफ़्लो में घर्षण का कारण बनता है।

बुधवार 27 नवंबर, 2019 को 16:48 पर वेस्ली विघम सूचनाएं @github.com
लिखा था:

.d.ts फ़ाइल अनिवार्य रूप से संरचना का वर्णन करने वाला एक शीर्षलेख है जिसमें शामिल हैं
यह किस एक्सटेंशन से मैप करता है, इस बारे में कोई जानकारी नहीं है (धारणा यह है कि
आम तौर पर आपके पास एक ही नाम से कई फाइलें नहीं होनी चाहिए लेकिन
एक ही स्थान पर अलग-अलग एक्सटेंशन) - आज भी, संबद्ध
रनटाइम "स्रोत" .js या .jsx हो सकता है (jsx का उपयोग करके: संरक्षित करें)। आप ऐसा कर सकते हैं
नहीं, मोटे तौर पर, उत्सर्जन समय पर आयात में .d.ts संदर्भ को .js से बदलें
और मान लें कि यह काम करता है ...

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/TypeScript/issues/16577?email_source=notifications&email_token=AAESFSQS2DQ23RR5KN3RTZ3QV3TLXA5CNFSM4DPRQTY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW#TNMVW255Z62140
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAESFSUAP2YO23ZFHCOWVQLQV3TLXANCNFSM4DPRQTYQ
.

सुनिश्चित नहीं है कि इस परिदृश्य को कैसे संभालना है, लेकिन उसी चीज़ से संबंधित संदेह था।

मेरे पास मेरी एचटीएमएल फाइल में इस तरह का एक आयात नक्शा है:

<script type="importmap-shim">
      {
        "imports": {
          "@root/":"../../../",
         }
      }
</script>

और मेरे पास मेरी ts फ़ाइल है जहाँ मैं इस तरह की फ़ाइल आयात कर रहा हूँ:

import '@root/components/page-main/page-main.js';

अब, यह सेटअप ब्राउज़र में अच्छी तरह से काम करता है। लेकिन, मैं इसे VSCode में कैसे नेविगेट/उपयोग कर पाऊंगा? मेरा मतलब है, मैं आयात पर ctrl + क्लिक करना चाहता हूं और फ़ाइल पर नेविगेट करना चाहता हूं, स्वत: पूर्ण प्राप्त करना, डीफ़ टाइप करना आदि।

साथ ही, इस बात पर विचार करते हुए कि tsc .ts से .js तक आयात एक्सटेंशन को फिर से नहीं लिखता है, क्या कोई अन्य अनुशंसित टूल/पैकेज है जिसका उपयोग मैं निर्माण समय पर करने के लिए कर सकता हूं? धन्यवाद।

(मैं ES मॉड्यूल और आयात मानचित्रों के लिए https://github.com/guybedford/es-module-shims का उपयोग कर रहा हूं)

लेकिन, मैं इसे VSCode में कैसे नेविगेट/उपयोग कर पाऊंगा?

paths कंपाइलर विकल्प देखें।

साथ ही, इस बात पर विचार करते हुए कि tsc .ts से .js तक आयात एक्सटेंशन को फिर से नहीं लिखता है, क्या कोई अन्य अनुशंसित टूल/पैकेज है जिसका उपयोग मैं निर्माण समय पर करने के लिए कर सकता हूं? धन्यवाद।

बस .js का उपयोग करें और यह ठीक काम करेगा, भले ही आप बिल्ड समय पर .ts फ़ाइल की बात कर रहे हों।

@tvvignesh https://github.com/Zoltu/typescript-transformer-append-js-extension/ संकलन समय पर .js पर विस्तारहीन आयात को फिर से लिखने के लिए। मैं व्यक्तिगत रूप से "बस अपनी टीएस फाइलों में .js डालें" का प्रशंसक नहीं हूं क्योंकि यदि आप ऐसा करते हैं तो आपका कोड टीएस-नोड में नहीं चलेगा। यदि आपको अपना कोड ts-node में चलाने की आवश्यकता नहीं है, तो .js का उपयोग करना काम करेगा।

लेकिन, मैं इसे VSCode में कैसे नेविगेट/उपयोग कर पाऊंगा?

paths कंपाइलर विकल्प देखें।

साथ ही, इस बात पर विचार करते हुए कि tsc .ts से .js तक आयात एक्सटेंशन को फिर से नहीं लिखता है, क्या कोई अन्य अनुशंसित टूल/पैकेज है जिसका उपयोग मैं निर्माण समय पर करने के लिए कर सकता हूं? धन्यवाद।

बस .js का उपयोग करें और यह ठीक काम करेगा, भले ही आप बिल्ड समय पर .ts फ़ाइल की बात कर रहे हों।

आपके त्वरित उत्तर के लिए धन्यवाद। मैंने पहले ही tsconfig.json में पथ विकल्प सेट कर दिया था लेकिन फिर भी ctrl+क्लिक द्वारा नेविगेट करने में सक्षम नहीं था।

tsconfig.json में यह मेरा पथ विकल्प है

"paths": {
            "*": ["www/node_modules/*"],
            "@modules/*": ["www/node_modules/*"],
            "@root/*": ["www/*"]
        }

बस .js का उपयोग करें और यह ठीक काम करेगा, भले ही आप बिल्ड समय पर .ts फ़ाइल का जिक्र कर रहे हों।

यह काफी अव्यावहारिक है जब हजारों आयात होते हैं।

"बस .js का उपयोग करें" के साथ समस्या यह है कि यदि टाइपस्क्रिप्ट .mjs फाइलों का उत्सर्जन करता है तो आपका प्रोग्राम काम नहीं करता है। इसका मतलब है कि आप एक ऐसी स्थिति में समाप्त हो जाते हैं जहां आप टाइपस्क्रिप्ट लिख रहे हैं कि _eother_ ब्राउज़र में काम करता है _or_ NodeJS में काम करता है। अब आप टाइपस्क्रिप्ट नहीं लिख सकते जो दोनों में काम करता हो।

मेरा मानना ​​​​है कि यहाँ तर्क है, "यह टाइपस्क्रिप्ट की गलती नहीं है, यह ब्राउज़र और NodeJS का विचलन है"।

नोड 13.2 .js एक्सटेंशन का समर्थन करता है।

@justinfagnani ES मॉड्यूल के लिए? मैंने सोचा था कि नोडजेएस केवल ईएस मॉड्यूल लोड करेगा यदि उनके पास .mjs एक्सटेंशन था, अन्यथा फाइलों को कॉमनजेएस के रूप में माना जाता था?

मुझे लगता है कि यह पूरा सूत्र थोड़ा भटका हुआ है। फ़ाइल एक्सटेंशन को स्पष्ट रूप से लिखने से यह पूरी समस्या हल हो जाएगी। यदि आप एक जावास्क्रिप्ट फ़ाइल आयात कर रहे हैं, तो .js एक्सटेंशन लिखें। यदि आप टाइपस्क्रिप्ट फ़ाइल आयात कर रहे हैं, तो .ts एक्सटेंशन लिखें। मानक में इसकी अनुमति है और टाइपस्क्रिप्ट कंपाइलर इसे समान रूप से अच्छी तरह समझता है। एकमात्र समस्या यह है कि संकलक बताता है कि .ts एक्सटेंशन त्रुटियां हैं। यह शुद्ध ट्रांसपिलेशन को प्रभावित नहीं करता है, लेकिन यह केवल एक प्रकार की त्रुटि है। टाइपस्क्रिप्ट को इसे ठीक करना चाहिए, क्योंकि स्पष्ट रूप से एक .ts फ़ाइल एक्सटेंशन मान्य है, क्योंकि हम टाइपस्क्रिप्ट में संलेखन कर रहे हैं। इस समस्या को हल करने के लिए, Deno.js में VS कोड एक्सटेंशन है: https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

WebAssembly के आगमन के साथ, वेब एप्लिकेशन अधिक से अधिक फ़ाइल प्रकारों का आयात करना शुरू करने जा रहे हैं। यदि आप एक .wasm, .js, .ts, .rs, .c, आदि फ़ाइल आयात कर रहे हैं तो स्पष्ट रूप से यह बताना महत्वपूर्ण हो जाएगा कि

किसी ने वास्तव में मेरे द्वारा लिखी गई स्क्रिप्ट का उपयोग किया है?

https://github.com/microsoft/TypeScript/issues/16577#issuecomment -310426634

कोई प्रतिक्रिया यदि हां?

@QuantumInformation मैंने आपकी स्क्रिप्ट का उपयोग नहीं किया है, लेकिन मैंने जो टाइपस्क्रिप्ट ट्रांसफॉर्मर प्लगइन लिखा है वह मूल रूप से वही काम करता है। 😊 https://github.com/Zoltu/typescript-transformer-append-js-extension/

सबसे पहले, मैं इसे लागू करने के लिए टाइपस्क्रिप्ट को समझाने के लिए फिर से कोशिश नहीं करने वाला हूं, मैं समझ गया, आप ऐसा नहीं करेंगे।
हालांकि मैं टिप्पणियों को पढ़ रहा हूं और सोच रहा हूं: वे सभी लोग कह रहे हैं कि पथ में .js जोड़ने से यह सब हल हो जाएगा - क्या आप वास्तव में तीसरे पक्ष के पैकेज का उपयोग नहीं करते हैं? मैं अपने आयात में एक्सटेंशन कैसे जोड़ रहा हूं जो नोड_मॉड्यूल्स में है?

@MicahZoltu ओह अच्छा एक

आपका क्या मतलब है? यदि आप पथ का उपयोग कर रहे हैं, तो आप उस फ़ाइल का फ़ाइल एक्सटेंशन स्पष्ट रूप से लिखेंगे जिसे आप node_modules से आयात कर रहे हैं। लेकिन क्या यह आमतौर पर वैसे भी एक नंगे आयात नहीं होगा?

यदि आप सापेक्ष पथ निर्दिष्ट करते हैं तो यह नंगे नहीं होगा। हालाँकि मैं उस पैकेज के आंतरिक आयात के बारे में बात कर रहा हूँ जिसे मैं आयात कर रहा हूँ, उदाहरण के लिए rxjs देखें।

@Draccoz मेरा मानना ​​​​है कि बिंदु यह बनाया जा रहा है कि अगर कोई टाइपस्क्रिप्ट को import { ... } from './foo' की तरह लिखता है और फिर उसे एनपीएम पैकेज के रूप में प्रकाशित करता है, तो उपयोगकर्ता उस लाइब्रेरी का सीधे ब्राउज़र में उपयोग नहीं कर सकता है, भले ही वह ईएस मॉड्यूल को लक्षित करता हो। मेरा मानना ​​​​है कि यहां माइक्रोसॉफ्ट का तर्क यह है कि पैकेज गलत है अगर वह इस तरह के कोड को इस उम्मीद के साथ वितरित कर रहा है कि यह ब्राउज़र में काम करता है।

आप उस फ़ाइल का विस्तार लिखेंगे जो नोड_मॉड्यूल्स में मौजूद है। import * as stuff from 'rxjs/path/to/file.js'; अगर यह एक जावास्क्रिप्ट फ़ाइल है, और import * as stuff from 'rxjs/path/to/file.ts'; अगर उन्होंने टाइपस्क्रिप्ट फ़ाइल वितरित की है। यह अभी काम करता है अगर मैं गलत नहीं हूँ

@lastmjs हां, लेकिन क्या होगा यदि rxjs/path/to/file.ts में import foo from './bar' हो? आप इसे बदल नहीं सकते, क्योंकि आप फ़ाइल को संशोधित नहीं कर सकते, क्योंकि यह एक तृतीय-पक्ष लाइब्रेरी है।

इसलिए हमें हर जगह स्पष्ट एक्सटेंशन का उपयोग करने पर जोर देना चाहिए, लेकिन हां मुझे आपकी बात समझ में आ रही है। मेरा टूल (https://github.com/lastmjs/zwitterion) इस पुनर्लेखन को उन फ़ाइलों के लिए स्टॉप-गैप समाधान के रूप में करता है जिन्होंने एक्सटेंशन छोड़ दिया है।

हाँ, मेरी बात बिल्कुल यही थी - केवल एक्सटेंशन जोड़ने से तृतीय पक्ष पुस्तकालय ठीक नहीं होंगे जिन्हें हम संशोधित नहीं कर सकते हैं, इसलिए यह कोई समाधान नहीं है।
मुझे Microsoft बिंदु भी मिलता है, इसलिए मैं इसे अब और आगे नहीं बढ़ा रहा हूं (इस तथ्य के अलावा कि इस मुद्दे को खुला रखने से अनावश्यक आशा मिलती है जो संकुल अनुरक्षकों को टीएस को हल करने के लिए प्रतीक्षा करने के बजाय बिल्ड को समायोजित करने से रोकता है), यह होगा भले ही केवल एक बिल्ड टूल के रूप में टाइपस्क्रिप्ट हो और कोई अन्य निर्भरता न हो।

हाँ, लेकिन स्पष्ट रूप से आशा अभी भी कई लोगों के लिए अच्छी है

फिर भी, उन टिप्पणियों के माध्यम से दो बार कहा गया कि इसे लागू नहीं किया जाएगा, तो इसे खुला क्यों रखा जाए?

अगर कोई टाइपस्क्रिप्ट लिखता है जैसे './foo' से आयात {...} और फिर उसे एनपीएम पैकेज के रूप में प्रकाशित करता है

क्या बहुत से लोग एनपीएम पैकेज में असम्पीडित टीएस प्रकाशित कर रहे हैं? मैं इसे अपने आंतरिक उपयोग के लिए देख रहा था। मैं परियोजनाओं के बीच साझा किए गए सामान्य कोड के पुस्तकालय बना रहा हूं और लगा कि एनपीएम उन्हें पैकेज करने का एक उचित तरीका है, और हमारी टीम विशेष रूप से टीएस में चली गई है इसलिए मुझे डीपीएस संकलित करने से बचने में खुशी होगी। लेकिन ऐसा लगता है कि अलग-अलग टाइपिंग के साथ JS को पैकेज बनाने के लिए सबसे आम उपयोग का मामला है, फिर modules या main को JS को और types को टाइपिंग के लिए इंगित करें।

क्या असम्पीडित TS को NPM में प्रकाशित करने के लिए कोई परंपरा है? यदि हां, तो क्या यह कहीं प्रलेखित है? मुझे लगता है कि यह मूल मुद्दे से ओटी भटक रहा है लेकिन मुझे लगता है कि यह उत्तर के लिए प्रासंगिक है, क्योंकि हमें यह जानने की जरूरत है कि "थर्ड पार्टी टाइपस्क्रिप्ट" (पैकेज) एक समर्थित उपयोग केस/लक्ष्य है या नहीं।

@ thw0rted स्पष्ट नहीं होने के लिए क्षमा करें, मेरा मतलब था:

...अगर कोई टाइपस्क्रिप्ट लिखता है जैसे import { ... } from './foo' और फिर उसे आज TSC का उपयोग करके JS को ट्रांसपाइल करता है और उस JS को NPM पैकेज के रूप में प्रकाशित करता है ...

यदि इसे लागू नहीं किया जाएगा, तो मैं इस मुद्दे को अब बंद करने के लिए इसे एमएस पर छोड़ दूंगा।

आह, अब मैं समझ गया। हां, जब मैं ट्रांसपाइल करता हूं ( target: ES2018 के साथ) उत्सर्जित जेएस आयात विवरण के विस्तार को छोड़ देता है, लेकिन यह मेरे लिए काम करता है क्योंकि उपभोक्ता वेबपैक/बेबेल के माध्यम से सबकुछ डाल रहा है और इसे लापता एक्सटेंशन में भरना होगा मेरे लिए। मैं अब गति में हूं। यह मेरे साथ भी नहीं हुआ था कि मेरा "पैकेज" पहले वेबपैक के माध्यम से यात्रा के बिना ब्राउज़र में मूल रूप से काम नहीं करेगा।

हाँ, यह एक कठिन है।

@thw0rted मैं वेबपैक/बेबेल का उपयोग नहीं करता, इसलिए बॉक्स से .js को हल करना मेरे लिए समस्या है।
कुछ समाधान/समाधान डिफ़ॉल्ट समाधान स्रोतों के लिए वेब सर्वर को कॉन्फ़िगर कर रहा है।

क्षमा करें यदि मैं वही दोहरा रहा हूं जो दूसरों ने कहा है, लेकिन यह एक ऐसी चीज है जिससे मैं हर दिन निपटता हूं इसलिए मैं अपने दो अनचाहे दो सेंट में फेंकना चाहूंगा।

मुझे पता है कि टाइपस्क्रिप्ट को किसी विशेष वातावरण (नोड.जेएस, वेबपैक, आदि) को पूरा करने की आवश्यकता नहीं है, लेकिन तथ्य यह है कि बहुत सारे वातावरण हैं जहां एक्सटेंशन हमेशा आवश्यक होता है, जब तक कि अन्यथा विशेष रूप से कॉन्फ़िगर नहीं किया जाता है, इसलिए मैं नहीं करता मुझे नहीं लगता कि उन्हें नजरअंदाज किया जाना चाहिए। आयात अब नोड में ध्वज के पीछे नहीं हैं और आयात पथ को वेब पर यूआरएल पथनाम से मेल खाना है। जबकि URL के अंत में .js होने की कोई तकनीकी आवश्यकता नहीं है, यह वास्तविक मानक है।

यदि Microsoft के अच्छे लोग वास्तव में चाहते हैं कि कोई फ़ाइल एक्सटेंशन डिफ़ॉल्ट न हो, तो मैं इसके बारे में बहस नहीं करूंगा। आप शायद मुझसे ज्यादा होशियार हैं, लेकिन मुझे निश्चित रूप से खुशी होगी अगर यह अनुमान लगाने के बजाय कि एक ही फाइल में अन्य आयातों के आधार पर एक्सटेंशन की आवश्यकता है या नहीं, जिसे प्रोजेक्ट-वाइड सेट किया जा सकता है, इसलिए यह पहले के लिए Intellisense स्वत: पूर्ण के लिए काम करेगा। आयात एक फ़ाइल में जोड़ा गया!

इस बीच, क्या किसी को किसी भी VSCode प्लगइन्स के बारे में पता है जो इसे ठीक करता है? एस्लिंट में इम्पोर्ट/एक्सटेंशन जोड़ना सबसे अच्छा है जो मैं इससे निपटने के लिए कर पाया हूं।

वर्तमान में मैं .js एक्सटेंशन के बिना import लाइनें लिखता हूं, और फिर आउटपुट फ़ाइलों में .js एक्सटेंशन जोड़ने के लिए sed का उपयोग करता हूं।
https://github.com/yoursunny/NDNts/blob/9f50fcec245b33c7649fa815bbb3dd404eee160e/mk/build.sh#L12 -L14
मुझे उत्पादन निर्माण के दौरान SourceMaps को हटाना होगा, क्योंकि आउटपुट फ़ाइलों को संशोधित करने के बाद वे अब मेल नहीं खाएंगे।

मैं .ts स्रोत फ़ाइलों में .js एक्सटेंशन नहीं लिख सकता क्योंकि यह ts-jest को तोड़ता है।
जबकि संकलित .js फ़ाइलों पर जेस्ट चलाना संभव है, यह Coveralls को तोड़ता है।

@yoursunny हां, sed वैरिएंट है (मैंने इसका इस्तेमाल भी किया था, लेकिन कॉन्फिग की वजह से रिप्लेस-इन-फाइल पसंद करते हैं, जिसे इंपोर्टमैप फाइल मैपिंग द्वारा कॉन्फ़िगर किया जा सकता है) जेनरेटेड जेएस-फाइल्स में स्ट्रिंग्स को बदलने के लिए, लेकिन यह अच्छी तरह से गंध नहीं करता है =) हो सकता है एक्सटेंशन जोड़ना ट्रांसफॉर्म प्लगइन के साथ ttypescript के लिए उपयोगी फीचर/विकल्प होगा (उदाहरण के लिए @MicahZoltu द्वारा टाइपस्क्रिप्ट-ट्रांसफॉर्म-पथ )।

@richardkazuomiller यह हिस्सा सच नहीं है:

यदि Microsoft के अच्छे लोग वास्तव में चाहते हैं कि कोई फ़ाइल एक्सटेंशन डिफ़ॉल्ट न हो

केवल टाइपस्क्रिप्ट:

1. नोड-आवश्यकता-शैली मॉड्यूल रिज़ॉल्यूशन के लिए अनुमति देता है (उन्हें नोड-आयात-शैली रिज़ॉल्यूशन की अनुमति देने के लिए इसका विस्तार करना चाहिए, जिसके लिए फ़ाइल एक्सटेंशन की आवश्यकता होती है)।
2. उसी संकलन इकाई में, .js फ़ाइलों को एक .js/.d.ts जोड़ी में हल करता है, इससे पहले कि वे कंपाइलर द्वारा उत्पन्न हों।
3. आयात विनिर्देशकों को _बिल्कुल, कभी भी संशोधित नहीं करता है।

तो इस सब का समाधान केवल .js एक्सटेंशन के साथ .js फ़ाइलों को आयात करना है। टाइपस्क्रिप्ट सही .ts फ़ाइल को हल करेगा और आयात विनिर्देशक को संशोधित नहीं करेगा, इसलिए चीजें सिर्फ ब्राउज़र और नोड> = 13.2 में काम करेंगी।

@yoursunny क्या आपने ts-jest के खिलाफ बग फाइल की? वे यहां वास्तविक टाइपस्क्रिप्ट मानक से हट रहे हैं। अगर यह .js फ़ाइलों पर स्रोत मानचित्रों का उपयोग नहीं कर सकता है तो यह Coveralls में एक बग की तरह भी लगता है।

क्या आपने ts-jest के खिलाफ बग फाइल किया है? वे यहां वास्तविक टाइपस्क्रिप्ट मानक से हट रहे हैं।

नहीं, क्योंकि मैं पूरी तरह से नहीं समझता कि ts-jest संकल्प कैसे काम करता है।

अगर यह .js फ़ाइलों पर स्रोत मानचित्रों का उपयोग नहीं कर सकता है तो यह Coveralls में एक बग की तरह भी लगता है।

Coveralls मेरी निर्माण प्रक्रिया से एक lcov रिपोर्ट प्राप्त करता है, और फिर GitHub के लिए प्रतिबद्ध फ़ाइलों का उपयोग करके कोड कवरेज प्रदर्शित करता है।
मैं गिटहब को आउटपुट .js फाइल नहीं करता हूं। यदि मैं .js फ़ाइलों पर इकाई परीक्षण चलाता हूँ, तो lcov रिपोर्ट उन .js फ़ाइलों का संदर्भ देगी जो GitHub पर मौजूद नहीं हैं।
इसलिए, Coveralls स्रोत फ़ाइलें ढूँढने में असमर्थ हैं। यह कवरेज प्रतिशत प्रदर्शित करेगा, लेकिन यह नहीं दिखा सकता कि कौन सी लाइनें कवर नहीं हैं।

नया युग यहाँ है!

हाल ही में जारी Node.js v13 और सभी प्रमुख ब्राउज़र मूल ES मॉड्यूल का समर्थन करते हैं, और टाइपस्क्रिप्ट के लिए इन वातावरणों को सरल तरीके से समर्थन देना बहुत अच्छा होगा।

सबसे बुनियादी उपयोग के मामलों (एक साधारण स्थिर फ़ाइल सर्वर के माध्यम से दी जाने वाली वेबसाइट) के लिए सबसे सरल समाधान "appendJsExtension": true या इसी तरह का एक नया कंपाइलर विकल्प जोड़ना होगा।

@mjbvz आपके द्वारा बंद किए गए वीएस कोड के रेपो में मुद्दा थोड़ा अलग है: यह स्वचालित रूप से आयात विवरण जोड़ने के लिए स्वत: पूर्ण का उपयोग करने के बारे में है; जब वीएस कोड ऐसा करता है तो .js एक्सटेंशन के बिना आयात विवरण जोड़ता है, और रनटाइम विफलता तक इसे अनदेखा करना आसान होता है।

हालांकि अगर टाइपस्क्रिप्ट "appendJsExtension": true या इसी तरह का कोई विकल्प जोड़ता है, तो इससे कोई फर्क नहीं पड़ेगा, और हम स्रोत में .js के बिना TS कोड लिखने में सक्षम होंगे।

हो सकता है कि वीएस कोड प्लगइन में स्वतः पूर्ण आयात विवरणों में .js एक्सटेंशन के ऑटो-जोड़ को सक्षम/अक्षम करने का विकल्प होना चाहिए?

@mjbvz वीएस कोड/इंटेलिजेंस मुद्दा संबंधित है, लेकिन इसे डुप्ली के रूप में बंद नहीं किया जाना चाहिए। यदि इस मुद्दे को अंततः WONTFIX के रूप में बंद कर दिया जाता है, तो यह वास्तव में VS कोड मुद्दे के महत्व को बढ़ा देगा।

मैं एक बिंदु को अनदेखा कर रहा हूं और समझ नहीं पा रहा हूं कि जेएस एक्सटेंशन विशेष आवरण वाले समाधान इसे कैसे हल करेंगे: ईएसएम के लिए, किसी भी एक्सटेंशन की विशेष स्थिति नहीं है, यहां तक ​​​​कि विस्तारहीन फाइलें भी पूरी तरह से ठीक हैं जब तक कि सर्वर उन्हें ब्राउज़र में सेवा देता है उपयुक्त टेक्स्ट/जावास्क्रिप्ट MIME प्रकार। इसका मतलब है कि कोड जैसे:

import something from './javascript-code.png';
import something2 from './javascript-code2.js';
import something3 from './javascript-code3.ts';

यह सब तब तक मान्य है जब तक फाइलें (उनके एक्सटेंशन की परवाह किए बिना) में जावास्क्रिप्ट कोड होता है और जावास्क्रिप्ट MIME प्रकार के साथ ब्राउज़र में परोसा जाता है।

चूंकि टाइपस्क्रिप्ट जावास्क्रिप्ट का एक टाइप-सुरक्षित सुपरसेट होना चाहिए, मुझे ऊपर वाले जैसे आयात की अनुमति देने का कोई रास्ता नहीं दिखता है, क्योंकि कोड वैध जावास्क्रिप्ट है और यदि टाइपस्क्रिप्ट इसे स्वीकार नहीं करेगा, तो यह एक सुरक्षित सुपरसेट नहीं रह जाता है जावास्क्रिप्ट का, क्या यह सही नहीं है?

तो समाधान जहां जेएस एक्सटेंशन या तो निहित है या केवल एक ही अनुमति है जो मुझे नहीं लगता कि इसे काट सकता है? इसके अलावा, यहां तक ​​​​कि TS और DTS एक्सटेंशन IMO विशेष आवरण नहीं हो सकते हैं, क्योंकि सामान्य रूप से ऐसा नहीं होता है, लेकिन उनमें जावास्क्रिप्ट कोड हो सकता है, न कि टाइपस्क्रिप्ट कोड और ब्राउज़र के लिए सर्वर, जैसे कि जहां तक ​​ESM का संबंध है, कोई समस्या नहीं है। , यह देखते हुए कि उन्हें सही MIME प्रकार दिया गया है।

क्या मुझे इस मोर्चे पर कुछ याद आ रहा है? क्या टाइपस्क्रिप्ट के लिए कोड आयात में मनमाने (लापता सहित) एक्सटेंशन के लिए समर्थन लागू नहीं करना संभव है, और क्या टाइपस्क्रिप्ट के लिए मॉड्यूल आयात में टीएस एक्सटेंशन को जारी रखना संभव है, यह देखते हुए कि file.ts और file (कोई विस्तार नहीं) तो क्या संघर्ष का परिणाम होगा?

वेब और सर्विस वर्कर्स को ES मॉड्यूल इम्पोर्ट/एक्सपोर्ट के लिए भी सपोर्ट मिल रहा है ।

मैं एक कंपाइलर विकल्प के रूप में उनके विचार को लागू करने के @trusktr के विचार का पूर्ण समर्थन और समर्थन करता हूं। ऐसा नहीं है कि मैं वेबपैक और रोलअप जैसे बंडलर से छुटकारा पाना चाहता हूं। लेकिन मुझे विश्वास है कि इस तरह की एक सुविधा बंडलर स्थापित करने में लगने वाली बहुत सारी परेशानी और समय को दूर कर देगी, जब आप केवल हुप्स के माध्यम से कूदने या अजीब वर्कअराउंड का उपयोग किए बिना एक साधारण टाइपस्क्रिप्ट प्रोजेक्ट को संकलित करना चाहते हैं।

कृपया इसे टाइपस्क्रिप्ट कंपाइलर के लिए एक विकल्प के रूप में मानें। <3

क्या किसी को किसी भी तरह के मॉड्यूल सिस्टम का उपयोग करके वेबपैक या --outFile के बिना ब्राउज़र में संकलित व्यक्तिगत जेएस फाइलों को चलाने के तरीके के बारे में पता है?

मेरी समस्या यह है: जिस काफी बड़े टाइपस्क्रिप्ट प्रोजेक्ट के साथ मैं काम कर रहा हूं, उसे वेबपैक के साथ ts-loader का उपयोग करके एक बंडल जेएस फ़ाइल में संकलित करने में लगभग 35 सेकंड लगते हैं।
जिस तरह से मैं इसे अनुकूलित कर सकता था वह transpileOnly का उपयोग कर रहा था जिसने संकलन समय को 20 सेकंड तक घटा दिया लेकिन यह अभी भी धीमा है और मैंने टाइप चेकिंग खो दी है।
वेबपैक से छुटकारा पाने के लिए मुझे आउटफाइल का उपयोग करके लगभग 14 सेकंड मिल सकते हैं लेकिन यह अभी भी मेरे लिए बहुत धीमा है। incremental का उपयोग करने से कोई फर्क नहीं पड़ा।

संकलन समय के कुछ सेकंड तक पहुंचने का एकमात्र तरीका 1 जेएस फ़ाइल प्रति 1 टीएस फ़ाइल उत्सर्जित करना और incremental ध्वज का उपयोग करना था। इस मामले में मुझे लगता है कि ts केवल उन फाइलों का पता लगाता है और संकलित करता है जो वास्तव में बदल गई हैं। मुद्दा यह है कि मैं इसे किसी भी मॉड्यूल लक्ष्य में ब्राउज़र में चलाने के लिए नहीं प्राप्त कर सका: सिस्टम, एएमडी, ईएस 6।
मैं paths मैपिंग का उपयोग tsconfig.json में कर रहा हूं और संकलित जेएस फाइलों में मुझे जो त्रुटियां मिल रही हैं वे ज्यादातर उन उपनामों को हल करने में सक्षम नहीं होने से संबंधित हैं।

क्या इसे प्राप्त करने का कोई तरीका है?

@andrewvarga मैं वर्तमान में अपने सभी संकलित टाइपस्क्रिप्ट को सीधे ब्राउज़र में बिना किसी फ़ाइल को बंडल या संकलित किए चलाता हूं। ऐसा करने का सबसे आसान तरीका है:

1. सुनिश्चित करें कि टाइपस्क्रिप्ट फ़ाइलों में सभी आयातों में .js एक्सटेंशन है।
2. एक देव सर्वर चलाएँ जो निर्भरता के लिए npm पैकेज नामों के आयात को हल करता है, यदि आवश्यक हो। es-dev-server मुझे पता है कि सबसे सरल है।
3. tsc --watch चलाएँ (सुनिश्चित करें कि मॉड्यूल आपके tsconfig में esnext है)

बस, इतना ही। यदि आप अपने टाइपस्क्रिप्ट में आयात के लिए केवल .js एक्सटेंशन लिखते हैं, तो आपको ब्राउज़र के लिए फ़ाइलों को ठीक करने के लिए अन्य टूलिंग की आवश्यकता नहीं है।

@justinfagnani दोस्त, आप जानकारी का सबसे महत्वपूर्ण टुकड़ा भूल गए - प्रकार jsdoc प्रारूप में होना चाहिए, देशी जावास्क्रिप्ट पर कोई भी टाइपस्क्रिप्ट अबास्ट्रक्शन पार्सर को विफल कर देगा।

@Draccoz tsc जावास्क्रिप्ट आउटपुट करेगा, टाइपस्क्रिप्ट नहीं।

@andrewvarga बंडलिंग के बिना ट्रांसपाइल करने का सबसे आसान तरीका मेरा प्रोजेक्ट Zwitterion है। इसे एक स्थिर फ़ाइल सर्वर के प्रतिस्थापन के लिए डिज़ाइन किया गया है, ताकि आपको अपने विकास के तरीके को बदलने की आवश्यकता न हो। आप स्क्रिप्ट तत्वों में भी स्पष्ट फ़ाइल एक्सटेंशन (जावास्क्रिप्ट के लिए .js और टाइपस्क्रिप्ट के लिए .ts) के साथ आयात और निर्यात कर सकते हैं। यह बहुत ही प्रदर्शनकारी है, जब फाइलें बदलती हैं तो कैशिंग और ऑटो-रीलोडिंग करता है। हालांकि आपको स्थिर विश्लेषण (टाइप एरर) के लिए अपने संपादक पर निर्भर रहना होगा

@andrewvarga मैं https://github.com/Zoltu/typescript-transformer-append-js-extension/ का उपयोग करता हूं और देशी ES मॉड्यूल को लक्षित करता हूं जो सभी आधुनिक ब्राउज़रों में लोड होते हैं (सफारी को छोड़कर, नया IE)।

यदि आपका रनटाइम NPM निर्भरताएँ बहुत सीमित हैं, तो आप उन्हें बिना किसी बंडलिंग के es-modules-shim के साथ लोड कर सकते हैं। आप मेरे द्वारा बनाया गया एक प्रतिक्रिया टेम्पलेट देख सकते हैं जो यह सब एक साथ काम करते हुए दिखाता है: https://github.com/Zoltu/react-es2015-template

@MicahZoltu Safari में ES मॉड्यूल का समर्थन है, मुझे पता है कि वास्तव में, कैनियस और व्यक्तिगत अनुभव के आधार पर: https://caniuse.com/#search =modules

@justinfagnani awww क्षमा करें, "संकलित टाइपस्क्रिप्ट" भाग को याद किया, सोचा कि आप jsdoc टाइपस्क्रिप्ट के बारे में बात कर रहे हैं।

विभिन्न युक्तियों के लिए आप सभी का धन्यवाद!

मैंने जो पाया वह यह है कि वेबपैक के लिए hard-source-webpack-plugin npm मॉड्यूल और ts-loader विकल्पों में transpileOnly: true का उपयोग करके बिल्ड समय को लगभग 4-5 सेकंड तक कम कर दिया।
यह निश्चित रूप से टाइपस्क्रिप्ट त्रुटियों को अनदेखा कर देगा, इसलिए यह निर्माण के त्वरित पुनरावृत्तियों, ब्राउज़र में कोशिश करने और किसी भी संभावित त्रुटियों के लिए आईडीई पर निर्भर होने के लिए उपयोगी है, लेकिन मुझे लगता है कि यह विकास के दौरान बहुत उपयोगी है।

टीएस त्रुटियों और तेजी से संकलन दोनों को प्राप्त करने के लिए मुझे अभी भी लगता है कि ब्राउज़र में मॉड्यूल चलाने का एकमात्र तरीका होगा लेकिन आयात-मानचित्र और जेएस एक्सटेंशन के समर्थन की कमी ने इसे मुश्किल बना दिया।
@justinfagnani @MicahZoltu धन्यवाद, मैं उन विकल्पों को आजमाउंगा। आम तौर पर मैं एक और एनपीएम मॉड्यूल का उपयोग करने से बचना पसंद करता हूं लेकिन ऐसा लगता है कि यह अनिवार्य है।

मैंने इसे systemjs का उपयोग करके भी काम करने की कोशिश की, लेकिन मैं आयात मानचित्रों के साथ फंस गया।

@andrewvarga आप इंपोर्टमैप के साथ मेरे हल्के उदाहरण से SystemJs आज़मा सकते हैं।
आप मेरे भारी उदाहरण - systemjs और esm विकल्प को भी आज़मा सकते हैं, लेकिन esm importmaps देशी द्वारा समर्थित नहीं हैं, और हमें मॉड्यूल को मैन्युअल रूप से हल करना चाहिए (gulp-replace), या आप es-module-shims आज़मा सकते हैं।

तो अगर मैं अपने मॉड्यूल प्रकार के रूप में tsc का उपयोग अपने एकमात्र कंपाइलर के रूप में कर रहा हूं, esnext या es2015 को लक्षित कर रहा हूं। क्या कोई तरीका है जिससे मैं सीधे अपने ब्राउज़र में आउटपुट का उपयोग कर सकता हूं?

https://github.com/alshdavid-sandbox/typescript-only-compiler

अगर मैं इस धागे के बाकी हिस्सों को सही ढंग से समझता हूं, तो अगर आप इस लाइन को from "./module.js" कहने के लिए बदलते हैं तो टाइपस्क्रिप्ट को आपके कोड को संकलित करने में पूरी तरह से खुशी होनी चाहिए। फिर संकलित index.js में एक वैध ES6 आयात विवरण होगा और यह सब काम करना चाहिए।

यह तब तक है जब तक आप कुछ पुस्तकालय आयात नहीं करते हैं जो या तो ईएस आयात करना नहीं जानता है या परवाह नहीं करता है: पी।

मैंने गल्प के लिए एक प्लगइन बनाया जो फ़ाइल पथ आयात करने के लिए .js जोड़ता है। (एक बोनस टीएस पथ संकल्प भी)।

मैंने गुलप का उपयोग किया क्योंकि मुझे किसी अन्य कार्य धावक के बारे में पता नहीं है जो मुझे अनिवार्य रूप से टीएससी कंपाइलर (घड़ी और सामान्य मोड दोनों) में एक साधारण पोस्ट-प्रोसेसिंग चरण संलग्न करने की अनुमति देगा। वेबपैक और रोलअप दोनों विशेष रूप से बंडल हैं, और मैं es मॉड्यूल का उत्सर्जन करना चाहता हूं।

यह काम करता है लेकिन यह देखने में धीमा है क्योंकि ऐसा लगता है कि यह पूरी चीज का पुनर्निर्माण करता है।

https://github.com/alshdavid-sandbox/typescript-only-compiler/tree/gulp

यह और अधिक महत्वपूर्ण होता जा रहा है क्योंकि नोड टीम ने विस्तारहीन आयात के खिलाफ निर्णय लिया है
https://github.com/nodejs/modules/issues/444

एक्सटेंशन रहित आयात के विरुद्ध तय किए गए आयात मानचित्र जोड़ें
https://github.com/WICG/import-maps/issues/194

यदि हम ब्राउज़र या नोड में टाइपस्क्रिप्ट संकलित एस मॉड्यूल का उपयोग करना चाहते हैं तो हमें टाइपस्क्रिप्ट द्वारा एक्सटेंशन जोड़े जाने की आवश्यकता है? (आंतरिक मॉड्यूल के लिए) और मैन्युअल रूप से बाहरी मॉड्यूल के लिए? @weswigham

@chyzwar फिर से, यदि आप अपने टाइपस्क्रिप्ट स्रोत में केवल .js एक्सटेंशन लिखते हैं, तो संकलित आउटपुट में सही एक्सटेंशन होंगे और मॉड्यूल ब्राउज़र और Node. आपके लिए कुछ भी करने के लिए आपको अतिरिक्त रूपांतरण टूल या tsc की आवश्यकता नहीं है।

डेवलपर के लिए निम्न कार्य करना आसान है: यदि यह टाइपस्क्रिप्ट स्रोत फ़ाइल है, तो .ts एक्सटेंशन लिखें। यदि यह एक जावास्क्रिप्ट स्रोत फ़ाइल है, तो एक .js एक्सटेंशन लिखें। यह ब्राउज़र में सही ढंग से संकलित और चलाएगा (.ts को एक एप्लिकेशन/जावास्क्रिप्ट MIME प्रकार की आवश्यकता होगी)। एक्सटेंशन स्रोत फ़ाइल प्रकार से मेल खाना चाहिए। tsc और ES मॉड्यूल इसे संभाल सकते हैं (ब्राउज़र में कम से कम ES मॉड्यूल, उम्मीद है कि Node.js उसी का अनुसरण करता है)

@justinfagnani tsc इससे काफी खुश हैं, और यहां "हमारी समस्या नहीं" कहना उचित है, लेकिन क्या सही है, इसके बारे में यहां कोई आम सहमति नहीं है,

टीएससी, बनामकोड, वेबपैक और टीएस-नोड के बीच कोई भी वास्तव में एक मानक के खिलाफ अच्छी तरह से सहमत नहीं हो सकता है जो अभी मूल रूप से उपलब्ध हो रहा है (अब उपलब्ध ब्राउज़र और नोड)।

उदाहरण 1

मैं एक आधुनिक जावास्क्रिप्ट पैकेज लिखना चाहता हूं, इसे टाइपस्क्रिप्ट में लिखना चाहता हूं और एक एक्मास्क्रिप्ट मॉड्यूल (आयात और निर्यात विवरण बनाए रखना) के रूप में वितरण के लिए प्रकारों को अलग करना चाहता हूं।

उदाहरण 2

मैं बनामकोड में मॉड्यूल का उपयोग करके एक स्थिर वेबसाइट बना रहा हूं, डिफ़ॉल्ट रूप से यह प्रत्येक पहले आयात के लिए एक्सटेंशन के बिना ऑटो आयात करेगा और आपको इसे मैन्युअल रूप से समायोजित करने की आवश्यकता है।

इन मामलों में, tsc इसे संभाल सकता है, और यहां तक ​​​​कि एक तरफ डिस्क्रिप्टर फ़ाइलों को निर्यात कर सकता है जो पूर्ण टाइपिंग (भयानक) के साथ टाइपस्क्रिप्ट से es मॉड्यूल वितरण का समर्थन करते हैं।

लेकिन अगर मैं स्रोत के खिलाफ टेस्ट कोड चलाना चाहता हूं, तो मैं टीएस-नोड का उपयोग कर सकता हूं लेकिन यहां टीएस-नोड खुश नहीं है।

इसी तरह, यह तथ्य कि tsc, vscode और webpack निम्नलिखित कार्य करने के लिए विकसित हुए हैं:

1. एक एक्सटेंशन के बिना vscode ऑटो आयात
2. tsc ts फ़ाइल के अर्थ के रूप में एक js फ़ाइल में आयात को खुशी से फिर से लिख देगा
3. डिफ़ॉल्ट एक्सटेंशन खोजने के लिए वेबपैक यहां विभिन्न जादू करता है

क्या सभी चीजें हैं जिन पर अब सवाल उठाया जाना चाहिए कि चार कार्यान्वयन (क्रोम, फ़ायरफ़ॉक्स, सफारी, नोड) सभी उम्मीद करते हैं कि आयात पथ किसी ऐसी चीज को इंगित करना चाहिए जो सीधे फ़ाइल को हल कर सके।

किसी आयात में .js जोड़ना एक अस्थायी समाधान होना चाहिए, निश्चित समाधान नहीं। अगर कुछ भी, यह एक हैक की तरह लगता है। संकलक को मूर्ख बनाने का एक तरीका। और एक कंपाइलर को आउटसोर्स करने की कोशिश करना इम्हो का पालन करने के लिए एक भयानक विचारधारा है। मैं केवल कल्पना कर सकता हूं कि टाइपस्क्रिप्ट के लिए नए लोगों के लिए यह कितना भ्रमित करने वाला होगा। एक भाषा जो जावास्क्रिप्ट डेवलपर्स को _better_ कोड लिखने में मदद करनी चाहिए।

जैसा कि पहले ही उल्लेख किए गए लोगों की संख्या है, यदि आप आयात में .js जोड़ते हैं, तो टाइपस्क्रिप्ट उन्हें आउटपुट करेगा और सब कुछ काम करता है (कम से कम आपके कोड के भीतर)। यह तर्क देना कि tsc को एक्सटेंशन जोड़ना चाहिए क्योंकि वे ब्राउज़र में काम नहीं करते हैं, टाइपस्क्रिप्ट को डेवलपर द्वारा उत्पन्न रनटाइम त्रुटियों को ठीक करने के लिए कहने जैसा है - ठीक है, लेकिन डेवलपर उन्हें स्वयं/स्वयं ठीक क्यों नहीं कर सकता है?
मुझे गलत मत समझो, मैं चाहता हूं कि tsc मेरी एकमात्र देव निर्भरता हो, लेकिन कुछ चीजें बस नहीं होंगी और एक सपने के रूप में रहेंगी।

मैं चाहता हूं कि tsc मेरी एकमात्र देव निर्भरता हो, लेकिन कुछ चीजें बस नहीं होंगी और एक सपने के रूप में रहेंगी।

मैंने कई वर्षों तक #3469 पर दर्जनों लगभग समान टिप्पणियों को देखा होगा, जिनमें से कुछ टाइपस्क्रिप्ट टीम से भी शामिल हैं। "यह एक टाइप-चेकर है, इसे एक काम अच्छी तरह से करना चाहिए, यह उम्मीद न करें कि यह आपके पूरे टूलचेन को बदल देगा ..." इसमें 3 साल लग गए, लेकिन उन्होंने अभी भी बिल्ड मोड जोड़ा, क्योंकि एक अच्छा मामला बनाया गया था कि यह था जाने की सही दिशा।

वेबपैक और रोलअप दोनों विशेष रूप से बंडल हैं, और मैं es मॉड्यूल का उत्सर्जन करना चाहता हूं।

@alshdavid रोलअप आपके लिए काम कर सकता है यदि आप आउटपुट स्वरूप को esm पर सेट करते हैं और preserveModules से true पर सेट करते हैं: https://rollupjs.org/guide/en/#preservemodules

शायद "विस्तार रहित" आयात एक मूल पाप था, ब्राउज़र के काम करने के तरीके के अनुकूल नहीं था

अब हमारे स्रोत कोड को ठीक करने और .js एक्सटेंशन शामिल करने का समय आ गया है: हम पाते हैं कि जब आप आज अपने स्रोत कोड में .js एक्सटेंशन जोड़ते हैं, तो सब कुछ काम करता है: ब्राउज़र संतुष्ट है, टाइपस्क्रिप्ट अज्ञेयवादी है, और बंडलर परवाह नहीं है

तो शायद विस्तारहीन हमारे स्रोत कोड में एक दोष था जिसकी भरपाई हमारी पुरानी टूलिंग कर रही थी

टाइपस्क्रिप्ट स्रोत कोड में आयात में .js एक्सटेंशन लिखना पूरी तरह बकवास है। यह काम कर रहा है, यह आउटपुट में एक्सटेंशन को सुरक्षित रखता है, लेकिन यह संभवत: VSCode में ESLint नियमों (या टाइपस्क्रिप्ट) या आप जिस भी संपादक का उपयोग कर रहे हैं, उसमें "फ़ाइल को हल नहीं कर सका" त्रुटियों के साथ विफल हो जाएगा। जब आप उस टाइपप्रति स्रोत कोड के विरुद्ध परीक्षण कर रहे हों तो उल्लेख नहीं करना चाहिए। तब परीक्षण उपकरण को उस बकवास व्यवहार के बारे में भी पता होना चाहिए। मुझे पूरा यकीन है कि यह त्रुटियों को फेंक देगा कि यह फाइलों को हल नहीं कर सकता है।

मूल उदाहरण

src/index.ts
src/foo.ts
test/index.ts

स्रोत/foo.ts

export default (a: number) => a + 100;

src/index.ts

// okay, editor (without ESLint) doesn't report error here
import foo from './foo.js';

export default () => {
  console.log(foo(123));
}

परीक्षण/index.ts

// errm... ts or js ext?! .ts should be the one that make sense
// and that's how the testing too will expect it to be, otherwise will throw
// but then it will detect some weird `.js` ext in the source files...
// which again won't be able to resolve... complete bullshit. 
import main from '../src/index.ts';
import foo from '../src/foo.ts';

test('some boolshit', () => {
  main();
});

test('about foo', () => {
  foo(20);
});

"बकवास" उपयोग के लिए क्षमा करें, लेकिन यह सच है।

मुझे नहीं लगता कि मूल विकल्प को लागू करना इतना कठिन है कि जब संकलक आयात में एक्सटेंशन ( .ts ) देखता है तो इसे .js में परिवर्तित कर देता है (या वैकल्पिक रूप से यह निर्दिष्ट करने की अनुमति देता है कि आउटपुट क्या है होना)। जब कोई एक्सटेंशन न हो, तो एक्सटेंशन को सुरक्षित न रखें (अर्ध-वर्तमान व्यवहार?)

टाइपस्क्रिप्ट सोर्स कोड में इम्पोर्ट में .js एक्सटेंशन लिखना पूरी तरह से बकवास है। यह काम कर रहा है, यह आउटपुट में एक्सटेंशन को सुरक्षित रखता है, लेकिन यह संभवत: VSCode में ESLint नियमों (या टाइपस्क्रिप्ट) या आप जिस भी संपादक का उपयोग कर रहे हैं, उसमें "फ़ाइल को हल नहीं कर सका" त्रुटियों के साथ विफल हो जाएगा।

यह सच नहीं है। ESLint, टाइपस्क्रिप्ट, VS कोड, और हर दूसरे टाइपस्क्रिप्ट-संबंधित टूल का मैंने इस विधि के साथ _just work_ का उपयोग किया है। यह एक हैक नहीं है, और इसके चारों ओर एक बहुत ही उचित तर्क है: कि जिस फ़ाइल को आप आयात कर रहे हैं वह वास्तव में _is_ .js फ़ाइल है, और आपके एक्सटेंशन केवल इसलिए नहीं बदलने चाहिए क्योंकि एक आयातित फ़ाइल स्थानीय का हिस्सा है प्रोजेक्ट, या किसी तृतीय-पक्ष पैकेज के भाग के रूप में पूर्व-संकलित।

दोबारा, मैं अपने सभी टाइपस्क्रिप्ट कोड इस तरह लिखता हूं और यह इस धागे में लाई गई सभी समस्याओं को हल करता है। आउटपुट ब्राउज़र और Node. में बढ़िया काम करता है। यह बकवास नहीं है, यह सिर्फ काम करता है, _आज_।

नहीं यह नहीं। कम से कम सबसे आम मामले में जहां आउटपुट निर्देशिका dist या build या lib और आदि है। आपकी संकलित फ़ाइलें एक ही निर्देशिका में नहीं हैं, वे कभी मौजूद नहीं हैं वहां ( src/ में) - न तो परीक्षण के दौरान, न ही संपादक में कोडिंग के दौरान।

उपरोक्त src/index.ts में ./foo.js होने/देखने और आयात करने से मुझे कोई मतलब नहीं है - बेशक यदि आप वास्तव में जेएस/जेसन फ़ाइल आयात करना चाहते हैं, जो पूरी तरह से ठीक है। लेकिन ./foo.js लिखने के लिए जब आप वास्तव में एक अन्य टाइपस्क्रिप्ट स्रोत फ़ाइल ( ./foo.ts ) का मतलब है ... क्रूर है। यह भ्रामक और भ्रमित करने वाला है, और निश्चित रूप से गलत है।

मुझे पूरा यकीन है कि अगर मैं जेस्ट के साथ उपरोक्त test/index.ts चलाता हूं तो यह त्रुटि के साथ विफल हो जाएगा कि यह ./foo.js को ढूंढ/समाधान नहीं कर सकता क्योंकि केवल ./foo.ts है।

अगर हम सब कुछ एक तरफ छोड़ देते हैं, तो इसे .js एक्सटेंशन की अनुमति क्यों है लेकिन .ts एक (संपादक में ts रिपोर्ट त्रुटि) की नहीं? यह बुनियादी, सरल और मूर्खतापूर्ण असंगति है। टाइपस्क्रिप्ट में कई अन्य "सिर्फ इसलिए" समस्याएं।

मैंने वास्तव में तर्क खो दिया है कि इस मुद्दे का नाम इस तरह क्यों रखा गया है जब वास्तव में .js एक्सटेंशन के साथ समाप्त होना संभव है। मुझे लगता है कि समस्या बिल्कुल विपरीत है - कि यह .ts (3.7+ तक) के साथ समाप्त नहीं हो सकती है

क्यों .ts आयात में विस्तार पूरी तरह से प्रतिबंधित है ?!

और स्पष्ट करते हैं। मैं विकास के समय और अनुभव के बारे में बात कर रहा हूं। मुझे यह बात समझ में आ रही है कि हम संकलित आउटपुट में .js एक्सटेंशन को संरक्षित क्यों कर सकते हैं, और हम त्रुटियों की रिपोर्ट किए बिना .ts फ़ाइल में आयात करने के लिए .js एक्सटेंशन क्यों जोड़ सकते हैं, और मैं मैं इसके साथ ठीक हूँ।

टाइपस्क्रिप्ट जावास्क्रिप्ट का सुपरसेट है लेकिन यह जावास्क्रिप्ट नहीं है। जावास्क्रिप्ट टाइपस्क्रिप्ट के लिए एक संकलन लक्ष्य है।

इस बात को ध्यान में रखते हुए, इस ज्ञान के बावजूद कि TS JS को संकलित करेगा, मुझे उम्मीद है कि टाइपस्क्रिप्ट कोड पूरी तरह से स्व-निहित जागीर में व्यवहार करेगा।

किसी .ts फ़ाइल को आयात करने का प्रयास करते समय .js लिखना लक्ष्य संकलन प्रकार का ज्ञान ग्रहण करता है और मानता है कि संकलन लक्ष्य हमेशा जावास्क्रिप्ट होता है।

क्या होगा यदि हम टाइपस्क्रिप्ट को वेब असेंबली बाइनरी में संकलित करते हैं या डेनो या टीएस-नोड जैसे वैकल्पिक रनटाइम का उपयोग करके टाइपस्क्रिप्ट कोड चलाते हैं।

.js के साथ समाप्त होने वाले आयात विवरण ऐसे संदर्भों में कोई मतलब नहीं रखते हैं।

मुझे अपने आयात पथों में .ts टाइप करने के लिए मजबूर होना पड़ेगा या कोई निर्दिष्ट एक्सटेंशन नहीं है जो टाइपस्क्रिप्ट स्रोत फ़ाइल मानता है।

यह दुख की बात है कि टाइपस्क्रिप्ट ने प्रवाह की तरह सिर्फ एक सिंटैक्स चीनी होने के बजाय अपने स्वयं के विस्तार का आविष्कार किया।

@phaux मैं कभी भी ऐसे प्रोजेक्ट के साथ काम नहीं करना चाहूंगा, जो एक ही एक्सटेंशन के तहत सोर्स और डिस्ट फाइलों को मिलाता हो, भले ही वे अलग-अलग फोल्डर में रहते हों। यह सभी फाइलों का नामकरण करने जैसा है index.js केवल इसलिए कि वे अलग-अलग फ़ोल्डरों में रहते हैं ...

यह मुद्दा (जो टाइपस्क्रिप्ट से बड़ा है) विजुअल स्टूडियो कोड के IntelliSense को वेब ब्राउज़र और नोड में काम करने से रोकता है - जिसके लिए आयात विनिर्देशों में पूर्ण (सापेक्ष) फ़ाइल पथ की आवश्यकता होती है। इसके बिना, उत्पन्न import कथन यह केवल ट्रांसपिलर और बंडलर के साथ काम करता है, जैसे वेबपैक और टाइपस्क्रिप्ट स्वयं।

VSCode टीम की प्रतिक्रिया थी कि एक्सटेंशन को उस कोड द्वारा जोड़ा जाना चाहिए जो ऑटो-आयात सुझाव प्रदान करता है। मुझे संदेह है कि यह टाइपस्क्रिप्ट भाषा सर्वर है (नहीं tsc , जिसके बारे में यहां चर्चा की गई है)।

क्या कोई व्यक्ति जो वास्तव में चीजों को जानता है, पुष्टि (या सही) कर सकता है कि VSCode को टाइपस्क्रिप्ट भाषा सर्वर से ऑटो-आयात सुझाव मिलते हैं?

स्थिति थोड़ी जटिल और बारीक है, इसलिए जब ".js" एक्सटेंशन शुरू में कई लोगों के सुरुचिपूर्ण अंतर्ज्ञान और आदर्शों के अनाज के खिलाफ जाते हैं, तो टाइपस्क्रिप्ट के लिए अनुसमर्थित ब्राउज़र मानकों और शिप किए गए कार्यान्वयन से बहुत अधिक विचलन करना मूर्खतापूर्ण और भ्रमित करने वाला हो सकता है।

तो शायद हम वर्तमान प्रतिमान को इस प्रकार मानते हैं:
टाइपस्क्रिप्ट आयात वर्णन करता है कि रनटाइम पर क्या आयात किया जाता है - यानी, आपके आयात आपकी "dist" निर्देशिका में निष्पादित हो रहे हैं, न कि "src" - जैसे fetch कॉल और बाकी - अगर हम इस विचार को सहन कर सकते हैं, तो बाकी बन जाता है सरल और सुसंगत

यह निश्चित रूप से एक बुरा विचार है कि टाइपस्क्रिप्ट को नेत्रहीन रूप से ".js" को विस्तारहीन आयातों से जोड़ना जैसे नोड कॉमनज के लिए करता है (यह ध्यान देने योग्य है कि नोड esm समर्थन के लिए ".js" उसी तरह की आवश्यकता होती है जैसे आज टाइपस्क्रिप्ट) - आँख बंद करके ".js" संलग्न करना नई समस्याएं पैदा करेगा, जैसे वास्तव में विस्तारहीन जावास्क्रिप्ट फ़ाइलें, या यहां तक ​​कि सीएसएस या जेसन जैसे अन्य फ़ाइल प्रकारों को आयात करना - यह एक्सटेंशन को सार्थक बना देगा और विशेष पार्सिंग तर्क की आवश्यकता होगी, ब्राउज़र और टाइपस्क्रिप्ट सेमेन्टिक्स के बीच एक बड़ा अंतर पैदा करेगा - और हम स्पष्ट रूप से नहीं जा रहे हैं fetch कॉल को उसी तरह फिर से लिखने के लिए, तो शायद import समान रहना चाहिए?

हालांकि, मुझे आश्चर्य है - क्या टाइपस्क्रिप्ट के लिए ".ts" एक्सटेंशन को ".js" में बदलना अपेक्षाकृत हानिरहित है?

बेशक, इससे जावास्क्रिप्ट फ़ाइल को आयात करना असंभव हो जाएगा जिसमें ".ts" एक्सटेंशन था - लेकिन हो सकता है कि यह एक अजीब जादू है जिसे हम सहन कर सकते हैं? दूसरी तरफ, यह ब्राउज़र और टाइपस्क्रिप्ट सेमेन्टिक्स के बीच एक भयानक जादुई मूर्खतापूर्ण अंतर है जिसे डेवलपर्स को सीखना और समझना होगा (निश्चित रूप से अजीब गोच्या बनाना) - इसलिए मेरी प्रवृत्ति उन चीजों को छोड़ना है जहां वे आज खड़े हैं

दूसरी ओर, अगर हम चीजों को यथावत रखते हैं, तो जादू को केवल टाइपस्क्रिप्ट में स्थानांतरित कर दिया जाता है, जिसे ".js" आयात को संबंधित ".ts" स्रोत फ़ाइलों से संबंधित करना होता है - यह मुझे एक अधिक उचित स्थान की तरह लगता है जादू का घर, ब्राउज़र शब्दार्थ को रौंदने के बजाय टाइपस्क्रिप्ट के लिए आंतरिक होना

पीछा करना

@rconnamacher , @TomasHubelbauer

यह मुद्दा (जो टाइपस्क्रिप्ट से बड़ा है) विजुअल स्टूडियो कोड के IntelliSense को वेब ब्राउज़र और नोड में काम करने से रोकता है - जिसके लिए आयात विनिर्देशों में पूर्ण (सापेक्ष) फ़ाइल पथ की आवश्यकता होती है। इसके बिना, उत्पन्न आयात विवरण यह केवल वेबपैक और टाइपस्क्रिप्ट जैसे ट्रांसपिलर और बंडलर के साथ काम करता है।

मुझे लगता है कि यहां कुछ भ्रम है - आज एक टाइपस्क्रिप्ट लाइब्रेरी या ऐप बनाना बहुत संभव है जो बनाम कोड और इंटेलिजेंस के साथ बढ़िया काम करता है, जो ब्राउज़र और नोड में काम करता है, और ईएसएम या कॉमनज में काम करता है - आज वास्तव में सार्वभौमिक समाधान संभव है

मैं मुट्ठी भर खुले पुस्तकालयों पर काम कर रहा हूं जो इसे प्रदर्शित करते हैं - रेनराकू , निंदक , रेडक्रिप्टो , सत्तावादी

मुझे एक ईमेल शूट करें और मुझे और अधिक समझाने में खुशी होगी

:लहर: पीछा

एक और बात यह है कि इससे आप जिस फाइल तक पहुंच रहे हैं उसमें भ्रम होता है। जब आपके पास .js और .ts फ़ाइल साथ-साथ हो तो मॉड्यूल रिज़ॉल्यूशन के बाद tsc क्या दिखता है, इस बारे में पहले से ही अस्पष्टता है।

/folder
  a.ts
  a.js
  index.ts

यदि index.ts में, moduleResolution: 'node' . का उपयोग करते समय

// points to a.ts
import * as a from './a` 

// points to a.ts
import * as a from './a.js` 

// compiler emits error
import * as a from './a.ts` 

जब आपके पास एक .js और .ts फ़ाइल साथ-साथ होती है, तो मॉड्यूल रिज़ॉल्यूशन के बाद tsc क्या देखता है, इस बारे में पहले से ही अस्पष्टता है।

ठीक है, निश्चित रूप से, लेकिन अगर a.js कुछ भी है, लेकिन a.ts के ट्रांसपिल्ड संस्करण के अलावा कुछ भयावह रूप से गलत हो गया है और यह टाइपस्क्रिप्ट की गलती नहीं है।

@ thw0rted यदि आप एक एकल JS बंडल फ़ाइल को संकलित कर रहे हैं, तो टाइपस्क्रिप्ट इनपुट टाइपस्क्रिप्ट फ़ाइलों के लिए केवल एक बंडल फ़ाइल के लिए JS समकक्ष उत्पन्न नहीं करेगा। उस स्थिति में, JS फ़ाइल और उसी नाम की TS फ़ाइल होना पूरी तरह से कानूनी है जो किसी भी तरह से मेल नहीं खाती है।

यह "अवैध" नहीं है, लेकिन इसका मतलब यह नहीं है कि यह एक अच्छा विचार है। क्या आपके पास कोई ठोस उदाहरण है कि आप वास्तव में यह कहाँ चाहते हैं?

बंडलर, लोडर के बिना टाइपस्क्रिप्ट का उपयोग करना अच्छा होगा और एक तरह से जो जावास्क्रिप्ट को उत्सर्जित करता है जिसे सीधे आधुनिक ब्राउज़र द्वारा उपयोग किया जा सकता है।

उदहारण के लिए:
https://github.com/alshdavid/tsc-website

लेकिन मुझे समस्या का दर्द महसूस होता है। टाइपस्क्रिप्ट टीम मॉड्यूल रिज़ॉल्यूशन को लागू नहीं करना चाहती। यही कारण है कि टाइपस्क्रिप्ट कंपाइलर संकलन समय पर paths को उनके वास्तविक सापेक्ष पथ में परिवर्तित नहीं कर सकता है।

किसी आयात को .ts से .js में कनवर्ट करना, या किसी एक्सटेंशन के बिना आयात में .js जोड़ने का मतलब है कि टाइपस्क्रिप्ट टीम मॉड्यूल रिज़ॉल्यूशन को लागू कर रही होगी और यह दायरे से बाहर है।

इसका एक समाधान टाइपस्क्रिप्ट टीम के लिए एक्सटेंशन पेश करने का एक तरीका प्रदान करना है ताकि हम इन चीजों को लागू कर सकें।

इसका एक समाधान टाइपस्क्रिप्ट टीम के लिए एक्सटेंशन पेश करने का एक तरीका प्रदान करना है ताकि हम इन चीजों को लागू कर सकें।

वे करते हैं, यह सिर्फ tsc (केवल संकलक के प्रोग्रामेटिक आमंत्रण के माध्यम से) के माध्यम से उजागर नहीं होता है। सौभाग्य से, किसी ने कोर कंपाइलर के चारों ओर एक रैपर बनाया जो _exactly_ जैसे tsc काम करता है, सिवाय इसके कि यह कॉन्फ़िगरेशन के माध्यम से एक्सटेंशन का समर्थन करता है। इस tsc रैपर का उपयोग करके, आप .js एक्सटेंशन को स्वतः जोड़ने के लिए https://github.com/Zoltu/typescript-transformer-append-js-extension/ जैसे एक्सटेंशन का उपयोग कर सकते हैं।

@alshdavid गिटहब में आपका उदाहरण बिना बंडलर के ब्राउज़र में काम करता है यदि आप आयात पर .js एक्सटेंशन शामिल करते हैं। मैंने इसे ठीक करने के लिए एक पीआर दायर किया।

@alshdavid आप मेरी नमूना परियोजना में दिलचस्प हो सकते हैं (आधुनिक के लिए esm और SystemJS के साथ IE11)।
लेकिन मैं मैन्युअल रूप से esm मॉड्यूल को हल करने के लिए मजबूर हूँ =(

मुझे अपने सभी import s में .js डालने में कोई समस्या नहीं है, लेकिन दुर्भाग्य से यह कुछ उपकरणों के साथ खराब बातचीत को उजागर करता है। उदाहरण के लिए, ts-नोड चोक: https://github.com/TypeStrong/ts-node/issues/783। यह किसकी ज़िम्मेदारी पर स्पष्ट सहमति प्रतीत नहीं होती है - टाइपस्क्रिप्ट .js एक्सटेंशन (कुछ परिस्थितियों में) को उत्सर्जित करने के लिए या हर उपकरण जो अनुवाद करने के लिए टाइपस्क्रिप्ट स्रोतों का उपभोग करता है। और जब तक हर कोई पैसा खर्च कर रहा है, उपयोगकर्ता इंटरऑप असंगतताओं के आसपास काम करने के लिए खराब-दस्तावेज प्लगइन्स या अजीब सेवा श्रमिकों से पीड़ित हैं।

क्या इस पर कोई अपडेट हैं? मैं ईमानदारी से विश्वास नहीं कर सकता कि बाहरी मॉड्यूल लोडर या वेबपैक जैसे बंडलर के बिना आज सामान्य रूप से टाइपस्क्रिप्ट का उपयोग करना संभव नहीं लगता है। यह बहुत अजीब लगता है और मुझे निराशा भी होती है। अगर टाइपस्क्रिप्ट को पूरी तरह से काम करने के लिए मुझे कुछ बाहरी मॉड्यूल का उपयोग करना है, तो उसे शुरू किया जाना चाहिए।

मैं इसे अपने इलेक्ट्रॉन ऐप में उपयोग करने की कोशिश कर रहा हूं, यही कारण है कि मुझे वेब बंडलर का उपयोग करने का कोई कारण नहीं दिख रहा है और अगर इसकी आवश्यकता नहीं है तो मैं बाहरी मॉड्यूल लोडर भी स्थापित नहीं करना चाहता हूं। लेकिन यह मुझे पागल बना रहा है। यहां तक ​​कि एक बुनियादी टाइपस्क्रिप्ट + इलेक्ट्रॉन सेटअप प्राप्त करने में सक्षम नहीं होने के बावजूद दोनों की हर जगह प्रशंसा की जाती है क्योंकि यह सबसे अच्छा समाधान है। यह पागल है, ईमानदार होने के लिए। मुझे नहीं पता कि मुझे कुछ याद आ रहा है लेकिन पर्याप्त समाधान नहीं ढूंढ पा रहा हूं, यह निराशा से कहीं अधिक है।

और अगर यह वास्तव में मैं नहीं हूं, तो मुझे समझ में नहीं आता कि इस मुद्दे को 3 साल में ठीक क्यों नहीं किया गया ...

मैंने हाल ही में टाइपस्क्रिप्ट ट्यूटोरियल पूरा किया है और फिर जब मैंने कुछ टीएस फाइलें बनाने की कोशिश की तो मैं इस मुद्दे पर आया। मैं इस जेएस-टीएस दुनिया के लिए बिल्कुल नया हूं इसलिए अगर कुछ गलत या भ्रामक/गलत सूचना दी गई है तो मुझे क्षमा करें।

मैंने जो किया वह आयात करते समय था

मैं बस ts फ़ाइल में .js एक्सटेंशन डालता हूं और फिर जब मैंने इंटेलिजेंस की जांच की तो यह तब भी काम करता है जब मैंने इसे tsc का उपयोग करके ट्रांसपाइल किया। इसमें .js एक्सटेंशन के साथ-साथ जेनरेट की गई आउटपुट फ़ाइल भी शामिल हो गई।

मैंने जो किया वह निम्नलिखित है।
टीएससी-पी

{
"संकलक विकल्प": {
// "मॉड्यूल": "एएमडी",
"मॉड्यूल": "es6",
"लक्ष्य": "es6",
"कोई लागू नहीं": झूठा,
"टिप्पणियां हटाएं": सच है,
"preserveConstEnums": झूठा,
// "आउटफाइल": "जेएस",
"आउटडिर": "जेएस",
"सोर्समैप": झूठा
},
"शामिल करना": [
"testscript.ts"
]
}

हालांकि इसने मेरे लिए काम किया।

मेरा संदेह यह है कि चूंकि आयात करने के लिए svgwrapper.js नहीं है
क्यों/कैसे काम किया? (मुझे लगता है कि यह विस्तार पर विचार नहीं करता है)

मैं संदर्भ के लिए स्क्रीनशॉट संलग्न कर रहा हूं।

@yogeshjog यह ठीक वैसा ही है जैसे tsc है और काम करने वाला है। आप फ़ाइल नाम के साथ मॉड्यूल आयात करते हैं जो उत्पन्न होगा। चाहे आयातित मॉड्यूल मूल रूप से .ts फ़ाइल के रूप में लिखा गया हो या .d.ts / .js जोड़ी आयात मॉड्यूल से देखने योग्य नहीं होनी चाहिए।

@yogeshjog यह ठीक वैसा ही है जैसे tsc है और काम करने वाला है। आप फ़ाइल नाम के साथ मॉड्यूल आयात करते हैं जो उत्पन्न होगा। चाहे आयातित मॉड्यूल मूल रूप से .ts फ़ाइल के रूप में लिखा गया हो या .d.ts / .js जोड़ी आयात मॉड्यूल से देखने योग्य नहीं होनी चाहिए।

धन्यवाद! @justinfagnani स्पष्टीकरण के लिए

आप फ़ाइल नाम के साथ मॉड्यूल आयात करते हैं जो उत्पन्न होगा।

लेकिन टाइपस्क्रिप्ट भी एक्सटेंशन को छोड़ने की अनुमति देता है, जिसकी ईसीएमएस्क्रिप्ट के अनुसार अनुमति नहीं है। यह VSCode में ऑटो-आयात सुविधा का उपयोग करते समय एक्सटेंशन को भी छोड़ देता है जो कि सबसे कष्टप्रद बात है। आप कुछ JS लिखते हैं और TS कहते हैं कि यह ठीक है और फिर यह रनटाइम में क्रैश हो जाता है।

लेकिन टाइपस्क्रिप्ट भी एक्सटेंशन को छोड़ने की अनुमति देता है

नोड रिज़ॉल्यूशन का उपयोग करते समय। tsconfig अन्य रिज़ॉल्यूशन मोड की अनुमति देने के लिए कम से कम सेटअप है जो इस बारे में चेतावनी देगा, लेकिन मेरी समझ यह है कि टीम अधिक मोड जोड़ने से पहले मूल मॉड्यूल समर्थन को व्यवस्थित कर रही है।

जिसे ईसीएमएस्क्रिप्ट के अनुसार अनुमति नहीं है।

ईसीएमएस्क्रिप्ट आयात विनिर्देशों के बारे में कुछ नहीं कहता है। यह HTML और Node जैसे परिवेशों को होस्ट करने के लिए छोड़ दिया गया है। टाइपस्क्रिप्ट मॉड्यूल लोड करते समय नोड रिज़ॉल्यूशन का समर्थन करता है, और कंपाइलर _output_ के विरुद्ध रिज़ॉल्यूशन की व्याख्या करता है, न कि कंपाइलर _input_ के। इस तरह विनिर्देशक संकलन के बाद काम करते हैं और वे इस पर ध्यान दिए बिना काम करते हैं कि आप संकलित मॉड्यूल आयात करने का प्रयास कर रहे हैं या नहीं।

क्योंकि टाइपस्क्रिप्ट नोड रिज़ॉल्यूशन का उपयोग करता है जो './foo' जानकारी './foo.js' को चालू करने के लिए पथ खोज करेगा, './foo' मान्य है। लेकिन नोड रिज़ॉल्यूशन './foo.ts' को './foo.js' में नहीं बदलेगा, इसलिए './foo.ts' अमान्य है।

लेकिन यह नोड रिज़ॉल्यूशन के भीतर है। यदि आप HTML या नोड के मूल मॉड्यूल समर्थन जैसे किसी अन्य वातावरण का उपयोग करने का प्रयास कर रहे हैं, तो टाइपस्क्रिप्ट और होस्ट इस बात से असहमत होंगे कि क्या मान्य है।

उम्मीद है कि टाइपस्क्रिप्ट के लिए एक और रिज़ॉल्यूशन सेटिंग जोड़ने के लिए देशी मॉड्यूल समर्थन अब पर्याप्त रूप से तय हो गया है।

@leontepe आपको बंडलर/लोडर की आवश्यकता नहीं है। आप या तो https://github.com/Zoltu/typescript-transformer-append-js-extension/ (मेरा पसंदीदा समाधान) का उपयोग कर सकते हैं या आप अपने सभी आयात विवरणों में .js जोड़ सकते हैं (सावधान रहें: यह होगा अपना कोड ts-node में विफल करें)।

@leontepe आपको बंडलर/लोडर की आवश्यकता नहीं है। आप या तो https://github.com/Zoltu/typescript-transformer-append-js-extension/ (मेरा पसंदीदा समाधान) का उपयोग कर सकते हैं या आप अपने सभी आयात विवरणों में .js जोड़ सकते हैं (सावधान रहें: यह होगा अपना कोड ts-node में विफल करें)।

@MicahZoltu ठीक है, धन्यवाद, लेकिन फिर भी थोड़ी निराशा होती है कि यह 'बॉक्स से बाहर' काम नहीं करता है। जैसा कि @phaux ने कहा, VSCode अपने उपयोगकर्ताओं को एक्सटेंशन के बिना आयात विवरण बनाने का सुझाव देता है और यह केवल रनटाइम में काम नहीं करता है। मैं यहां टाइपस्क्रिप्ट टीम की क्षमता पर गंभीरता से सवाल उठाता हूं या मैंने इस पूरे समय कुछ गलत किया है और मैं सिर्फ सादा बेवकूफ हूं। किंतु कौन जानता है...

संपादित करें: इस बिंदु पर जावास्क्रिप्ट + बेबेल के लिए टाइपस्क्रिप्ट को छोड़ने पर गंभीरता से विचार करें।

मैंने एक इलेक्ट्रॉन एप्लिकेशन नहीं लिखा है, लेकिन क्या इसे नोड-शैली रिज़ॉल्यूशन करने की कोई संभावना है, जहां आयात को हल करने की कोशिश करने के लिए एक एल्गोरिदम है जो एक निश्चित क्रम में कई चीजों की कोशिश करता है? ऐसा लगता है कि यह ठीक होना चाहिए कि सभी स्रोत स्थानीय संसाधनों से लोड किए जा रहे हैं ...

शायद यह TS में नया मॉड्यूल रिज़ॉल्यूशन जोड़ने का समय है? Node.js के पास अब मूल ESM समर्थन है, लेकिन सापेक्ष पथों में स्पष्ट एक्सटेंशन के बिना यह --experimental-specifier-resolution=node ध्वज का उपयोग करने के लिए मजबूर करता है, जो थोड़े कष्टप्रद है। डेनो और ब्राउजर भी हैं। आदर्श रूप में ऐसा कुछ होना चाहिए:
tsconfig.json:

{
    "compilerOptions": {
        "moduleResolution": "explicit",
        "strict": true
    }
}

फिर टाइपप्रति:

import foo from './foo.ts'; // no ts(2691) here

जावास्क्रिप्ट के लिए संकलित करता है:

import foo from './foo.js';

"सख्त": सच का मतलब बहुत काम है!
2020, अभी भी ठीक नहीं है, हास्यास्पद है।

केवल यह कहने में झिझकना कि यह समस्या हमारी टीम को भी अवरुद्ध कर रही है

हम वास्तव में एक एकल स्रोत प्राप्त करने में सक्षम होना चाहते हैं जो मूल मॉड्यूल बनाता है और नोड में और वेबपैक के साथ भी उपभोज्य है। यदि आप अपने TS कोड में अपने आयात में मैन्युअल रूप से .js डालते हैं तो Webpack में कोई समस्या प्रतीत होती है। हालाँकि, यदि आप अपने आयात में .ts फ़ाइल एक्सटेंशन डालते हैं, तो आप काम करने के लिए वेबपैक प्राप्त कर सकते हैं, लेकिन निश्चित रूप से टाइपस्क्रिप्ट शिकायत करता है। फ़ाइल एक्सटेंशन न होने के परिणामस्वरूप मूल मॉड्यूल नहीं होते हैं। इसलिए, कोई भी संयोजन ब्राउज़र और बंडलर को संतुष्ट नहीं करता है। अगर हम अपने आयात में .ts लिख सकते हैं और आउटपुट में .js बन जाते हैं, तो मुझे विश्वास है कि समस्या हल हो जाएगी (और आपको deno compat भी मिल जाएगा)। @ evg656e जैसा कुछ सुझाव देता है कि ऐसा लगता है कि इसे काम करना चाहिए।

@EisenbergEffect इसके लिए वेबपैक के खिलाफ एक बग दायर किया गया है? वास्तव में सामान्य टीएससी से अलग होने के लिए वेबपैक समस्या की तरह लगता है।

@justinfagnani मुझे यकीन नहीं है कि समस्या वेबपैक, टीएस-लोडर, या कहीं और है। मैंने अपना इष्टतम बिल्ड सेटअप प्राप्त करने का प्रयास करने में काफी समय बिताया और सभी बॉक्सों की जांच करने वाले किसी भी समाधान में नहीं आया। कस्टम ट्रांसफॉर्मर या पोस्ट-बिल्ड चरणों के साथ ऐसा करने के शायद तरीके हैं लेकिन मैं गैर-मानक सेटअप अपनाने के लिए अनिच्छुक हूं क्योंकि यह डाउनस्ट्रीम डेवलपर्स को नकारात्मक रूप से प्रभावित कर सकता है।

@EisenbergEffect यदि वेबपैक का टाइपस्क्रिप्ट लोडर आपको .js एक्सटेंशन जैसे tsc के माध्यम से टाइपस्क्रिप्ट फ़ाइलों को आयात करने नहीं देता है, तो यह एक बग है। जैसा आपने कहा, व्यवहार वेबपैक और tsc के साथ समान स्रोत निर्माण को रोकता है।

शायद यह TS में नया मॉड्यूल रिज़ॉल्यूशन जोड़ने का समय है? Node.js के पास अब मूल ESM समर्थन है, लेकिन सापेक्ष पथों में स्पष्ट एक्सटेंशन के बिना यह --experimental-specifier-resolution=node ध्वज का उपयोग करने के लिए मजबूर करता है, जो थोड़े कष्टप्रद है। डेनो और ब्राउजर भी हैं। आदर्श रूप में ऐसा कुछ होना चाहिए:
tsconfig.json:

{
    "compilerOptions": {
        "moduleResolution": "explicit",
        "strict": true
    }
}

फिर टाइपप्रति:

import foo from './foo.ts'; // no ts(2691) here

जावास्क्रिप्ट के लिए संकलित करता है:

import foo from './foo.js';

लोग (उदाहरण के लिए, मुझे) एक ही समय में Node.js, Deno और वेब के बीच कोड के एक टुकड़े को काम करने देना पसंद करेंगे। मुझे लगता है कि यह टाइपस्क्रिप्ट/जावास्क्रिप्ट प्रोग्रामिंग के लिए एक महान मील का पत्थर होगा।

यदि आप vscode का उपयोग कर रहे हैं और एक अंतरिम समाधान की आवश्यकता है, तो इसे settings.json में जोड़ने से समस्याएं ठीक हो जाती हैं:

"typescript.preferences.importModuleSpecifierEnding": "js"

यह आपके आयात पथों में .js जोड़ देगा (जो बिना किसी त्रुटि के स्रोत में *.ts फ़ाइलों को हल करेगा, लेकिन ट्रांसपिलिंग करते समय .js को बनाए रखेगा)। बंडलर के बिना tsc का उपयोग करते समय यह उपयोगी होता है।

जबकि हम एक tsc समाधान की प्रतीक्षा कर रहे हैं, इसका एक निम्न-तकनीकी समाधान है

1. सभी स्रोत फ़ाइलों को एक अस्थायी फ़ोल्डर में कॉपी करें
2. निर्माण से पहले आयात और निर्यात के लिए एक्सटेंशन निकालें

मैं इस वन-लाइनर को साझा करना चाहता था ताकि अन्य लोग इसका उपयोग कर सकें। यह src/ फ़ोल्डर को tmp/ में कॉपी करता है और वहां फाइलों को बदलता है।

npx shx cp -r ./src/ ./tmp/ && npx rexreplace "(^§s*?(?:import|export).*?from§s+?(['\"]).*?)§.ts§2" €1€2 './tmp/**/*.{ts,js,tsx,jsx}'

package.json में एक बिल्ड स्क्रिप्ट के हिस्से के रूप में ( yarn add --dev shx rexreplace करने के बाद) यह इस तरह दिख सकता है

"scripts":{
  "build": "yarn build-esm && yarn build-tsc",
  "buil-esm": "...Whatever you normally do...",
  "build-tsc": "shx mkdir -p tmp && shx cp -r ./src/* ./tmp && rexreplace \"(^§s*?(?:import|export).*?from§s+?(['\\\"]).*?)§.ts§2\" €1€2 './tmp/**/*.{ts,js,tsx,jsx}' && tsc src/index.ts && shx rm -r ./tmp"
}

मैं वर्तमान में जेस्ट को खुश रखने के लिए टाइपस्क्रिप्ट स्रोतों में आयात पथ से .js दूर रखता हूं।
फिर, मेरे पास .js जोड़ने के लिए एक पोस्ट प्रोसेसिंग चरण है।
स्रोत मानचित्र इस पद्धति के साथ समर्थित नहीं हैं।

tsc -b tsconfig-solution.json -w --listEmittedFiles \
  | node mk/build-post.js

बिल्ड-पोस्ट.जेएस पोस्ट प्रोसेसिंग स्क्रिप्ट निम्नलिखित कार्य करती है।

.js से import और सापेक्ष पथों के export में जोड़ें

उदाहरण के लिए,

export { X } from "./first";
import { Y } from "./second";

हो जाता है

export { X } from "./first.js";
import { Y } from "./second.js";

ध्यान दें कि मैं कहीं भी index.ts का उपयोग नहीं करता, बल्कि इसके बजाय डेनो सम्मेलन के बाद mod.ts का उपयोग करता हूं। इस प्रकार, मुझे /index.js जोड़ने के मामले पर विचार करने की आवश्यकता नहीं है।

CommonJS पैकेज के लिए import से require बदलें

मेरा कोड मॉड्यूल मोड में नोड ^12.17 और ^14.1 पर चलता है। मैं केवल ES मॉड्यूल प्रकाशित करता हूं।
हालाँकि, कई निर्भरताएँ अभी भी अपने "main" फ़ील्ड में CommonJS रखती हैं।
इस प्रकार, मुझे नोडजेएस बिल्टिन मॉड्यूल को छोड़कर, इन्हें कॉमनजेएस में बदलना चाहिए।

उदाहरण के लिए,

import { Server as WsServer } from "ws";

हो जाता है

import { createRequire } from "module";
const require = createRequire(import.meta.url);
const { __importDefault } = require("tslib");

const { Server: WsServer } = require("ws");

लेकिन फिर, वेबपैक इन require s से नाखुश है, इसलिए मुझे इसका उपयोग करना होगा:

/// #if false
import { createRequire } from "module";
const require = createRequire(import.meta.url);
const { __importDefault } = require("tslib");
/// #endif

/// #if false
const { Server: WsServer } = require("ws");
/*
/// #else
import { Server as WsServer } from "ws";
/// #endif
/// #if false
*/
/// #endif

वेबपैक में, मेरे प्रोजेक्ट को आयात करने वाले किसी भी पैकेज को ifdef-loader का उपयोग करना चाहिए, और फिर वेबपैक को मूल import लाइन दिखाई देगी।

हम भी इसकी चपेट में आ रहे हैं और मुझे समझ नहीं आ रहा है कि रिपोर्ट किए जाने के 3 साल बाद भी इसे कैसे ठीक नहीं किया गया।
हम वेबस्टॉर्म का उपयोग कर रहे हैं इसलिए VSCode विशिष्ट सेटिंग काम नहीं करेगी।
आउटपुट को ठीक करने के लिए एक अलग स्क्रिप्ट का उपयोग करना हास्यास्पद है।
यह तृतीय-पक्ष टूल का उपयोग किए बिना काम करना चाहिए।

+1

एएसपीनेट कोर 3.1 वेबसाइट का उपयोग करके यह मेरा कामकाज है (शायद निचले संस्करणों पर काम करता है)
स्टार्टअप.सीएस में:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseRouting();

            var rewriteOptions = new RewriteOptions();
            rewriteOptions.AddRewrite(@"^js/(.+)", "js/$1.js", skipRemainingRules: true);

            app.UseRewriter(rewriteOptions);

            app.UseStaticFiles();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapGet("/", async context =>
                {
                    await context.Response.WriteAsync("Hello World!");
                });
            });
        }

पुनर्लेखन मिडलवेयर फ़ोल्डर /js को लक्षित करने वाले किसी भी अनुरोध में एक्सटेंशन ".js" जोड़ देगा।
चेतावनी: मिडलवेयर का क्रम यहां मायने रखता है, UseStaticFiles को UserRewriter के बाद रखा जाना चाहिए या यह काम नहीं करेगा।

यहां सभी के रूप में, मैं लीक से हटकर समाधान पसंद करूंगा लेकिन तब तक...

शायद यह TS में नया मॉड्यूल रिज़ॉल्यूशन जोड़ने का समय है? Node.js के पास अब मूल ESM समर्थन है, लेकिन सापेक्ष पथों में स्पष्ट एक्सटेंशन के बिना यह --experimental-specifier-resolution=node ध्वज का उपयोग करने के लिए मजबूर करता है, जो थोड़े कष्टप्रद है। डेनो और ब्राउजर भी हैं। आदर्श रूप में ऐसा कुछ होना चाहिए:
tsconfig.json:

{
    "compilerOptions": {
        "moduleResolution": "explicit",
        "strict": true
    }
}

फिर टाइपप्रति:

import foo from './foo.ts'; // no ts(2691) here

जावास्क्रिप्ट के लिए संकलित करता है:

import foo from './foo.js';

मैंने node/file-extension-in-import नियम को eslint-plugin-node #$ में लाइनिंग कॉन्फिगरेशन के लिए मैन्युअल रूप से इम्पोर्ट स्टेटमेंट में एक्सटेंशन जोड़ने के विचार के साथ सेट किया (क्योंकि यह उस तरह से बेहतर है) और टाइपस्क्रिप्ट में "moduleResolution": "node" config है और मैं केवल ts(2691) देख सकता हूं।

उम्मीद है कि @ evg656e ने जो कहा वह लागू करने लायक हो सकता है।

मुझे विश्वास नहीं हो रहा है कि यह अभी भी एक मुद्दा है।

जब आप उपयोग करते हैं
"baseUrl": ".", "paths": { "/*": ["./*"] },

आप इस तरह एक निरपेक्ष मॉड्यूल आयात कर सकते हैं:
`आयात ws "/ हे/कनेक्शन" से;

लेकिन ".js" एक्सटेंशन जोड़ते समय, अचानक कंपाइलर को कनेक्शन.ts घोषणा नहीं मिलती है और कहता है:

Could not find a declaration file for module '/hey/connection'. '/home/tobi/Documents/JITcom/Code/Libs/Test_Browser/hey/connection.js' implicitly has an 'any' type.

एक सापेक्ष पथ का उपयोग करके यह सब ठीक काम करता है।

कृपया इसे ठीक करें

मैं इसके लिए एक फिक्स भी चाहता हूं।

धन्यवाद।

यह हास्यास्पद है कि यह अभी भी एक मुद्दा है! :00

मैंने आखिरकार टाइपस्क्रिप्ट पर स्विच करने का फैसला किया है और यह उन पहले मुद्दों में से एक था जिसमें मैं भाग गया था। यह नोड के मूल कार्यान्वयन में मॉड्यूल रिज़ॉल्यूशन को तोड़ता है, और मैं केवल esm पैकेज का उपयोग करके इसे प्राप्त करने में सक्षम हूं जो एक्सटेंशन के बिना नाम स्वीकार करने में अधिक लचीला लगता है, या (अजीब तरह से) आयात पथ में .js एक्सटेंशन का उपयोग करके मेरी .ts फ़ाइलों के अंदर तब भी जब आयात .ts या .tsx फ़ाइल की बात कर रहा हो। मुझे यकीन नहीं है कि टाइपस्क्रिप्ट कंपाइलर इसे क्यों स्वीकार करता है, लेकिन कम से कम बिल्ड आउटपुट में .js एक्सटेंशन शामिल है। हालांकि बहुत हैकी समाधान।

मैं इन दिनों क्लाइंटसाइड पर टाइपस्क्रिप्ट का अधिक उपयोग नहीं कर रहा हूं, मेरी कोड गुणवत्ता को बहुत अधिक प्रभावित नहीं किया और चीजों को आसान बना दिया। संभवतः जावास्क्रिप्ट में एक बिंदु के वैकल्पिक प्रकार होंगे और यह समस्या अब कोई मायने नहीं रखेगी।

मैं जेस्ट और वेबपैक को खुश करने के लिए आयात लाइनों पर एक्सटेंशन को छोड़ देता हूं।
जब मैं संकलित करता हूं, तो मैं tsc --listEmittedFiles आह्वान करता हूं और आउटपुट को पोस्ट-प्रोसेसिंग स्क्रिप्ट में पाइप करता हूं। नोड (मॉड्यूल मोड में) को खुश करने के लिए वह स्क्रिप्ट .js एक्सटेंशन जोड़ती है।
https://github.com/yoursunny/NDNts/blob/fa6b2eb68a9f32a6a2e24e5475275f803236b8f8/mk/build-post.js

@kj

(अजीब तरह से) मेरी .ts फ़ाइलों के अंदर आयात पथ में .js एक्सटेंशन का उपयोग करना, तब भी जब आयात .ts या .tsx फ़ाइल का संदर्भ दे रहा हो। मुझे यकीन नहीं है कि टाइपस्क्रिप्ट कंपाइलर इसे क्यों स्वीकार करता है, लेकिन कम से कम बिल्ड आउटपुट में .js एक्सटेंशन शामिल है। हालांकि बहुत हैकी समाधान।

यह अजीब नहीं है और निश्चित रूप से हैकी नहीं है, और ब्राउज़र और नोड मूल मॉड्यूल रिज़ॉल्यूशन के साथ पूरी तरह से काम करता है।

जिस संसाधन को आप _is_ .js फ़ाइल आयात कर रहे हैं। प्रकार या तो .ts फ़ाइल में या .d.ts फ़ाइल में हो सकता है। एक .d.ts फ़ाइल को .js मॉड्यूल का सहोदर होने की भी आवश्यकता नहीं है, और .d.ts फ़ाइलों और .js फ़ाइलों के बीच 1-से-1 संबंध होने की आवश्यकता नहीं है।

.js मॉड्यूल को आयात करना सबसे विश्वसनीय और स्थिर विकल्प है जिसे tsc चुन सकता था। अन्यथा ऐसे मामले होंगे जहां आप प्रकार आयात करते हैं और tsc उन्हें वास्तविक मॉड्यूल पथ में फिर से लिखने का सही तरीका नहीं जानता है।

@justinfagnani आह, मुझे लगता है कि यह समझ में आता है। मेरा मतलब यह नहीं था कि टाइपस्क्रिप्ट जो कुछ भी कर रहा था वह हैकी था (मैं इस तरह का दावा करने की स्थिति में नहीं हूं), बस मुझे लगा कि मैं जो कर रहा था वह सामान्य नहीं हो सकता है। मुझे लगता है कि मैं इसके बारे में गलत तरीके से सोच रहा था, हालांकि। यह टाइपस्क्रिप्ट नहीं है जो मॉड्यूल को आयात करता है, यह जो कुछ भी बिल्ड आउटपुट का मूल्यांकन करता है (या क्या मैं गलत समझ रहा हूं)? उस स्थिति में मैं देख सकता हूं कि यह इस तरह क्यों काम करेगा।

जिस संसाधन को आप _is_ .js फ़ाइल आयात कर रहे हैं

आप यहाँ निर्मित मॉड्यूल की बात कर रहे हैं, है ना? स्रोत निर्देशिका में .js फ़ाइल नहीं है, लेकिन .ts मॉड्यूल का निर्मित संस्करण है?

क्या ऐसा नहीं हो सकता है कि यदि आप मॉड्यूल पथ में एक्सटेंशन .ts या .tsx को स्पष्ट रूप से निर्दिष्ट करते हैं, तो आउटपुट .js को प्रतिस्थापित करेगा?

मुझे लगता है कि @kj पर क्या हो रहा है इसकी गलतफहमी हो सकती है। जब आप अपना कोड संकलित किए बिना .ts एक्सटेंशन निर्दिष्ट करते हैं, तो यह ts फ़ाइल को संदर्भित करता है। लेकिन जब आप tsc का उपयोग करके संकलन करते हैं तो यह ts फ़ाइल की सामग्री को एक js फ़ाइल में बदल देता है जो उस वातावरण में निष्पादन योग्य होता है जिसमें आप (नोड या ब्राउज़र) होते हैं।

मैं समझता हूं कि @ mkay581 , लेकिन कहें कि मेरे पास यह पंक्ति foo.ts फ़ाइल में है:

import { Component } from './Component.js';

मैं जिस 'Component.js' का जिक्र कर रहा हूं वह वास्तव में फाइल सिस्टम पर 'Component.tsx' है (कोई .js फाइल नहीं है, जब तक कि टाइपस्क्रिप्ट इसे फाइल के अंतिम ट्रांसपाइल संस्करण के संदर्भ में नहीं समझ रहा है?), फिर भी टाइपस्क्रिप्ट इसे ठीक से स्वीकार करता है और फिर वही आयात लाइन आउटपुट में मौजूद होती है (.js एक्सटेंशन के साथ जो तब नोड या ब्राउज़र के साथ काम करता है)।

पारंपरिक टाइपस्क्रिप्ट तरीका (AFAIK) विस्तार के बिना उस आयात लाइन को निर्दिष्ट करना होगा, जैसे:

import { Component } from './Component';

यह स्पष्ट रूप से ठीक भी संकलित करता है, सिवाय इसके कि transpiled .js फ़ाइल में .js एक्सटेंशन './Component' पर शामिल नहीं है, जो कुछ वातावरणों के लिए आवश्यक है (और संभवतः यह कल्पना की तरह लगता है, हालांकि मेरे पास है) टी इसे सुनिश्चित करने के लिए पढ़ें)।

दूसरी तरफ, अगर मैं स्रोत फ़ाइल के वास्तविक फ़ाइल नाम के साथ लाइन निर्दिष्ट करता हूं:

import { Component } from './Component.tsx';

तब टाइपस्क्रिप्ट पथ को नहीं पहचानता है और सुझाव देता है कि मुझे फ़ाइल एक्सटेंशन के बिना आयात लाइन का प्रयास करना चाहिए (यदि मुझे याद है, मैं अभी अपने कंप्यूटर पर नहीं हूं)।

तो, पहला उदाहरण मेरे लिए थोड़ा अजीब लगता है, क्योंकि मैं टाइपस्क्रिप्ट लिख रहा हूं, मैं .ts या .tsx एक्सटेंशन के साथ आयात करने में सक्षम होने की उम्मीद करता हूं, फिर भी यह केवल बिना किसी एक्सटेंशन के पथ को स्वीकार करता है (जो ऐसा लगता है ES मॉड्यूल सिस्टम के अन्य कार्यान्वयन के साथ) या .js एक्सटेंशन के साथ जो केवल आउटपुट फ़ाइल को संदर्भित कर सकता है क्योंकि मेरे पास ऐसी कोई स्रोत फ़ाइल नहीं है।

@justinfagnani

जिस संसाधन को आप _is_ .js फ़ाइल आयात कर रहे हैं।

मुझे नहीं पता कि tsc कैसे काम करता है लेकिन यह मुझे सही नहीं लगता। जब आप अपना कोड लिखते हैं, तब तक कोई .js फ़ाइल नहीं होती है। इसे बनाना कंपाइलर का काम है।

TS JS के शीर्ष पर अमूर्तता की एक परत के रूप में कार्य करता है और .js फ़ाइलें संकलन चरण का आउटपुट हैं। उस विशिष्ट विस्तार के साथ वहां होने पर गिनना अमूर्तता, आईएमओ को तोड़ना प्रतीत होता है।

दूसरे शब्दों में कहें तो, जब आप C या C++ का उपयोग कर रहे होते हैं तो आप अपने कोड में #include .o फ़ाइलें नहीं रखते हैं, आप .h या अधिक से अधिक .c या .cpp ।

मैं टाइपस्क्रिप्ट में इस व्यवहार के लिए एक उचित स्पष्टीकरण स्वीकार करने को तैयार हूं, लेकिन जब तक मुझे कुछ याद नहीं आ रहा है, यह ऐसा प्रतीत नहीं होता है।

@kj

यह अजीब नहीं है और निश्चित रूप से हैकी नहीं है

कठिन असहमत। मेरे लिए यह अजीब और हैकी की परिभाषा है। आप यहाँ जो कर रहे हैं वह एक काल्पनिक फ़ाइल का संदर्भ दे रहा है। एक फ़ाइल जिसके अस्तित्व की गारंटी नहीं है। (उदाहरण के लिए कोड को बंडल करते समय, असेंबलीस्क्रिप्ट या डीनो का उपयोग करके) आप आउटपुट स्वरूप मान रहे हैं। लेकिन अज्ञेय कोड लिखते समय (उदाहरण के लिए तृतीय-पक्ष मॉड्यूल), यह मान लेना एक _खतरनाक_ बात है।

@borfast @frzi हां, मूल रूप से मुझे इसके बारे में कैसा लगा, और मुझे यह देखकर खुशी हुई कि मैं अकेला नहीं हूं जो इसके साथ सहज महसूस नहीं करता है। मैं कोशिश कर रहा हूं कि टाइपस्क्रिप्ट के लिए बहुत सी धारणाएं इतनी नई न हों!

@frzi

आप यहां जो कर रहे हैं वह एक काल्पनिक फ़ाइल का संदर्भ दे रहा है। एक फ़ाइल जिसके अस्तित्व की गारंटी नहीं है

काल्पनिक नहीं, टीएससी जानता है कि यह इसे उत्पन्न करेगा। tsc का उपयोग करते समय इसके अस्तित्व की गारंटी है।

इसे देखने का दूसरा तरीका यह है कि यदि आप .ts फ़ाइल आयात करते हैं तो आप एक ऐसी फ़ाइल आयात कर रहे हैं जो संकलन के बाद वहां नहीं होगी।

कोड बंडल करते समय

बंडलर tsc . के पीछे चलते हैं

@kj ने .tsx फ़ाइलों का उल्लेख किया है, और वे मेरी बात को और भी अधिक घर ले जाते हैं। .tsx केवल उस मॉड्यूल के कंपाइलर को संकेत देने के लिए मौजूद है, _locally_, कि मॉड्यूल में JSX है। मॉड्यूल के आयातकों को यह जानने की कोई आवश्यकता नहीं है कि फ़ाइल में JSX था, और वे संकलन के बाद नहीं बता सकते। फ़ाइलें .tsx, .ts, और .js/.d.ts जोड़े के बीच निर्बाध रूप से पोर्ट की जा सकती हैं।

मान लें कि आप एक .ts फ़ाइल आयात कर रहे हैं:

import {Component} from './component.ts';

और फिर आप घटक के लिए JSX का उपयोग करना चाहते हैं, इसलिए आप इसका नाम बदलकर घटक.tsx कर दें। क्या सभी आयात विफल हो जाने चाहिए? मान लें कि आप .ts से .js/.d.ts में माइग्रेट करते हैं, क्या आयात फिर से विफल हो जाना चाहिए?

@ बोरफास्ट

TS JS के शीर्ष पर अमूर्तता की एक परत के रूप में कार्य करता है और .js फ़ाइलें संकलन चरण का आउटपुट हैं। उस विशिष्ट विस्तार के साथ वहां होने पर गिनना अमूर्तता, आईएमओ को तोड़ना प्रतीत होता है।

अमूर्त उतना पूर्ण नहीं है जितना आप यहाँ बता रहे हैं। आप अपने TS प्रोजेक्ट के अंदर या बाहर से .js फ़ाइलें आयात कर सकते हैं। आप .d.ts फ़ाइल के साथ .js फ़ाइल में प्रकार जोड़ सकते हैं जो आपके प्रोजेक्ट में कहीं भी रहती है। .js फ़ाइलें संकलन के बाद वास्तविक होती हैं। बाकी सब कुछ सिर्फ संकलक की सहायता करता है।

@justinfagnani आप जो कह रहे हैं उससे मैं थोड़ा खो रहा हूं, लेकिन टाइपस्क्रिप्ट सिर्फ यह क्यों नहीं मान सकता कि यदि आप इसे .ts या .tsx के साथ एक आयात पथ देते हैं कि यह उस मॉड्यूल के लिए एक .js फ़ाइल उत्पन्न करेगा और इसलिए आउटपुट में बाद वाले एक्सटेंशन को स्थानापन्न करना चाहिए?

@justinfagnani

काल्पनिक नहीं, tsc _knows_ यह इसे उत्पन्न करेगा। tsc का उपयोग करते समय इसके अस्तित्व की गारंटी है।

लेकिन यहां एक समरूपता निहित है जिसे आप स्वीकार नहीं कर रहे हैं।

आप जिस "गारंटी" का उल्लेख करते हैं, वह दोनों तरह से है। यदि, जैसा कि आप कहते हैं, "tsc _knows_ यह [js फ़ाइलें] उत्पन्न करेगा", तो यह पूछने के लिए एक समान रूप से मान्य प्रश्न है: "ठीक है, तो tsc इस गारंटी पर कार्य क्यों नहीं कर रहा है और .js एक्सटेंशन लागू करें जो इसे _knows_ है संकलित जेएस से गायब है?"

इस तथ्य की व्याख्या करते हुए कि "tsc js फ़ाइलों की गारंटी देता है" दोनों तरह से जाता है।

तो मैं सहमत हूं, @justinfagnani , आपकी व्याख्या _is_ मान्य है, एक निश्चित दृष्टिकोण से। लेकिन इसके विपरीत व्याख्या यह है कि "tsc को इसलिए _अपने ज्ञान पर कार्य करना चाहिए_ और डेवलपर के लिए इस प्रक्रिया को निष्पादित करना चाहिए"। और जो बात मुझे शुरू से ही इस पूरी बहस के बारे में परेशान करती है, वह यह है कि कैसे _नकारात्मक रूप से_ इस व्याख्या को प्राप्त किया जाता है, लगभग उपहास के बिंदु तक। यह अनुचित है।

अंत में, यह बहस _एक सौंदर्य निर्णय के बारे में है, तार्किक नहीं_। और मेरी आशा है कि आवाज का एक अनुकूल और मिलनसार स्वर - जैसा कि सौंदर्यवादी _opinion_ (तार्किक कटौती नहीं) के लिए उचित है - इस मुद्दे पर इसके विरोधियों द्वारा सहन किया जाता है।

संक्षेप में, कृपया स्वीकार करें कि ओपी का प्रश्न पूरी तरह से मान्य व्याख्या है - शायद आपके साथ भी। कठोर बहस की जरूरत नहीं है।

शुक्रिया

@justinfagnani

इसे देखने का दूसरा तरीका यह है कि यदि आप .ts फ़ाइल आयात करते हैं तो आप एक ऐसी फ़ाइल आयात कर रहे हैं जो संकलन के बाद वहां नहीं होगी।

बेशक यह नहीं होगा, जैसे .h फ़ाइल सी प्रोग्राम के निष्पादन योग्य के साथ वितरित नहीं की जाती है। ठीक यही बात है: आप एक कंपाइलर को स्रोत फ़ाइलों को शामिल करने के लिए कहते हैं, संकलित फ़ाइलें नहीं।

ठीक है, मैं इस बातचीत को और अनदेखा करने के लिए बहुत अधिक स्पैम हो गया हूं।
import स्टेटमेंट टाइपस्क्रिप्ट का हिस्सा नहीं है, यह जावास्क्रिप्ट वातावरण का हिस्सा है जिसने इसे निष्पादित किया है। अब, यहां मुख्य शब्द जावास्क्रिप्ट वातावरण है, क्योंकि यह वही है जो पथों को हल करता है। मुझे एक एकल ऐप दिखाएं जो रनटाइम में .ts फ़ाइलों को आयात और निष्पादित करता है (निश्चित रूप से, कुछ हो सकते हैं, लेकिन वे वही हैं जिन्हें मैं हैकी कहूंगा)।
टाइपस्क्रिप्ट .js एक्सटेंशन जोड़ने की अनुमति देता है क्योंकि यह मूल जावास्क्रिप्ट को इसकी स्रोत फ़ाइलों के अंदर अनुमति देता है। नोड.जेएस के ब्राउज़र में से कोई भी .ts फ़ाइल को निष्पादित नहीं करेगा, यहां तक ​​कि ts-node ट्रांसपाइल्स .ts फ़ाइलों को फ्लाई पर, बस परिणाम को हार्ड ड्राइव पर लिखने के बजाय मेमोरी में रखता है (बिल्कुल हैकी नहीं) ?)

अब, उचित tsc फिक्स होगा:

• हमारे पास .ts फ़ाइल है
• हम इसे किसी अन्य फ़ाइल में संदर्भित करते हैं
• tsc उस .ts फ़ाइल को .js फ़ाइल में ट्रांसपाइल करता है
• tsc फिर .ts फ़ाइल के सभी प्रत्यक्ष संदर्भों को .ts .js के साथ फिर से लिखता है (यह ठीक से जानता है कि यह कैसे ट्रांसपाइल किया गया है इसलिए इसे सही तरीके से अपडेट कर सकते हैं)

समस्या: "आधुनिक वेब देव" वास्तविक वेब देव नहीं है और आयात करने के नोड.जेएस तरीके का उपयोग करता है, एक्सटेंशन (और संपूर्ण फ़ाइल पथ) को छोड़ देता है। tsc अब नहीं जानता कि आउटपुट क्या होने वाला है, coz my-awesome-module/test आयात करना कुछ भी हो सकता है, test.js में node-modules/my-awesome-module फ़ाइल से शुरू होकर index.js फ़ाइल के माध्यम से test फ़ोल्डर के अंदर node-modules/my-awesome-module , गैर-जेएस फाइलों जैसे ./local-mocks/my-awesome-module/mock.json के साथ कुछ स्थानीय पुनर्लेखन पर समाप्त होता है।

यह वह जगह है जहां समस्या उत्पन्न होती है: एक टीएससी कैसे जान सकता है कि आपके विशेष प्रोजेक्ट के लिए फंकी वेबपैक/रोलअप/सुपर-भयानक-नया-और-चमकदार-बंडलर कॉन्फ़िगरेशन क्या है?

दोबारा: मैं आयात पथ को फिर से लिखने के लिए टीएससी के लिए हूं, लेकिन यह केवल साधारण परियोजनाओं के लिए काम करेगा, और इसे केवल साधारण परियोजनाओं के लिए काम करना होगा (जो आजकल अल्पसंख्यक है क्योंकि साधारण प्रस्तुति पृष्ठ भी अतिसंवेदनशील वेबपैक कॉन्फ़िगरेशन के साथ प्रतिक्रिया का उपयोग करते हैं) लायक नहीं है समय व्यतीत करना, यदि यह एक साधारण कस्टम लिखित लिपि के साथ किया जा सकता है।

दोबारा: मैं आयात पथ को फिर से लिखने के लिए टीएससी के लिए हूं, लेकिन यह केवल साधारण परियोजनाओं के लिए काम करेगा, और इसे केवल साधारण परियोजनाओं के लिए काम करना होगा (जो आजकल अल्पसंख्यक है क्योंकि साधारण प्रस्तुति पृष्ठ भी अतिसंवेदनशील वेबपैक कॉन्फ़िगरेशन के साथ प्रतिक्रिया का उपयोग करते हैं) लायक नहीं है समय व्यतीत करना, यदि यह एक साधारण कस्टम लिखित लिपि के साथ किया जा सकता है।

वेबपैक के बिना एक साधारण परियोजना में आप इसे कैसे करेंगे, बस टीएससी के साथ मेरा मतलब है?

मैं सभी की टिप्पणियों को पढ़ रहा हूं और यह यहां टाइपप्रति उपयोग की अपेक्षाओं की मूलभूत असहमति प्रतीत होता है।

जब .ts स्रोत फ़ाइलें .js फ़ाइलों का संदर्भ दे रही हों, तो समस्या पहले ही शुरू हो चुकी है।

टाइपस्क्रिप्ट को ~run~ कंपाइल सोर्स .ts फाइल्स के लिए बनाया गया था - न कि .js फाइल्स के लिए। यदि कोई देव अपने प्रोजेक्ट पर टाइपस्क्रिप्ट का उपयोग करना चाहता है, तो उन्हें अपने _entire_ प्रोजेक्ट को टाइपस्क्रिप्ट में बदलना चाहिए और अनाथ .js फ़ाइलों को नहीं छोड़ना चाहिए और उन्हें संदर्भित करने का प्रयास करना चाहिए। और यदि आपके पास जेएस फाइलों में सामग्री को टाइपस्क्रिप्ट सिंटैक्स में बदलने का समय नहीं है, तो बस जेएस फाइलों को टीएस फाइलों में बदलें (या टीएस के पथ मैपिंग का उपयोग .js फाइलों में आयात को मैप करने के लिए करें)। समस्या हल हो गई। :man_shrugging:

संपादित करें: "संकलन" को "संकलित" करने के लिए सही किया गया, जो मेरा मतलब था लेकिन मैं देख सकता हूं कि इसका अलग-अलग व्याख्या कैसे किया जा सकता है।

@ mkay581 टाइपस्क्रिप्ट का उद्देश्य कभी भी कुछ भी चलाने का इरादा नहीं था, केवल JS फ़ाइलों को आउटपुट करने के लिए।

@valeriob सरल परियोजना में शायद कुछ फाइलें अधिक से अधिक होंगी, जिन्हें बंडल करने की आवश्यकता नहीं है। ब्राउज़रों में आजकल आयात अंतर्निहित हैं, उसके आसपास जाने की कोई आवश्यकता नहीं है। फिर यह ब्राउज़र में नेविगेशन घटनाओं को सुनने जितना आसान होगा, फिर प्रत्येक घटना को मिलान मार्ग पर मैप करें, प्रत्येक मार्ग fetch के साथ डेटा आयात कर सकता है और एक बार वापस आने के बाद गैर-संकलित टेम्पलेटिंग इंजन के साथ प्रस्तुत किया जा सकता है (लिट- html, HyperHTML, या पुराने वाले जैसे मूंछें, हैंडलबार, पग आदि)। हो गया, फैंसी वेबपैक, फ्रेमवर्क या किसी भी उपयोगिता पुस्तकालयों की आवश्यकता नहीं है, यहां तक ​​​​कि श्रोताओं, रेगेक्सपी, फ़ेच, वादे और एक साधारण जेएस टेम्प्लेटिंग इंजन भी।

धन्यवाद @Draccoz , क्या आप मुझे बता सकते हैं कि इस सरल परिदृश्य को कैसे काम करना है? https://github.com/valeriob/Typescript_Non_SPA
यह एक साधारण .ts फ़ाइल है जो JS लाइब्रेरी (उदाहरण के रूप में rxjs) को संदर्भित करती है और मैं इसे एक html पृष्ठ में मॉड्यूल के रूप में उपभोग करना चाहता हूँ।

@valeriob यह उतना छोटा नहीं है जितना होना चाहिए। अधिकांश तृतीय पक्ष पुस्तकालय, भले ही वे घोषणा करते हैं कि वे ES मॉड्यूल संगत हैं, वे ब्राउज़र की दुनिया में नहीं हैं।
आरएक्सजेएस एक ऐसी चीज है जिसे मूल प्रवाह में लाने में मेरी दिलचस्पी थी, लेकिन वे इस टिकट के हल होने की प्रतीक्षा करते हैं इससे पहले कि वे इसे स्वयं लागू करने का निर्णय लें (मजाकिया ...)।
आर्किटेक्चर में मैं डिजाइन कर रहा था, मैंने शुरू में सभी आयातों को ठीक करने के लिए sed का उपयोग किया था, लेकिन फिर पथ पुनर्लेखन के साथ एक साधारण देव सर्वर का उपयोग करने के लिए अपना विचार बदल दिया। मेरी अवधारणा है कि आरएक्सजेएस, टाइपस्क्रिप्ट और लिट-एचटीएमएल (4 फ़ोल्डरों के साथ नोड_मॉड्यूल और अल्ट्रा फास्ट सीआई परीक्षण/बिल्ड) के अलावा मेरे ऐप्स में कोई बाहरी निर्भरता नहीं है। यदि TS पथों को फिर से लिखता है, तो यह मेरे सर्वर की आवश्यकता को समाप्त कर देगा, हालाँकि यह वैसे भी कोड की लगभग 90 पंक्तियाँ हैं। यह खुला स्रोत है, अगर कोई लिंक चाहता है तो बस मेरी प्रोफ़ाइल में संगठनों से पूछें या जांचें।

साधारण पृष्ठों के रूप में, मैं उन लोगों को संदर्भित कर रहा था जिन्हें वास्तव में किसी पुस्तकालय की आवश्यकता नहीं है, जैसे यूआरएल मारना -> डेटा प्राप्त करना -> इसे प्रदर्शित करना -> दोहराना।

जेएस में किसी भी पुस्तकालय का उपयोग करने की आवश्यकता नहीं है, शुद्ध कल्पना है क्योंकि जेएस के पास कोई आधार पुस्तकालय नहीं है।

साधारण परिदृश्य वह है जिसे मैंने लिंक किया है, और यह काम नहीं कर रहा है। साथ ही यह पीपीएल के लिए सबसे आम परिदृश्य है जो पागल वेबपैक/संकलन दुनिया में गोता नहीं लगाना चाहता है जो बिना किसी वास्तविक लाभ के चीजों को जटिल बनाता है, अपने विकल्पों को बहुत सीमित करता है, देवों को आपके ऐप को लिखने से अधिक टूल से लड़ने के लिए प्रेरित करता है, और आपके देव को धीमा कर देता है कुंडली।

कई मानसिक जिम्नास्टिक इस बात से इनकार करते हैं कि यह समस्या मौजूद है और यह कई डेवलपर्स की उत्पादकता के लिए एक महत्वपूर्ण चिंता का विषय है।

यह समझाते हुए कि यह _कोई मुद्दा नहीं होना चाहिए__समस्या का समाधान नहीं_है। सॉफ़्टवेयर को उपयोगकर्ताओं के मानसिक मॉडल के अनुरूप होना चाहिए, न कि अपने स्वयं के कार्यान्वयन मॉडल को उपयोगकर्ताओं पर थोपना चाहिए। (यूएक्स सामान)

यदि उपयोगकर्ता @borfast के अनुसार tsc को C- जैसे संकलक के रूप में अवधारणा कर रहे हैं, तो वह विशेषाधिकार प्राप्त मानसिक विधा है जिसे tsc के कार्यान्वयन विवरण के बावजूद समायोजित करने की आवश्यकता है।

ओपी के प्रश्न में 200+ अंगूठे हैं, रेपो पर अन्य सभी मुद्दों से अधिक।

यह मुद्दा एक सामुदायिक वोट का हकदार है। कृपया मतदान शुरू करने पर विचार करें।

यदि अधिकांश उपयोगकर्ता चाहते हैं कि tsc उनके आयात को फिर से लिखे, तो यह सही उत्तर है। कम से कम चीजों को देखने का यही UX तरीका है।

यह उससे भी आसान है, यदि टाइपस्क्रिप्ट एक भाषा के रूप में यह जावास्क्रिप्ट का सुपरसेट है, तो tsc का आउटपुट (यहां तक ​​कि एक आउटपुट फ़ाइल स्विच भी नहीं) जावास्क्रिप्ट द्वारा ही पचने योग्य होना चाहिए।

@weoreference यदि आप स्पष्ट तरीके से परिभाषित करते हैं (कोड नहीं लिखें, बस डिज़ाइन करें) तो यह वास्तव में कैसे पथों को फिर से लिखना चाहिए, कई वातावरणों (नोड.जेएस, ब्राउज़र), कई बंडलर कॉन्फ़िगरेशन संभावनाओं (सभी वर्तमान, नियोजित और संभावित भविष्य की विशेषताओं की जांच करना) वेबपैक, रोलअप और पार्सल और कोई अन्य बंडलर) तो निश्चित रूप से, तो मेरा मानना ​​​​है कि टाइपस्क्रिप्ट टीम आपके पक्ष में होगी।

यदि आप ऐसा करने के लिए तैयार नहीं हैं या सोचते हैं कि यह बहुत कठिन है, तो उन्हें ऐसी सुविधा बनाने के लिए कहना बंद करें जिसका वास्तव में कोई भी वर्णन नहीं कर सकता है, यह "मुझे परवाह नहीं है कि कैसे, लेकिन इस गाय को उड़ने दें" ...

@Draccoz , आप चाहते हैं कि आपकी कार गियर शिफ्ट करे ताकि आप इसे 10 किमी/घंटा से तेज ड्राइव कर सकें, लेकिन मुझे यकीन है कि आपको निर्माता द्वारा कभी यह जानने के लिए नहीं कहा गया था कि गियर ट्रेन कैसे काम करती है, अकेले डिजाइन करें।

जहां तक ​​बंडलर और क्या नहीं है, के मुद्दे के लिए यह एक अवरोधक क्यों है?

देखिए, मैं सिर्फ ES मॉड्यूल का उपयोग करना चाहता हूं, मैं सभी बेबेल और वेबपैक पागलपन से निपटना नहीं चाहता। यह एक वैकल्पिक कंपाइलर विकल्प क्यों नहीं हो सकता है जो फ़ाइल एक्सटेंशन को .js में बदल देता है? यदि यह व्यवहार उपयोगकर्ता द्वारा सेट किए गए अन्य कॉन्फ़िगरेशन विकल्पों के साथ विरोध करता है, तो इसे स्वचालित रूप से अक्षम कर दिया जाना चाहिए, या एक चेतावनी/त्रुटि दिखाई जानी चाहिए और जब tsc निष्पादित किया जाता है तो संकलन बंद हो जाता है, ताकि उपयोगकर्ता को पता चले कि उन्हें कॉन्फ़िगरेशन बदलने की आवश्यकता है।

मैं वास्तव में नहीं देखता कि यह असंभव क्यों है।

@Draccoz हैलो :) ठीक है, जैसा कि मैंने इसे देखा, आप दो चीजें पूछ रहे हैं:

1. इसे कैसे लागू किया जा सकता है

2. मैं, डेवलपर, tsc को कैसे संकेत दे सकता हूं कि मैं अपने विशेष परिवेश के लिए आयातों का एक निश्चित तरीके से नाम बदलना चाहता हूं

यहाँ मेरे विचार हैं।

1. कृपया @borfast का उत्तर देखें; यह एक "उच्च-आदेश" उत्तर है, लेकिन संक्षिप्त :)

2. हो सकता है कि मैं tsc/tsconfig, जैसे "renameImports":true, या कोई अन्य सिग्नल जो tsc द्वारा उठाया जाता है, को फ़्लैग पास कर सकता हूँ। यदि अधिक सटीकता की आवश्यकता है, तो शायद ध्वज बूलियन नहीं होना चाहिए बल्कि एक स्ट्रिंग लेना चाहिए, शायद ऐसा कुछ:

मानक आयात एक्सटेंशन: 'जेएस'

इसलिए फ़ाइल एक्सटेंशन के बिना सभी आयात डिफ़ॉल्ट रूप से .js

निष्कर्ष:
यह कार्यक्षमता केवल लागू करना कठिन लगता है क्योंकि आप मानते हैं कि Q2 (आयात नाम बदलने की योजना) को Q1 (यानी tsc द्वारा) पहले से ही जाना जाना चाहिए। लेकिन वास्तव में, नहीं। मैं, मानव विकासकर्ता, आसानी से इस "विश्व ज्ञान" की आपूर्ति tsc को कर सकता है, बिना यह जाने कि वेबपैक/ब्राउज़र/आदि कैसे काम करता है। यह सब एक साधारण झंडे के साथ।

@borfast ट्रांसमिशन किसी उपयोगकर्ता द्वारा नहीं पूछा गया था, यह एक निर्माता द्वारा एक कार के साथ प्रदान किया गया था, उपयोगकर्ता बस सहमत था कि यह एक नई सुविधा है और इसका उपयोग करना शुरू कर दिया - क्षमा करें, यह उचित तर्क नहीं है। आपके उपयोगकर्ता-कार निर्माता उदाहरण की तुलना में यह अधिक है "मैं चाहता हूं कि मेरी कार 100k मील की दूरी के साथ एक पूर्ण इलेक्ट्रिक कार हो और एक जेट की शीर्ष गति तक पहुंचने की गति हो। मुझे परवाह नहीं है कि इसे कैसे प्राप्त किया जाए, मुझे यह चाहिए और बस इतना ही - अवधि।
@ मेरे सवालों में थोड़ी गलतफहमी। मैं इस बारे में पूछ रहा था: टीएससी को यह कैसे समझा जाए कि पथ किस ओर इशारा करता है? क्या यह सीधे जेएस फाइल है? या यह index.ts के अंदर एक फ़ोल्डर है? या यह package.json वाला एक मॉड्यूल है जिसमें main फ़ील्ड है? या एसनेक्स्ट फील्ड? या कोई अन्य जो गैर-मानक है? या यह एक पथ है जिसे वेबपैक द्वारा फिर से लिखा गया है? या रोलअप? यदि हां, तो कॉन्फ़िगरेशन कहां है? क्या यह शायद एक और बंडलर है? कुछ कम ज्ञात? और अन्य उपयोग के मामले क्या हैं जिनके बारे में मैंने उपरोक्त वाक्य में नहीं सोचा था?

हो सकता है कि मैं tsc/tsconfig, जैसे "renameImports":true, या कोई अन्य सिग्नल जो tsc द्वारा उठाया जाता है, को फ़्लैग पास कर सकता हूँ।

@weoreference क्या आप पहले से ही पथ मानचित्रण के साथ ऐसा नहीं कर सकते हैं? TSconfig फ़ाइल में paths विकल्प हमें JS फ़ाइलों के आयात पथ को मैप करने का नियंत्रण देता है। क्षमा करें यदि मैं गलत व्याख्या कर रहा हूँ।

@Draccoz आपके उत्तर के लिए धन्यवाद, कृपया मुझे स्पष्ट करने दें

और अन्य उपयोग के मामले क्या हैं जिनके बारे में मैंने उपरोक्त वाक्य में नहीं सोचा था?

अरे हाँ, टीएससी के लिए इन सभी पर्यावरण/बिल्ड टूल संयोजनों के बारे में ज्ञान होना बहुत मुश्किल होगा।

लेकिन tsc में एक साधारण उपयोगिता हो सकती है जो डेवलपर्स को _most_ उपयोग के मामलों को कवर करने में मदद करती है, और यह "मानक आयात एक्सटेंशन" कॉन्फ़िगरेशन मान है जिसे मैंने समझाया है।

बेशक, यहाँ "गारंटी" की समस्या आती है। इससे पहले इस धागे में, यह तर्क दिया गया था कि tsc को "गारंटी" देनी चाहिए कि संकलित js वास्तव में [कुछ वातावरण पर] चलेगा।

अच्छा... शायद यह बहुत कठिन प्रतिबद्धता थी। वास्तव में, tsc के लिए यह गारंटी देना बहुत कठिन है कि js [कुछ वातावरण पर] चलेगा, क्योंकि, जैसा कि आपने अभी वर्णन किया है, वर्तमान JS परिदृश्य में उस वातावरण को परिभाषित करना बहुत कठिन है।

लेकिन @borfast द्वारा प्रस्तावित साधारण फ़्लैग उपयोगिता tsc आज़माने वाले नए उपयोगकर्ताओं द्वारा सामना की गई JS आयात त्रुटियों में से _most_ को हल करती है।

उन्नत उपयोग, जिसका आप उल्लेख करते हैं, इन सभी बातों में शामिल है —

क्या यह सीधे जेएस फाइल है? या यह index.ts के अंदर एक फ़ोल्डर है? या यह package.json वाला एक मॉड्यूल है जो मुख्य क्षेत्र रखता है? या एसनेक्स्ट फील्ड? या कोई अन्य जो गैर-मानक है? या यह एक पथ है जिसे वेबपैक द्वारा फिर से लिखा गया है? या रोलअप? यदि हां, तो कॉन्फ़िगरेशन कहां है? क्या यह शायद एक और बंडलर है?

- ठीक है, वह उपयोग, वास्तव में कस्टम उपयोगकर्ता स्क्रिप्ट, बंडलर और अन्य टूल पर छोड़ा जा सकता है।

लेकिन केवल इसलिए कि उन्नत उपयोग को हल करना कठिन है इसका मतलब यह नहीं है कि हमें आसान मामलों को हल करने से बचना चाहिए।

और सबसे आसान मामला आयात में .js एक्सटेंशन जोड़ना है; जिसे हम हल कर सकते हैं, और हल करना चाहिए।

@weoreference इसलिए मैं आपके द्वारा एक प्रश्न पूछने और मददगार बनने की कोशिश करने के लिए अस्वीकृत हूं और फिर आप प्रश्न को अनदेखा कर देते हैं। ऐसा लगता है कि आप वास्तव में एक उत्पादक समाधान की ओर बढ़ने के बजाय केवल बहस और बहस करना चाहते हैं। आपने ऐसा करने के हर प्रयास को नकार दिया है। इस सूत्र पर मेरे लिए अंतिम संदेश। सभी स्पैमिंग के लिए क्षमा चाहते हैं, सभी।

@Weoreference इस बातचीत की शुरुआत में @DanielRosenwasser टिप्पणियों पर देखें। वह बताते हैं कि वे इसे क्यों लागू नहीं करेंगे ("फिलहाल"? बेकार की उम्मीद देना)। उनके बयान के बाद टाइपस्क्रिप्ट में से किसी ने भी इस विषय पर आगे कोई टिप्पणी नहीं की। मेरे लिए यह चर्चा बंद होनी चाहिए और माइक्रोसॉफ्ट को आधिकारिक तौर पर अपना रुख बताना चाहिए। अवधि।
एक साइड नोट के रूप में - व्यक्तिगत रूप से मैं उस सुविधा के लिए हूं, बहुत कुछ सरल कर दूंगा। मेरी आशा खो गई थी क्योंकि मैं टाइपस्क्रिप्ट टीम के तर्कों को भी समझता हूं।

@weoreference

काल्पनिक नहीं, टीएससी जानता है कि यह इसे उत्पन्न करेगा। tsc का उपयोग करते समय इसके अस्तित्व की गारंटी है।

लेकिन यहां एक समरूपता निहित है जिसे आप स्वीकार नहीं कर रहे हैं।

आप जिस "गारंटी" का उल्लेख करते हैं, वह दोनों तरह से है। यदि, जैसा कि आप कहते हैं, "tsc जानता है कि यह [js फ़ाइलें] उत्पन्न करेगा", तो यह पूछने के लिए एक समान रूप से मान्य प्रश्न है: "ठीक है, तो tsc इस गारंटी पर कार्य क्यों नहीं कर रहा है और .js एक्सटेंशन लागू करें जो इसे पता है संकलित जेएस से गायब है?"

समरूपता वास्तव में धारण नहीं करती है। यह केवल "एक .js एक्सटेंशन लागू करने" जितना आसान नहीं है - tsc को विनिर्देशक को हल करना और फिर से लिखना होगा, और संकल्प प्रकार की घोषणाओं पर निर्भर हो सकता है। टाइपस्क्रिप्ट और बैबेल एकल-मॉड्यूल संकलन मोड (tsc के लिए पृथक मॉड्यूल) का समर्थन करते हैं और इस मामले में यदि आप जावास्क्रिप्ट के बजाय प्रकार आयात करते हैं, तो tsc को यह निर्धारित करने के लिए प्रकार की घोषणाओं को लोड करना होगा कि संबंधित .js फ़ाइल कहां होगी, ताकि इसे फिर से लिखा जा सके। विनिर्देशक चीजों को सुसंगत रखने और किनारे के मामले नहीं रखने के लिए, केवल .js फ़ाइलों को आयात करने का समर्थन करना सबसे आसान है जो संकलन से पहले मौजूद हैं या वर्तमान प्रोजेक्ट के ज्ञात परिणाम हैं।

@justinfagnani @Draccoz धन्यवाद; ठीक है, हाँ मैं समझता हूँ।

मेरी अंतिम टिप्पणी: "केवल इसलिए कि कठिन मामलों को हल नहीं किया जा सकता है इसका मतलब यह नहीं है कि हम आसान मामलों को हल नहीं कर सकते।"

शुक्रिया

मैं इस धारणा के तहत रहा हूं कि टाइपस्क्रिप्ट यहां कल्पना के खिलाफ जा रहा है (और अमान्य जावास्क्रिप्ट का उत्पादन कर रहा है), लेकिन मुझे उस कल्पना में कहीं भी नहीं मिल रहा है जिसके लिए वास्तव में आयात पथ मिलान फ़ाइल नामों (एक्सटेंशन के साथ) की आवश्यकता है। इसे पचाना बहुत कठिन है, इसलिए मैं पूरी तरह से आश्वस्त नहीं हूं, लेकिन मैं केवल इतना पा सकता हूं कि कल्पना के लिए 'फ्रॉमक्लॉज' में 'मॉड्यूलस्पेसिफायर' को 'स्ट्रिंगलिटरल' होना आवश्यक है। एक बहुत ही ढीली परिभाषा लगती है, लेकिन मुझे लगता है कि कई अलग-अलग वातावरणों में मॉड्यूल रिज़ॉल्यूशन में लचीलेपन की अनुमति देने के लिए हो सकता है जिसमें ईसीएमएस्क्रिप्ट मौजूद है। क्या कोई पुष्टि कर सकता है कि क्या मैं इसे सही ढंग से पढ़ रहा हूं? यदि वास्तव में ऐसा है, तो मुझे टाइपस्क्रिप्ट द्वारा इसे संभालने के तरीके के प्रति अपना रुख नरम करना होगा। हालांकि, मैं अब भी पसंद करूंगा कि टाइपस्क्रिप्ट, नोड और वेब के बीच अधिक अंतःक्रियाशीलता हो। वर्तमान स्थिति आदर्श नहीं है।

मैं इसे पढ़ने के बाद इस मुद्दे पर आया था। उस मुद्दे ने मुझे यह आभास दिया कि ES युक्ति के कारण नोड का सिस्टम जिस तरह से करता है (सख्ती से मिलान करने वाले फ़ाइल नाम) संचालित करता है, लेकिन अब मैं देख सकता हूं कि मैंने इसे गलत तरीके से पढ़ा (वे ES कल्पना का जिक्र नहीं कर रहे थे), और शायद न तो नोड, न ही टाइपस्क्रिप्ट वास्तव में कुछ भी 'गलत' कर रहे हैं। फिर, यह मुद्दा वास्तव में विभिन्न वातावरणों के बीच मॉड्यूल रिज़ॉल्यूशन के लिए समान रूप से मान्य दृष्टिकोणों के बीच असंगतियों के बारे में है। फिर भी, स्पष्ट रूप से टाइपस्क्रिप्ट का मुख्य लक्ष्य वातावरण नोड और वेब हैं, और हालांकि नोड सैद्धांतिक रूप से अपना दृष्टिकोण बदल सकता है, मुझे नहीं लगता कि ब्राउज़रों के लिए इसकी बहुत संभावना है, इसलिए मुझे अभी भी लगता है कि यह समस्या मान्य है।

संपादित करें: मुझे लगता है कि यह कल्पना का यह खंड हो सकता है जो यह निर्दिष्ट करता है कि मॉड्यूल रिज़ॉल्यूशन 'होस्ट-डिफ़ाइंड' है?

@kj प्रासंगिक विशिष्ट पाठ HTML युक्ति में है: https://html.spec.whatwg.org/multipage/webappapis.html#resolve -a-module-specifier

यह कहता है कि आयात विनिर्देशक पूर्ण URL या पूर्ण या सापेक्ष पथ होना चाहिए। यदि विनिर्देशक URL के रूप में पार्स नहीं करता है (आमतौर पर http:// या https:// से शुरू होता है) या / , ./ , या ../ से शुरू होता है

कोई अन्य पथ खोज या समाधान नहीं किया जाता है। इसका मतलब यह है कि विनिर्देशक को मॉड्यूल के पूर्ण URL को हल करना होगा और यदि सर्वर को इसकी आवश्यकता है तो आपको एक्सटेंशन शामिल करना होगा। सर्वर के पास एक्सटेंशन रहित URL के लिए प्रतिक्रियाएँ वापस करने का विकल्प होता है।

मॉड्यूल के लिए नोड के अधिक प्रतिबंधात्मक रिज़ॉल्यूशन एल्गोरिदम के साथ जाने का कारण वेब के साथ अधिक संगत होना है, ताकि यह अधिक सामान्य हो कि npm पर प्रकाशित मॉड्यूल को ब्राउज़र में मूल रूप से चलाने के लिए अतिरिक्त टूलिंग की आवश्यकता न हो। पैकेज नाम से आयात करना अभी भी एक बहुत ही महत्वपूर्ण विशेषता है, इसलिए नोड इसका समर्थन करता है, लेकिन आयात मानचित्र प्रस्ताव (जिसे डेनो और सिस्टमजेएस पहले से समर्थन करते हैं) के साथ संगत होने का लक्ष्य रखता है।

सभी ने बताया, .js एक्सटेंशन के साथ आयात करने के लिए tsc का समर्थन नोड और वेब ब्राउज़र दोनों में पूरी तरह से काम करता है। यह वास्तव में विस्तारहीन आयात है जो अतिरिक्त उपकरणों के बिना समस्याएं पैदा करता है। आमतौर पर हालांकि, पैकेज नामों के लिए नोड रिज़ॉल्यूशन का समर्थन करने वाले टूल क्लास की आवश्यकता () शैली रिज़ॉल्यूशन का भी उपयोग करेंगे और सापेक्ष पथों को हल करेंगे और उनके एक्सटेंशन भी जोड़ेंगे। यह वही है जो es-dev-server करता है।

धन्यवाद @justinfagnani। तो कम से कम ब्राउज़र में यह वास्तव में इस बात पर निर्भर करता है कि सर्वर इसे कैसे लागू करता है। यह जानकर अच्छा लगा। यह अभी भी काफी सहज और भ्रमित करने वाला है और मुझे विश्वास है कि समुदाय की भलाई के लिए परियोजनाओं के बीच अधिक अभिसरण की आवश्यकता है, लेकिन मुझे अब यकीन नहीं है कि यह कैसा दिख सकता है।

संपादित करें: अभी के लिए, यह मेरे लिए पर्याप्त होगा (विशेषकर ऊपर दिए गए स्पष्टीकरण को देखते हुए, मैं इसके साथ अधिक सहज महसूस करता हूं):

https://nodejs.org/api/esm.html#esm_customizing_esm_specifier_resolution_algorithm

मुझे यकीन नहीं है कि यह विकल्प टाइपस्क्रिप्ट दस्तावेज़ीकरण में संदर्भित है, लेकिन यदि ऐसा नहीं है, तो शायद यह भ्रम से बचने के लिए होना चाहिए। ऐसा प्रतीत नहीं होता है, या तो ' साइट: typescriptlang.org विनिर्देशक-रिज़ॉल्यूशन' या ' साइट: स्टेजिंग -टाइपस्क्रिप्ट.org विनिर्देशक-रिज़ॉल्यूशन' खोज रहा है। हालांकि, चूंकि यह अभी भी नोड में काफी नया है, यह बहुत आश्चर्यजनक नहीं है।

@justinfagnani मैं सहमत हूं कि .js एक्सटेंशन ज्यादातर मामलों में काम करता है, उन मामलों को छोड़कर जहां कोई वैचारिक रुख _के खिलाफ लेता है (उदाहरण के लिए https://github.com/TypeStrong/ts-node/issues/783, जिससे आप परिचित हैं)।

मैंने यहाँ पर @quantuminformation की स्क्रिप्ट का निर्भरता-मुक्त संस्करण बनाया है। उस संस्करण में एक रेगेक्स भी शामिल है जो केवल उन मॉड्यूल को प्रतिस्थापित करेगा जो पहले से ही .js के साथ समाप्त नहीं होते हैं।

वही जरूरत

आयात विवरण में .js का उपयोग करके ESM संगतता के लिए .js एक्सटेंशन प्राप्त करना मेरे लिए काम नहीं कर रहा है। जब मैं एक टीएस फ़ाइल आयात करता हूं और किसी भी एक्सटेंशन को छोड़ देता हूं, तो यह ठीक से संकलित होता है। जब मैं आयात में .js एक्सटेंशन जोड़ता हूं, तो मुझे TS कंपाइलर से बहुत सारी त्रुटियां (जो मौजूद नहीं होनी चाहिए) मिलती हैं।

ऐसा लगता है कि यह सुविधा विकसित नहीं होने का मुख्य कारण विभिन्न बंडलर के साथ संगतता की कठिनाई/असंभवता है, लेकिन ईसीएमएस्क्रिप्ट में मॉड्यूल के लिए समर्थन के अभाव में नोड.जेएस और बंडलर ने अपनी मॉड्यूल योजनाएं विकसित की हैं। अब जबकि हमारे पास ईएसएम है, जैसा कि कुछ लोग इसे अपर्याप्त मान सकते हैं, यह आगे का रास्ता है। जैसे-जैसे ईएसएम और वेब घटकों में अधिक कोड विकसित होता है, बंडलर का उपयोग कम होता जाएगा, और टीएस और ईएसएम के बीच यह दर्द बिंदु अधिक घर्षण विकसित करेगा। यह अच्छा होगा, भले ही प्रारंभिक समर्थन छोटी गाड़ी है और सभी उपयोग के मामलों पर विचार नहीं करता है, अगर यह समर्थित होना शुरू हो सकता है।

जब तक कोई बेहतर समाधान न हो, यह निर्माण कार्य के रूप में उपयोग करने के लिए एक नो-डिपेंडेंसी नोड स्क्रिप्ट है

आप package.json में कॉन्फ़िगर करें:

  ..
    "scripts": {
        "build": "node build.js",
   ...

//build.js
import { execSync} from "child_process"
import * as util from "util"
import * as fs from "fs"
import * as path from "path"

//function to recurse dirs finding files
function fromDir(startPath, filter, callback) {

    //console.log('Starting from dir '+startPath+'/');

    if (!fs.existsSync(startPath)) {
        console.log("no dir ", startPath);
        return;
    }

    var files = fs.readdirSync(startPath);
    for (var i = 0; i < files.length; i++) {
        var filename = path.join(startPath, files[i]);
        var stat = fs.lstatSync(filename);
        if (stat.isDirectory()) {
            fromDir(filename, filter, callback); //recurse
        }
        else if (filter.test(filename)) callback(filename);
    };
};

//this add .js to lines like:  import .* from "\.  <-- only imports from ./ or ../ are touched
function addDotJsToLocalImports(filename) {
    var buf = fs.readFileSync(filename);
    let replaced = buf.toString().replace(/(import .* from\s+['"])(?!.*\.js['"])(\..*?)(?=['"])/g, '$1$2.js')
    if (replaced !== buf.toString()) {
        fs.writeFileSync(filename, replaced)
        console.log("fixed imports at "+filename )
    }
}

//------------------------
//---BUILD TASK START 
//------------------------

execSync("npx tsc --build -verbose", { stdio: 'inherit' })

//add .js to generated imports so tsconfig.json module:"ES2020" works with node
//see: https://github.com/microsoft/TypeScript/issues/16577
fromDir("./dist", /\.js$/, addDotJsToLocalImports)

https://github.com/microsoft/TypeScript/issues/16577#issuecomment -310426634 पर आधारित

क्या कोई याद कर सकता है कि 3 साल पहले जब इस मुद्दे को खोला गया था तब वे क्या कर रहे थे?

गैर-बंडलर समाधान वेब-वितरित परियोजनाओं को विस्तार के रूप में .js के साथ लिखना है।

वह 100% काम करता है। बड़ी समस्या ऐसे मॉड्यूल लिखने की कोशिश कर रही है जो वेब और Node.js को लक्षित करते हैं, लेकिन यह सामान्य रूप से JS के लिए एक समस्या है।

अगर कुछ किया जाना था, तो वह --moduleResolution=web जोड़ देगा, लेकिन यह इस मुद्दे का दायरा यहां नहीं है।

मुझे .js एक्सटेंशन जोड़ने के लिए यह पोस्ट-बिल्ड स्क्रिप्ट लिखनी पड़ी।

fix-ts-imports

#!/usr/bin/env sh

# Fixes JavaScript module imports generated by TypeScript without extension.
# Converts
# import {} from './module'
# into
# import {} from './module.js'
#
# EXAMPLE
# ./fix-ts-imports

ProjectDir="$(cd "$(dirname "$0")/.." && pwd)"

fix() {(
        local pkg="$1"
        shift

        find "$pkg" -type f -iname '*.js' -not -ipath '*/node_modules/*' -print0 \
        | while read -r -d '' file; do
                sed -i '' -E 's|(import .+ from ['\''"]\.?\./.+[^.][^j][^s])(['\''"])|\1.js\2|g' "$file"
        done
)}

if test $# -eq 0; then
        set -- "$ProjectDir"
fi

for pkg; do
        fix "$pkg"
done

मेरे पास जावास्क्रिप्ट में समान स्क्रिप्ट है:
https://github.com/yoursunny/NDNts/blob/743644226fe18d48e599181e87ad571a2708a773/mk/build-post.js

इसे इस प्रकार बुलाया जाता है:

tsc -b mk/tsconfig-solution.json -w --listEmittedFiles \
  | node mk/build-post.js

इस प्रकार की लिपियों का मुख्य दोष यह है कि वे स्रोत मानचित्रों को तोड़ देते हैं, जिससे डिबगिंग कम प्रभावी हो जाती है।

स्रोत में आधुनिक टूलिंग और .js एक्सटेंशन का उपयोग करके, नोड और ब्राउज़र में सब कुछ उत्कृष्ट रूप से काम करता है

• टाइपप्रति
• ईएस मॉड्यूल
• जमना

मैं केवल यह मान सकता हूं कि यहां परेशानी वाले लोग वास्तव में ईएस-मॉड्यूल और नोड रिज़ॉल्यूशन के कुछ टूटे हुए हाइब्रिड में फंस गए हैं, क्योंकि डेवलपर्स अपने पुराने वर्कफ़्लो के परिचित स्थलों से चिपके रहते हैं - शायद वेबपैक को दोष देना है ...

- शायद वेबपैक को दोष देना है ...

और इसलिए - बिल्ली बैग से बाहर है।

स्रोत में आधुनिक टूलिंग और .js एक्सटेंशन का उपयोग करके, नोड और ब्राउज़र में सब कुछ उत्कृष्ट रूप से काम करता है

_अधिकांश_ चीजें उत्कृष्ट रूप से काम करती हैं, और मैं सहमत हूं कि स्रोत फ़ाइलों में सभी के निर्यात में .js एक्सटेंशन होने चाहिए। मेरे अनुभव में, एक चीज जो इसके साथ अच्छी तरह से काम नहीं करती है, वह है ts-node, .js एक्सटेंशन का समर्थन करने के लिए उनके जिद्दी इनकार के कारण। हां, आप नोड चलाने से पहले एक पूर्व-ट्रांसपिलेशन चरण जोड़ सकते हैं, और .js आयात काम करेगा, लेकिन यदि आप .ts कोड चलाना चाहते हैं या सीधे नोड के साथ और ब्राउज़र में भी परीक्षण करना चाहते हैं, आप वर्तमान में ज्यादातर भाग्य से बाहर हैं। (स्पष्ट करने के लिए, मुझे लगता है कि यह एक ts-नोड बग है, टाइपस्क्रिप्ट बग नहीं)।

धन्यवाद @ चेस-मोस्कल।

मैंने रेपो और tsconfig फ़ाइल को फिर से तैयार किया, और अब
import {something} from './something.js'
फेंकता नहीं
typescript force overwrite error TS5055: Cannot write file because it would overwrite input file
अब और, और मुझे अब fix-ts-imports हैक की आवश्यकता नहीं है।

250+ टिप्पणियों में, बहुत कम स्पष्टता आई है। संक्षेप में:

पृष्ठभूमि

ब्राउज़र मॉड्यूल

ब्राउज़र संबंधित URL सहित, URL के अनुसार EcmaScript मॉड्यूल का समाधान करते हैं। ( व्हाटडब्ल्यूजी )

Node.js मॉड्यूल

Node.js एक अधिक जटिल एल्गोरिथ्म के माध्यम से मॉड्यूल (EcmaScript और Node.js-विशिष्ट CommonJS दोनों) को हल करता है जिसमें कई फ़ॉलबैक और पार्सिंग package.json फ़ाइलें शामिल हैं। ( Node.js ) जिसे अनुकूलित किया जा सकता है, उदाहरण के लिए --experimental-specifier-resolution=explicit के साथ जिसके लिए पूर्ण पथ की आवश्यकता होती है।

टाइपस्क्रिप्ट मॉड्यूल

टाइपस्क्रिप्ट में कई उपलब्ध मॉड्यूल रिज़ॉल्यूशन एल्गोरिदम और इन्हें और अधिक अनुकूलित करने के लिए कई विकल्प हैं। ( टाइपस्क्रिप्ट ) आशय यह है कि उपयोगकर्ता उसी मॉड्यूल विनिर्देशक को लिखते हैं जो उत्पादित आउटपुट में उपयोग किए जाते हैं, tsc के रिज़ॉल्यूशन को बेसयूआरएल और पाथमैपिंग जैसे विकल्पों के साथ समायोजित करते हैं।

व्यवहार में, अधिकांश उपयोगकर्ता नोड मॉड्यूल समाधान का उपयोग करते हैं, एक Node.js वातावरण या संगत बंडलर को लक्षित करते हैं। यह अनुरोध बिना बंडलर के ब्राउज़र को लक्षित करने वाले उपयोगकर्ताओं पर केंद्रित है।

टीएस-नोड मॉड्यूल संकल्प

जाहिर है, ts-नोड एक्सटेंशन के साथ मॉड्यूल पहचानकर्ताओं का समर्थन नहीं करता है । हालांकि यह स्पष्ट नहीं है कि क्यों, क्योंकि Node.js और टाइपस्क्रिप्ट दोनों करते हैं, और ts-node जाहिरा तौर पर उन का समामेलन है।

तथ्यों

तथ्य 1: आप .js एक्सटेंशन का उपयोग कर सकते हैं

व्यापक संगतता (अर्थात् ब्राउज़र) के लिए, आप आज .js एक्सटेंशन का उपयोग कर सकते हैं। टीएस-नोड (आईएमओ बग) के अजीब अपवाद के साथ, सब कुछ अभी पूर्ण पथ निर्दिष्ट करके काम करता है (यानी, विस्तार सहित)।

तथ्य 2: यह "एक्सटेंशन जोड़ें" जितना आसान नहीं है

इस अनुरोध को "मॉड्यूल पहचानकर्ता को फ़ाइल पथ में बदलने" के रूप में बेहतर ढंग से संक्षेपित किया गया है। जैसे ./example बन जाता है ./example/index.js और 'lodash' बन जाता है '.node_modules/lodash/index.js' ।

ध्यान दें कि कभी-कभी कोई हल किया गया फ़ाइल पथ भी नहीं होता है, जैसे परिवेश मॉड्यूल घोषणाओं के साथ।

declare module "lodash" {
}

शायद मॉड्यूल पुनर्लेखन वर्तमान परियोजना/संकलन में टीएस मॉड्यूल तक ही सीमित है।

किसी भी स्थिति में, अब हम TS के एक डिज़ाइन पैरामीटर का उल्लंघन कर रहे हैं, कि अन्य मॉड्यूल वर्तमान के आउटपुट को प्रभावित करते हैं।

निष्कर्ष

वेब के लिए काम करने वाले मॉड्यूल पहचानकर्ताओं के लिए पथ का उपयोग करना संभव है। (उदाहरण के ./foo/index.js के बजाय ./foo ।)

(हालांकि व्यावहारिक रूप से बोलते हुए, आप ब्राउज़र को लक्षित करने के लिए एक बंडलर चाहते हैं। अर्थात्, यदि एनपीएम पैकेज का उपयोग किया जाता है।)

@pauldraper "तथ्य 2" के साथ एक महत्वपूर्ण समस्या है:

इस अनुरोध को "मॉड्यूल पहचानकर्ता को फ़ाइल पथ में बदलने" के रूप में बेहतर ढंग से संक्षेपित किया गया है। जैसे ./example ./example/index.js बन जाता है और 'lodash' 'node_modules/lodash/index.js' बन जाता है।

आप वास्तव में संकलन समय पर अपने पैकेज के बाहर विनिर्देशकों को हल नहीं करना चाहते हैं, क्योंकि जब पैकेज कहीं और स्थापित होता है तो ये पथ उपलब्ध नहीं हो सकते हैं। आपको प्रत्येक अद्वितीय पैकेज स्थापना में नोड मॉड्यूल रिज़ॉल्यूशन चलाने की आवश्यकता है। अन्यथा हम import {} from './node_modules/lodash/index.js' लिख और प्रकाशित कर सकते थे और इसके साथ किया जा सकता था।

@justinfagnani , मैं सहमत हूं, लेकिन यह दर्शाता है कि मॉड्यूल पहचानकर्ता सार हैं और आप टीएससी के बाहर मॉड्यूल के स्थानों में हेरफेर कर रहे हैं। और वह tsc इस तरह के जोड़तोड़ के साथ खुद को चिंतित करने की आवश्यकता नहीं है/नहीं है।

इस अनुरोध को "मॉड्यूल पहचानकर्ता को फ़ाइल पथ में बदलने" के रूप में बेहतर ढंग से संक्षेपित किया गया है। जैसे ./example बन जाता है ./example/index.js और 'lodash' बन जाता है '.node_modules/lodash/index.js'।
ध्यान दें कि कभी-कभी कोई हल किया गया फ़ाइल पथ भी नहीं होता है, जैसे परिवेश मॉड्यूल घोषणाओं के साथ।

ऐसा नहीं है कि यह अनुरोध किस बारे में है। यह कोड उत्सर्जित करते समय एक्सटेंशन जोड़ने के बारे में है। हम अतिरिक्त हैकी बिल्ड स्टेप के बिना टाइप: "मॉड्यूल" के साथ संगत मॉड्यूल लिखना चाहते हैं। लॉश जैसे बाहरी मॉड्यूल .js के बिना भी काम करना जारी रखेंगे क्योंकि ये CommonJs हैं।

उदाहरण:

// ./src/moduleA.ts
export const test = 2;

// ./src/moduleB.ts
import {test} from './moduleA'



md5-ec0300a1c6d92a03c70699d0e52c0072



```js
// ./lib/moduleB.js
import {test} from './moduleA.js'

उपरोक्त टाइपस्क्रिप्ट के अलावा package.json "निर्यात" और "प्रकार" का समर्थन नहीं करते हैं। मेरे द्वारा प्रबंधित परियोजनाओं में सच्चे ईएसएम की ओर कोई रास्ता नहीं है।

यह अनुरोध बिना बंडलर के ब्राउज़र को लक्षित करने वाले उपयोगकर्ताओं पर केंद्रित है।

यह गलत है। मैं ब्राउज़रों के लिए शायद ही कभी टीएस/जेएस लिखता हूं, मैं ज्यादातर सर्वर-साइड कोड पर काम करता हूं और मुझे इसकी भी आवश्यकता है क्योंकि मैं नोड में ईएसएम लोडिंग का उपयोग करना चाहता हूं और मॉड्यूल लोडिंग के लिए बंडलर और अतिरिक्त कोड पर निर्भर नहीं हूं।

लॉश जैसे बाहरी मॉड्यूल .js के बिना भी काम करना जारी रखेंगे क्योंकि ये CommonJs हैं।

जब तक वे नहीं हैं।

जब उत्सर्जित।

यह ./moduleA.js हो सकता है। या यह ./moduleA/index.js हो सकता है, है ना? Node.js मॉड्यूल रिज़ॉल्यूशन कई रास्तों की अनुमति देता है।

जब तक वे नहीं हैं।

क्या आप उदाहरण प्रदान कर सकते हैं जब ये काम नहीं करेंगे? Node.js को कॉमनजेएस से नामित निर्यात आयात करने के लिए अभी-अभी समर्थन मिला है।
https://nodejs.org/api/esm.html#esm_import_statements

यह ./moduleA.js हो सकता है। या यह ./moduleA/index.js हो सकता है, है ना? Node.js मॉड्यूल रिज़ॉल्यूशन कई रास्तों की अनुमति देता है।

ईएसएम मोड में नहीं। index.js अब समर्थित नहीं होगा जैसा कि अभी है। ESM लोडर package.json मेटाडेटा "निर्यात" और "प्रकार" पढ़ेगा।
https://nodejs.org/api/esm.html#esm_mandatory_file_extensions

टाइपस्क्रिप्ट + नोड.जेएस आधारित परियोजनाओं के लिए हमें बेहतर देशी ईएसएम कहानी की आवश्यकता है। यह टूलिंग (टाइपस्क्रिप्ट) या नोड.जेएस के माध्यम से हो सकता है समस्या यह है कि क्या किया जाना चाहिए, इस पर आम सहमति की कमी है।

नोड पीआर के लिए हटाए गए लिंक को संपादित करें क्योंकि यह भ्रामक था।