---
url: https://nsh.dev/hi/docs/dev-server-and-debugging
description: "nsh run और nsh dev के साथ Rust और TSX ऐप्स चलाएँ, सिमुलेटर, एमुलेटर और डिवाइस कनेक्ट करें, और रीबिल्ड, hot module replacement, लॉग, error overlay तथा source-mapped stacks का उपयोग करें।"
---

# Dev Server और डीबगिंग

डेवलपमेंट के दौरान NSH हर सेव पर आपका ऐप बिल्ड करता है। Rust ऐप (`nsh.json` अपने `"root"` का नाम बताता है) अपने ही रनर में बिल्ड होता है, जिसे `nsh run` शुरू करता है; उसके क्रेट में बदलाव होने पर वह दोबारा बिल्ड होता है और ऐप रीस्टार्ट हो जाता है। TSX ऐप हर कनेक्टेड होस्ट को भेजा जाता है, जो अपडेट को उसी जगह लागू कर लेता है। यह काम दो कमांड करते हैं:

- `nsh run` ऐप को बिल्ड **और** लॉन्च करता है: Mac Catalyst या AppKit विंडो, Linux पर GTK विंडो, Windows पर Win32 विंडो, iOS सिमुलेटर, Android डिवाइस या एमुलेटर, या ब्राउज़र पेज। TSX के लिए यह डेव सर्वर भी शुरू करता है, जिससे डेवलपमेंट होस्ट कनेक्ट होता है।
- `nsh dev --server-only` TSX के लिए डेव सर्वर शुरू करता है, उन होस्ट के लिए जिन्हें आप खुद शुरू करते हैं: डेवलपमेंट SDK वाला आपका अपना ऐप, नेटवर्क पर मौजूद कोई डिवाइस, या एक साथ कई होस्ट।

```sh
# A Rust app, from its directory
nsh run                             # AppKit window (macOS); GTK window (Linux); Win32 window (Windows)
nsh run --target ios                # iOS simulator
nsh run --target android            # Android device or emulator

# A TSX app
nsh run App.tsx                     # AppKit window (macOS); GTK window (Linux); Win32 window (Windows)
nsh run App.tsx --target macos      # AppKit window (macOS)
nsh run App.tsx --target ios        # iOS simulator
nsh run App.tsx --target android    # Android device or emulator
nsh dev App.tsx --server-only       # server only
```

`nsh dev` डिफ़ॉल्ट रूप से नेटिव होस्ट भी खोलता है; मोबाइल होस्ट `--target ios` या `--target android` का उपयोग करते हैं।

## `nsh run`

| फ़्लैग | विवरण |
|---|---|
| `--target <catalyst \| ios \| android \| macos \| linux \| windows \| gpui \| web>` | कहाँ चलाना है। macOS (AppKit) पर डिफ़ॉल्ट `macos`, Linux पर `linux`, Windows पर `windows`। Rust ऐप इन सभी पर चलता है, सिवाय `gpui` के, जो अपना रूट GPUI ऐप में एम्बेड करता है ([GPUI](https://nsh.dev/translations/hi/docs/gpui.md))। |
| `--device <name or UDID>` | उपयोग किया जाने वाला iOS सिमुलेटर। डिफ़ॉल्ट: पहले से बूट किया हुआ सिमुलेटर, नहीं तो सबसे नया iPhone (जिसे आपके लिए बूट किया जाता है)। |
| `--port <port>` | डेव सर्वर पोर्ट। डिफ़ॉल्ट 8790; यह व्यस्त हो तो अगला खाली पोर्ट इस्तेमाल होता है। |
| `--release` | TSX के रिलीज़ बिल्ड सर्व करें (minified, बिना डीबग जानकारी, बिना हॉट अपडेट)। |
| `--trace` | होस्ट पर हर commit का समय लॉग करें (TSX ऐप)। |

हर टारगेट क्या करता है:

- **`catalyst`** (macOS) डेवलपमेंट होस्ट को Mac ऐप के रूप में चलाता है। `nsh run` को रोकने (Ctrl-C, या `kill`) पर यह बंद हो जाता है, और विंडो बंद करने पर `nsh run` समाप्त हो जाता है।
- **`macos`** (macOS) AppKit डेवलपमेंट होस्ट को उसी तरह चलाता है, यानी 1200×800 विंडो में एक डेस्कटॉप ऐप; Cmd+R नवीनतम बिल्ड रीलोड करता है। इसके लिए macOS 14 या बाद का संस्करण चाहिए ([macOS](https://nsh.dev/translations/hi/docs/macos.md))।
- **`linux`** (Linux) GTK डेवलपमेंट होस्ट को 390×844 विंडो में उसी तरह चलाता है: `nsh run` को रोकने पर यह बंद हो जाता है, और विंडो बंद करने पर `nsh run` समाप्त हो जाता है। इसके लिए GTK 4.14 या बाद का संस्करण चाहिए ([Linux](https://nsh.dev/translations/hi/docs/linux.md))।
- **`windows`** (Windows) Win32 डेवलपमेंट होस्ट को 1200×800 विंडो में उसी तरह चलाता है; होस्ट कभी `nsh run` से अधिक देर तक नहीं चलता, कंसोल बंद होने पर भी नहीं। इसके लिए Windows 10 1809 या बाद का संस्करण चाहिए ([Windows](https://nsh.dev/translations/hi/docs/windows.md))।
- **`ios`** डेवलपमेंट होस्ट को सिमुलेटर में इंस्टॉल करता है, उसे डेव सर्वर की ओर इंगित करके लॉन्च करता है और निगरानी जारी रखता है। सिमुलेटर Mac का नेटवर्क साझा करता है, इसलिए होस्ट सर्वर तक `127.0.0.1` पर पहुँचता है। `nsh run` को रोकने (Ctrl-C) पर होस्ट बंद हो जाता है, वरना वह अगले सेशन से जुड़ जाता। इसके लिए Xcode चाहिए।
- **`android`** डेवलपमेंट होस्ट APK इंस्टॉल करता है (केवल तब दोबारा जब रनटाइम बदला हो), `adb reverse tcp:<port> tcp:<port>` चलाता है ताकि डिवाइस का अपना `127.0.0.1` सर्वर तक पहुँच सके, और उसे शुरू करता है। यह एमुलेटर या USB डिवाइस के साथ काम करता है। इसके लिए Android SDK (`ANDROID_HOME`) चाहिए। जब `nsh run` समाप्त होता है (Ctrl-C पर भी), तो यह होस्ट को रोक देता है और वह पोर्ट फ़ॉरवर्डिंग हटा देता है, ताकि होस्ट अगले सेशन से न जुड़े।

जब `nsh run` समाप्त होता है, चाहे जैसे भी, तो वह अपने शुरू किए हुए होस्ट को रोक देता है: वह Catalyst ऐप को बंद करता है या macOS, Linux या Windows होस्ट को बंद करता है, सिमुलेटर में डेवलपमेंट होस्ट को समाप्त करता है, या डिवाइस पर उसे force-stop करता है।

Rust ऐप के लिए हर टारगेट ऐप का अपना रनर चलाता है, जो उसके क्रेट के साथ बिल्ड होता है: डेस्कटॉप पर डीबग बिल्ड उसी जगह चलता है और उसका आउटपुट टर्मिनल में आता है; iOS और Android पर उसका एक पैकेज इंस्टॉल किया जाता है। TSX के लिए होस्ट सामान्य (generic) होते हैं: वे सर्वर द्वारा भेजा गया कोई भी NSH ऐप चलाते हैं, इसलिए हर ऐप के लिए कुछ बिल्ड नहीं करना पड़ता (जिस ऐप का अपना क्रेट हो, उसे उसी के साथ बने होस्ट मिलते हैं)।

## `nsh dev`

```sh
nsh dev App.tsx
```

```text
✓ built App.tsx (3.2 KB js, 9.8 KB bytecode, 21ms)
→ dev server ws://127.0.0.1:8790/ws
  devices on this network: ws://192.168.1.20:8790/ws
```

| फ़्लैग | विवरण |
|---|---|
| `--port <port>` | डेव सर्वर पोर्ट। डिफ़ॉल्ट 8790 (व्यस्त होने पर अगला खाली पोर्ट)। |
| `--release` | रिलीज़ बिल्ड सर्व करें। |

होस्ट को प्रिंट किए गए URL से कनेक्ट करें:

- **आपका अपना iOS ऐप**, जो `NativeShellDev.xcframework` के साथ लिंक किया गया हो:
  `try app.connectDevServer(URL(string: "ws://192.168.1.20:8790/ws")!)`। देखें [iOS ऐप्स में एम्बेड करना](https://nsh.dev/translations/hi/docs/ios.md#development)।
- **आपका अपना Android ऐप**, `nsh-dev.aar` के साथ: `nsh.connectDevServer("ws://192.168.1.20:8790/ws")`, या
  `adb reverse tcp:8790 tcp:8790` और `ws://127.0.0.1:8790/ws`। देखें [Android ऐप्स में एम्बेड करना](https://nsh.dev/translations/hi/docs/android.md#development)।

एक साथ कितने भी होस्ट कनेक्ट हो सकते हैं; हर बिल्ड सभी को भेजा जाता है। बाद में कनेक्ट होने वाले होस्ट को वर्तमान बिल्ड तुरंत मिल जाता है। जो होस्ट ऐप नहीं चला सकता, क्योंकि ऐप जो UI सेट इम्पोर्ट करता है वह उसमें नहीं है (किसी दूसरे ऐप के लिए बना डेवलपमेंट होस्ट), उसे कोई बिल्ड नहीं मिलता: वह कारण दिखाता है, और टर्मिनल एक `warn` लाइन प्रिंट करता है जिसमें ऐप का होस्ट इंस्टॉल करने वाला कमांड होता है।

> [!NOTE]
> LAN पर मौजूद डिवाइस को डेव सर्वर के पोर्ट पर आपके कंप्यूटर तक पहुँचना होगा: एक ही नेटवर्क, बीच में कोई फ़ायरवॉल नहीं।
> एसेट (इमेज, फ़ॉन्ट) उसी पोर्ट से सादे HTTP पर सर्व किए जाते हैं।

<a id="rust-edits"></a>

## Rust में बदलाव

Rust कंपाइल की जाने वाली भाषा है: ऐप के क्रेट में, या उस क्रेट में जिस पर वह path से निर्भर है, कोई बदलाव होने पर ऐप दोबारा बिल्ड होता है और `nsh run` उसे नए कोड के साथ रीस्टार्ट कर देता है। ऐप की स्टेट नए सिरे से शुरू होती है; जो कुछ रीस्टार्ट के बाद भी बचना चाहिए उसे [स्टोरेज](https://nsh.dev/translations/hi/modules/nsh.md#storage) में रखें। बिल्ड एरर टर्मिनल में प्रिंट होता है, और जो अगला सेव कंपाइल हो जाए, वह ऐप को फिर चलाता है। Rust और TSX दोनों वाले ऐप में TSX के बदलाव हॉट अपडेट रहते हैं (नीचे देखें) और Rust के बदलाव ऐप को रीस्टार्ट करते हैं।

## Hot module replacement

TSX डेवलपमेंट बिल्ड हर सोर्स फ़ाइल के लिए एक मॉड्यूल रखते हैं। जब आप सेव करते हैं, NSH दोबारा बिल्ड करता है, मॉड्यूल की तुलना पिछले अच्छे बिल्ड से करता है और केवल बदले हुए मॉड्यूल वाला एक **पैच** भेजता है। होस्ट उसे एक मिलीसेकंड से भी काफ़ी कम समय में उसी जगह लागू कर देता है; फ़ाइल सेव करने से बदलाव दिखने तक लगभग 120 ms लगते हैं।

आपके ऐप के साथ क्या होता है:

- **केवल वही कॉम्पोनेंट दोबारा रेंडर होते हैं जिन्हें आपने बदला।** हर टॉप-लेवल कॉम्पोनेंट (बड़े अक्षर से शुरू होने वाला फ़ंक्शन जो JSX लौटाता है) एक स्थिर प्रॉक्सी में लिपटा होता है। जब उसका कोड बदलता है (या उसके मॉड्यूल का बाकी कोड, जिसका वह उपयोग कर सकता है), तो उसके इंस्टेंस नए कोड के साथ दोबारा रेंडर होते हैं; जिन कॉम्पोनेंट का कोड नहीं बदला, वे अपने इंस्टेंस रखते हैं, और उनके साथ अपने सिग्नल और स्टेट भी। किसी बटन की स्टाइल बदलें और स्क्रीन वहीं रहती है, उसी इनपुट टेक्स्ट और स्क्रॉल पोज़िशन के साथ।
- **जो मॉड्यूल बदले वे दोबारा चलते हैं**, और वे मॉड्यूल भी जो बदले हुए मॉड्यूल को इम्पोर्ट करते हैं और अपडेट खुद नहीं ले सकते, एंट्री तक। इसलिए मॉड्यूल-लेवल कोड दोबारा चलता है, सिवाय उसके जो अपनी स्टेट बनाए रखता है:
- **टॉप-लेवल सिग्नल और नेविगेशन स्टैक अपनी स्टेट बनाए रखते हैं**: किसी मॉड्यूल के शीर्ष पर `signal(…)` या `createNavStack(…)` से बना `const` बदलावों के बीच अपना मान बनाए रखता है (स्टैक अपने पेज), जब तक उसका अपना इनिशियलाइज़र वही रहता है; नए सिरे से शुरू करने के लिए इनिशियलाइज़र बदलें (`signal(0)` से `signal(10)`)।
- **टॉप-लेवल `context()` ऑब्जेक्ट अपनी पहचान बनाए रखते हैं**, और नया डिफ़ॉल्ट मान ले लेते हैं, ताकि अलग-अलग मॉड्यूल में प्रोवाइडर और कंज़्यूमर आपस में मेल खाते रहें।
- **एंट्री बदलने पर ऐप माउंटेड रहता है।** उसी कॉम्पोनेंट के साथ दोबारा चला `mount(App)` (या `mount(() => <App />)`) जो कुछ माउंट कर चुका है उसे बनाए रखता है: केवल वही कॉम्पोनेंट दोबारा रेंडर होते हैं जिन्हें आपने बदला। `App` को खुद बदलें तो वह दोबारा रेंडर होता है, उन सबके साथ जिन्हें वह रेंडर करता है (उनकी अपनी स्टेट नए सिरे से शुरू होती है), लेकिन मॉड्यूल के शीर्ष पर बना नेविगेटर अपने रूट बनाए रखता है, इसलिए पुश की गई स्क्रीन पुश ही रहती है। जिस `mount` कॉल में बदलाव हुआ (दूसरा कॉम्पोनेंट, प्रॉप्स), वह ऐप को दोबारा माउंट करता है।
- **जो कॉम्पोनेंट एरर फेंकता है** वह एरर रिपोर्ट करता है और जब तक आप उसे ठीक नहीं करते कुछ रेंडर नहीं करता; बाकी ऐप चलता रहता है। अगला सही सेव उसे ठीक कर देता है।

होस्ट पैच करने के बजाय **पूरा ऐप रीलोड करता है** जब:

- बदलाव ऐसा NSH मॉड्यूल इम्पोर्ट करता है जो चल रहे ऐप ने अभी तक इम्पोर्ट नहीं किया था (उदाहरण के लिए पहला `import … from "nsh"`);
- `nsh.json` में ऐप का `capabilities` बदल गया;
- होस्ट वह बिल्ड नहीं चला रहा जिस पर पैच आधारित है (वह अभी कनेक्ट हुआ है, या पिछला लोड विफल रहा);
- कोई पैच लागू नहीं हो पाता।

> [!TIP]
> कॉम्पोनेंट अपने सिग्नल में जो स्टेट रखता है, वह तब रीसेट हो जाती है जब वह कॉम्पोनेंट, या उसे रेंडर करने वाला कोई कॉम्पोनेंट, बदला जाता है। जो स्टेट बदलावों के बाद भी बचनी चाहिए उसे टॉप-लेवल सिग्नल (या स्टोर मॉड्यूल) में रखें, और नेविगेटर मॉड्यूल के शीर्ष पर बनाएँ।

`--release` रिलीज़ बिल्ड सर्व करता है, बिना हॉट अपडेट के: हर सेव ऐप को रीलोड करता है। minified बिल्ड जाँचने के लिए इसका उपयोग करें। डेव सर्वर से लोड की गई कोई भी चीज़, `--release` हो या नहीं, रनटाइम की हार्डनिंग छोड़ देती है (`eval` उपलब्ध रहता है); देखें [सैंडबॉक्स और कैपेबिलिटीज़](https://nsh.dev/translations/hi/docs/sandbox-and-capabilities.md#hardening)।

<a id="logs"></a>

## लॉग

Rust ऐप `log` क्रेट (`log::info!`, `log::warn!`, `log::error!`) से लॉग करता है: `nsh run` डेस्कटॉप पर और iOS सिमुलेटर में ये लाइनें ऐप के आउटपुट के साथ अपने टर्मिनल में दिखाता है।

TSX में `console.log`, `console.info`, `console.debug`, `console.warn` और `console.error` टारगेट `js` के साथ नेटिव लॉग में जाते हैं। जब तक कोई होस्ट कनेक्टेड है, उसकी लॉग लाइनें `nsh run` / `nsh dev` चलाने वाले टर्मिनल को फ़ॉरवर्ड की जाती हैं: आपकी `console.log` लाइनें जैसी हैं वैसी (कई डिवाइस कनेक्ट होने पर डिवाइस के नाम के उपसर्ग के साथ), और चेतावनियाँ तथा एरर डिवाइस के नाम के बाद:

```text
• iPhone 16 Pro connected, build 1
loading more after 1000
warn iPhone 16 Pro: deprecated option
error iPhone 16 Pro: uncaught exception: TypeError: cannot read property 'id' of undefined
          at Row (demos/Photos.tsx:18:22)
```

`console.log` मानों को ब्राउज़र कंसोल की तरह फ़ॉर्मैट करता है: स्ट्रिंग जैसी हैं वैसी, एरर अपने स्टैक के साथ, फ़ंक्शन नाम से, ऑब्जेक्ट और ऐरे JSON के रूप में। जब होस्ट कनेक्टेड नहीं होता, तो लॉग प्लेटफ़ॉर्म के लॉग में जाते हैं (iOS पर Xcode का कंसोल / unified log, Android पर `adb logcat`)।

जो promise रिजेक्ट हुआ और उसे रिजेक्ट करने वाला काम पूरा होने तक (उसके microtasks चलने के बाद) भी जिसका कोई हैंडलर नहीं है, उसे भी एरर के रूप में लॉग किया जाता है, जैसे ब्राउज़र रिपोर्ट करता है: ऐसा `async` फ़ंक्शन जो एरर फेंकता है जबकि कोई उसे await नहीं कर रहा, ऐसा `Promise.reject(…)` जिसे कोई catch नहीं करता, या Rust में ऐसी कॉल जो विफल होती है और जिसका कोई इंतज़ार नहीं कर रहा। यह लाइन वहीं जाती है जहाँ `console.error` जाता है (टर्मिनल, प्लेटफ़ॉर्म का लॉग, वेब पर ब्राउज़र कंसोल), और उसका स्टैक आपके सोर्स की ओर इशारा करता है:

```text
error iPhone 16 Pro: unhandled rejection: Error: HTTP 404
          at loadProfile (App.tsx:12:11)
```

उसी turn में बाद में जोड़ा गया हैंडलर (`const p = load(); …; p.catch(…)`) उसे हैंडल किया हुआ मानता है। जहाँ विफलता मायने रखती है, वहाँ promise को await करें या उसे `.catch` दें।

टर्मिनल का बाकी हिस्सा हर चरण के लिए एक लाइन है (`✓` पूरा हुआ, `→` कहाँ कनेक्ट करना है, `•` डिवाइस ने क्या किया); NSH जो टूल चलाता है (cargo, खुद होस्ट) उनका आउटपुट केवल तब प्रिंट होता है जब कोई विफल हो। `nsh run -v` (या `NSH_VERBOSE=1`) सब कुछ प्रिंट करता है: हर लॉग लाइन अपने लेवल और सोर्स के साथ, cargo का आउटपुट और होस्ट का अपना आउटपुट।

`--trace` हर commit की लागत जोड़ देता है:

```text
perf commit: 10 ops, 151µs (list js 2µs), 8 mount items, 27 nodes
```

इन संख्याओं का मतलब जानने के लिए [टेस्टिंग](https://nsh.dev/translations/hi/docs/testing-and-trace.md) देखें।

<a id="the-error-overlay"></a>

## एरर ओवरले

ये एरर होस्ट पर ऐप के ऊपर संदेश और स्टैक के साथ लाल ओवरले दिखाते हैं:

- बिल्ड विफलता (सिंटैक्स एरर, अज्ञात एलिमेंट, गायब इम्पोर्ट), उस लाइन की ओर इशारा करने वाले code frame के साथ;
- बंडल के evaluate होने के दौरान हुआ एरर;
- इवेंट हैंडलर, टाइमर या इफ़ेक्ट में अनकॉट एक्सेप्शन।

ओवरले को हटाने के लिए उस पर टैप करें। यह अगले सफल रीलोड पर भी गायब हो जाता है। बिल्ड विफलताएँ टर्मिनल में भी प्रिंट होती हैं:

```text
error building App.tsx failed
App.tsx

  x <Buton> names nothing in scope
   ,-[3:11]
 2 | function App() {
 3 |   return <Buton />;
   :           ^^^^^
 4 | }
```

बंडलर TypeScript टाइप बिना जाँचे हटा देता है; टाइप एरर के लिए [`nsh check`](https://nsh.dev/translations/hi/docs/cli.md#nsh-check) चलाएँ (TypeScript का नेटिव कंपाइलर, जिसमें `tsconfig.json` `nsh init` लिखते हैं; Node की ज़रूरत नहीं) या अपने एडिटर पर भरोसा करें।

रिलीज़ बिल्ड में (रिलीज़ SDK वाला एम्बेडिंग ऐप, पैकेज्ड ऐप) एरर लॉग किए जाते हैं और होस्ट ऐप के एरर हैंडलर (`NshAppView.onError`, `NshView.setErrorListener`) को दिए जाते हैं, लेकिन ऐप के ऊपर दिखाए नहीं जाते।

<a id="source-maps-and-stack-traces"></a>

## सोर्स मैप और स्टैक ट्रेस

बंडलिंग एक सोर्स मैप बनाती है जो हर चरण को जोड़ती है (TypeScript → JSX → बंडल), और वह हर बिल्ड के साथ भेजा जाता है। स्टैक ट्रेस प्रिंट या प्रदर्शित होने से पहले रनटाइम बंडल की पोज़िशन को आपके सोर्स में बदल देता है, इसलिए स्टैक `App.tsx:2:28` की ओर इशारा करते हैं, बंडल की ओर नहीं:

```text
error Mac Catalyst: uncaught exception: Error: tap boom
          at <anonymous> (App.tsx:2:58)
```

`nsh build` मैप को `bundle.js.map` के रूप में लिखता है; जो एम्बेडिंग ऐप किसी फ़ोल्डर से बंडल लोड करता है वह उसे बंडल के बगल से पढ़ता है, और [साइन किए गए पैकेज](https://nsh.dev/translations/hi/docs/signed-packages.md) में भी वह होता है, जब तक कि उसे पैकेज के बगल में अलग न रखा गया हो और `nsh symbolicate` से लागू न किया गया हो ([प्रकाशित पैकेजों के एरर](https://nsh.dev/translations/hi/docs/signed-packages.md#errors-from-published-packages))।

<a id="debugging-tips"></a>

## डीबगिंग सुझाव

- **बदलाव के बाद कुछ अपडेट नहीं होता**: टर्मिनल में बिल्ड एरर देखें; ओवरले उसे होस्ट पर भी दिखाता है।
- **ऐप वह पुरानी स्टेट रखता है जिसे आप रीसेट होने की उम्मीद कर रहे थे**: हॉट रिप्लेसमेंट जानबूझकर बिना बदले कॉम्पोनेंट की स्टेट, टॉप-लेवल सिग्नल और नेविगेटर को बनाए रखता है। Ctrl-C और `nsh run` से रीस्टार्ट करें, या स्टेट का इनिशियलाइज़र बदलें।
- **अनुरोध केवल पैकेज्ड या एम्बेडेड बिल्ड में विफल होता है**: ऐप की [कैपेबिलिटीज़](https://nsh.dev/translations/hi/docs/sandbox-and-capabilities.md) जाँचें; अस्वीकृतियाँ जोड़ी जाने वाली key के साथ लॉग होती हैं।
- **कुछ धीमा है**: उसे [`nsh test --trace`](https://nsh.dev/translations/hi/docs/testing-and-trace.md) से headless दोबारा चलाएँ, जो हर नेटिव व्यू ऑपरेशन प्रिंट करता है, या TSX ऐप को `--trace` के साथ चलाएँ।
- **एडिटर में टाइप एरर**: `nsh run` और `nsh dev` `.nsh/types` को अप-टू-डेट रखते हैं; देखें [प्रोजेक्ट संरचना](https://nsh.dev/translations/hi/docs/project-structure.md)।

<a id="see-also"></a>

## यह भी देखें

- [CLI](https://nsh.dev/translations/hi/docs/cli.md)
- [टेस्टिंग](https://nsh.dev/translations/hi/docs/testing-and-trace.md)
- [iOS ऐप्स में एम्बेड करना](https://nsh.dev/translations/hi/docs/ios.md), [Android ऐप्स में एम्बेड करना](https://nsh.dev/translations/hi/docs/android.md)
