diff --git a/1-js/13-modules/02-import-export/article.md b/1-js/13-modules/02-import-export/article.md
index ccbf18cf5..1a1ad451c 100644
--- a/1-js/13-modules/02-import-export/article.md
+++ b/1-js/13-modules/02-import-export/article.md
@@ -1,14 +1,14 @@
-# Export and Import
+# Export و Import
 
-Export and import directives have several syntax variants.
+دستورات export و import شامل چندین نوع پیاده سازی هستند.
 
-In the previous article we saw a simple use, now let's explore more examples.
+در مقاله قبلی استفاده ساده ای از آنها را دیدیم، حال بیایید مثال های بیشتری را بررسی کنیم.
 
-## Export before declarations
+## اکسپورت قبل از تعریف
 
-We can label any declaration as exported by placing `export` before it, be it a variable, function or a class.
+می‌توانیم هر تعریفی را با قرار دادن `export` در قبل آن به عنوان اکسپورت شده علامت گذاری کنیم، که آن می‌تواند تعریف متغیر، تابع یا کلاس باشد.
 
-For instance, here all exports are valid:
+به عنوان مثال، در اینجا همه export ها معتبر هستند:
 
 ```js
 // export an array
@@ -25,12 +25,12 @@ For instance, here all exports are valid:
 }
 ```
 
-````smart header="No semicolons after export class/function"
-Please note that `export` before a class or a function does not make it a [function expression](info:function-expressions). It's still a function declaration, albeit exported.
+````smart header="بعد از export تابع و کلاس سمی‌کالِن نیست"
+لطفا توجه داشته باشید که export قبل از یک کلاس یا تابع آن را به یک [function expression](info:function-expressions) تبدیل نمی‌کند. هنوز هم تعریف یک تابع است اگرچه export شده.
 
-Most JavaScript style guides don't recommend semicolons after function and class declarations.
+اکثر راهنماهای استایل کد جاوااسکریپت توصیه نمی‌کنند پس از تعریف توابع و کلاس ها از سمی‌کالِن یا همان نقطه ویرگول استفاده شود.
 
-That's why there's no need for a semicolon at the end of `export class` and `export function`:
+به همین دلیل نیازی به سمی‌کالِن در انتهای `export class` و `export function` نیست: 
 
 ```js
 export function sayHi(user) {
@@ -40,11 +40,11 @@ export function sayHi(user) {
 
 ````
 
-## Export apart from declarations
+## اکسپورت جدا از تعریف
 
-Also, we can put `export` separately.
+همچنین، می‌توانیم `export` را به طور جداگانه قرار دهیم.
 
-Here we first declare, and then export:
+در اینجا ابتدا تعریف می‌کنیم و سپس export می‌کنیم:
 
 ```js
 // 📁 say.js
@@ -57,15 +57,15 @@ function sayBye(user) {
 }
 
 *!*
-export {sayHi, sayBye}; // a list of exported variables
+export {sayHi, sayBye}; // لیستی از متغیرهای اکسپورت شده
 */!*
 ```
 
-...Or, technically we could put `export` above functions as well.
+یا از نظر فنی می‌توان خط شامل export را در بالای تعریف توابع قرار داد.
 
-## Import *
+## Import *‎
 
-Usually, we put a list of what to import in curly braces `import {...}`, like this:
+معمولاً ما لیستی از آنچه را که می‌خواهیم import کنیم درون کرلی‌بریس `import {...}‎` قرار می‌دهیم، مانند:
 
 ```js
 // 📁 main.js
@@ -77,7 +77,7 @@ sayHi('John'); // Hello, John!
 sayBye('John'); // Bye, John!
 ```
 
-But if there's a lot to import, we can import everything as an object using `import * as <obj>`, for instance:
+اما اگر چیزهای زیادی برای import از یک ماژول وجود داشته باشد، می‌توانیم همه را به عنوان یک شیء با استفاده از `import * as <obj>‎` درون برنامه import کنیم.
 
 ```js
 // 📁 main.js
@@ -89,24 +89,24 @@ say.sayHi('John');
 say.sayBye('John');
 ```
 
-At first sight, "import everything" seems such a cool thing, short to write, why should we ever explicitly list what we need to import?
+در نگاه اول "import همه چیز" چیز خیلی خوبی به نظر می‌رسد، حجم کمتری کد می‌نویسیم، با این حال چرا باید همیشه به صراحت آنچه نیاز داریم را import کنیم؟
 
-Well, there are few reasons.
+خب، چند دلیل وجود دارد.
 
-1. Explicitly listing what to import gives shorter names: `sayHi()` instead of `say.sayHi()`.
-2. Explicit list of imports gives better overview of the code structure: what is used and where. It makes code support and refactoring easier.
+1. فهرست کردن صریح مواردی که باید وارد شوند، نام‌های کوتاه‌تری را نشان می‌دهد: `sayHi()‎` به جای `say.sayHi()‎`.
+2. لیست واضح از import مرور بهتری از ساختار کد ایجاد می‌کند: چه چیزی استفاده شده و کجا. این پشتیبانی و بازبینی کد را آسان تر می‌کند.
 
-```smart header="Don't be afraid to import too much"
-Modern build tools, such as [webpack](https://webpack.js.org/) and others, bundle modules together and optimize them to speedup loading. They also removed unused imports.
+```smart header="از import کردن زیاد نترسید."
+ابزارهای مدرن بیلد مانند [webpack](https://webpack.js.org/) و مانند آن، ماژول ها را با هم باندل (ترکیب و فشرده سازی) می‌کنند و بهینه می‌کنند تا سرعت بارگذاری را افزایش دهند. آنها همچنین import های استفاده نشده را حذف می‌کنند. 
 
-For instance, if you `import * as library` from a huge code library, and then use only few methods, then unused ones [will not be included](https://github.com/webpack/webpack/tree/main/examples/harmony-unused#examplejs) into the optimzed bundle.
+به عنوان مثال، اگر `import * as library` از یک کتابخانه کد بزرگ import کنیم و سپس تنها از چند تابع آن استفاده کنیم، موارد استفاده نشده [درون بسته بهینه شده نخواهد بود](https://github.com/webpack/webpack/tree/main/examples/harmony-unused#examplejs).
 ```
 
-## Import "as"
+## Import "as"‎
 
-We can also use `as` to import under different names.
+همچنین می‌توانیم از `as` برای import تحت نام های متفاوت استفاده کنیم.
 
-For instance, let's import `sayHi` into the local variable `hi` for brevity, and import `sayBye` as `bye`:
+به  عنوان مثال، اجازه دهید برای اختصار `sayHi` را import کنیم و آن را در متغیر محلی `hi` قرار دهیم، همچنین `sayBye` تحت عنوان `bye` :
 
 ```js
 // 📁 main.js
@@ -118,11 +118,11 @@ hi('John'); // Hello, John!
 bye('John'); // Bye, John!
 ```
 
-## Export "as"
+## Export "as"‎
 
-The similar syntax exists for `export`.
+ساختار مشابهی برای export وجود دارد.
 
-Let's export functions as `hi` and `bye`:
+اجازه دهید توابع را تحت عناوین hi و bye در پایین export کنیم:
 
 ```js
 // 📁 say.js
@@ -130,7 +130,7 @@ Let's export functions as `hi` and `bye`:
 export {sayHi as hi, sayBye as bye};
 ```
 
-Now `hi` and `bye` are official names for outsiders, to be used in imports:
+اکنون `hi` و `bye` نام های رسمی برای استفاده در بیرون ماژول هستند، برای استفاده در import ها:
 
 ```js
 // 📁 main.js
@@ -142,31 +142,31 @@ say.*!*bye*/!*('John'); // Bye, John!
 
 ## Export default
 
-In practice, there are mainly two kinds of modules.
+در عمل، عمدتاً دو نوع ماژول وجود دارد.
 
-1. Modules that contain a library, pack of functions, like `say.js` above.
-2. Modules that declare a single entity, e.g. a module `user.js` exports only `class User`.
+1. ماژول هایی که حاوی کتابخانه، بسته ای از توابع، مانند `say.js` بالا هستند.
+2. ماژول هایی که یک موجودیت واحد را اعلان می‌کنند، به عنوان مثال ماژول `user.js` فقط کلاس `User` را export می‌کند.
 
-Mostly, the second approach is preferred, so that every "thing" resides in its own module.
+اغلب، رویکرد دوم ترجیح داده می‌شود، به طوری که هر "چیزی" در ماژول خودش قرار دارد.
 
-Naturally, that requires a lot of files, as everything wants its own module, but that's not a problem at all. Actually, code navigation becomes easier if files are well-named and structured into folders.
+طبیعتاً، این نیاز به تعداد زیادی فایل دارد، زیرا هر چیزی ماژول خود را می‌خواهد، اما این اصلا مشکلی نیست. در واقع، پیمایش کد با نامگذاری و ساختاربندی خوب فایل ها در پوشه ها آسان تر می‌شود.
 
-Modules provide a special `export default` ("the default export") syntax to make the "one thing per module" way look better.
+ماژول ها ساختار `export default` ("export به صورت پیش فرض") را برای بهبود دادن رویکرد "یک چیز در هر ماژول" فراهم می‌کنند.
 
-Put `export default` before the entity to export:
+عبارت `export default` را قبل از موجودیتی که می‌خواهید export کنید قرار دهید:
 
 ```js
 // 📁 user.js
-export *!*default*/!* class User { // just add "default"
+export *!*default*/!* class User { // .اضافه شد default فقط
   constructor(name) {
     this.name = name;
   }
 }
 ```
 
-There may be only one `export default` per file.
+در هر فایل فقط می‌توان یک `export default` داشت.
 
-...And then import it without curly braces:
+و سپس آن را بدون کرلی‌بریس import کنید.
 
 ```js
 // 📁 main.js
@@ -175,39 +175,39 @@ import *!*User*/!* from './user.js'; // not {User}, just User
 new User('John');
 ```
 
-Imports without curly braces look nicer. A common mistake when starting to use modules is to forget curly braces at all. So, remember, `import` needs curly braces for named exports and doesn't need them for the default one.
+بدون کرلی‌بریس import ظاهر بهتری می‌گیرد. اما یک اشتباه رایج هنگام شروع استفاده از ماژول‌ها فراموش کردن کرلی‌بریس‌ها در همه جا است. پس به یاد داشته باشید `import` برای export های نامگذاری شده نیاز به کرلی‌بریس دارد و برای export های پیش فرض نیازی ندارد.
 
-| Named export | Default export |
-|--------------|----------------|
-| `export class User {...}` | `export default class User {...}` |
-| `import {User} from ...` | `import User from ...`|
+| (export نامگذاری شده) Named export | (export پیش فرض) Default export |
+|:----|:----|
+| `export class User {...}‎` | `export default class User {...}‎` |
+| `import {User} from ...‎` | `import User from ...‎`|
 
-Technically, we may have both default and named exports in a single module, but in practice people usually don't mix them. A module has either named exports or the default one.
+از نظر فنی، ممکن است هم export پیش فرض و هم export نامگذاری شده در یک ماژول وجود داشته باشد، اما در عمل معمولا افراد آنها را مخلوط نمی‌کنند. یک ماژول یا export نامگذاری شده دارد یا export پیش فرض.
 
-As there may be at most one default export per file, the exported entity may have no name.
+از آنجایی که فقط امکان تعریف یک export پیش فرض در هر فایل وجود دارد، موجودیت export شده ممکن است نامی نداشته باشد.
 
-For instance, these are all perfectly valid default exports:
+به عنوان مثال، همه اینها export پیش فرضِ معتبر هستند:
 
 ```js
-export default class { // no class name
+export default class { // کلاس اسم ندارد
   constructor() { ... }
 }
 ```
 
 ```js
-export default function(user) { // no function name
+export default function(user) { // تابع اسم ندارد
   alert(`Hello, ${user}!`);
 }
 ```
 
 ```js
-// export a single value, without making a variable
+// شده export یک مقدار واحد را بدون ایجاد متغیر
 export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 ```
 
-Not giving a name is fine, because there is only one `export default` per file, so `import` without curly braces knows what to import.
+عدم استفاده از نام مشکلی ایجاد نمی‌کند، زیرا در هر فایل فقط یک `export default` وجود دارد، بنابراین `import` بدون کرلی‌بریس می‌داند چه چیزی را import کند.
 
-Without `default`, such an export would give an error:
+بدون `default` چنین export کردنی خطا می‌دهد:
 
 ```js
 export class { // Error! (non-default export needs a name)
@@ -217,20 +217,20 @@ export class { // Error! (non-default export needs a name)
 
 ### The "default" name
 
-In some situations the `default` keyword is used to reference the default export.
+در برخی موقعیت‌ها از کلمه‌ی کلیدی `default` برای اشاره به export پیش فرض استفاده می‌شود.
 
-For example, to export a function separately from its definition:
+ به عنوان مثال، برای export جداگانه یک تابع از تعریف آن:
 
 ```js
 function sayHi(user) {
   alert(`Hello, ${user}!`);
 }
 
-// same as if we added "export default" before the function
+// را اضافه کرده‌ایم "export default" شبیه این می‌ماند که قبل از تابع
 export {sayHi as default};
 ```
 
-Or, another situation, let's say a module `user.js` exports one main "default" thing, and a few named ones (rarely the case, but it happens):
+یا موقعیت دیگری، فرض کنید ماژول `user.js` یک چیز را بصورت پیش فرض export می‌کند و چند export بصورت نامگذاری شده دارد (این عمل نادر انجام می‌شود، اما ممکن است):
 
 ```js
 // 📁 user.js
@@ -245,7 +245,7 @@ export function sayHi(user) {
 }
 ```
 
-Here's how to import the default export along with a named one:
+اینجا نحوه import کردن export پیش فرض همراه با یک export نامگذاری شده را مشاهده می‌کنید:
 
 ```js
 // 📁 main.js
@@ -254,7 +254,7 @@ import {*!*default as User*/!*, sayHi} from './user.js';
 new User('John');
 ```
 
-And, finally, if importing everything `*` as an object, then the `default` property is exactly the default export:
+ و در نهایت، اگر همه چیز را به عنوان یک شیء با استفاده از `*` در برنامه import کنیم، آنگاه خاصیت `default` در شیء، همان export پیش فرض می‌باشد:
 
 ```js
 // 📁 main.js
@@ -264,28 +264,28 @@ let User = user.default; // the default export
 new User('John');
 ```
 
-### A word against default exports
+### کلمه ای در برابر export پیش فرض
 
-Named exports are explicit. They exactly name what they import, so we have that information from them; that's a good thing.
+باید دانست که export های نامگذاری شده صریح هستند. آنها دقیقا می‌گویند که چه چیزی را import می‌کنند، بنابراین از آنها این اطلاعات را داریم؛ این یک چیز خوب است.
 
-Named exports force us to use exactly the right name to import:
+همچنین export های نامگذاری شده ما را مجبور می‌کنند از دقیقاً همان نام درست برای import استفاده کنیم:
 
 ```js
 import {User} from './user.js';
-// import {MyUser} won't work, the name must be {User}
+// باشد {User} کار نمی‌کند، نام باید {MyUser} کردن import
 ```
 
-...While for a default export, we always choose the name when importing:
+در صورتی که برای export پیش فرض در هنگام import از یک نام انتخابی استفاده می‌کنیم.
 
 ```js
-import User from './user.js'; // works
-import MyUser from './user.js'; // works too
-// could be import Anything... and it'll still work
+import User from './user.js';   // کار می‌کند
+import MyUser from './user.js'; // این هم کار می‌کند
+// کند... و همچنان کار خواهد کرد import می‌تواند هر نامی را
 ```
 
-So team members may use different names to import the same thing, and that's not good.
+بنابراین اعضای تیم ممکن است برای import یک ماژول از نام های متفاوتی استفاده کنند و این خوب نیست.
 
-Usually, to avoid that and keep the code consistent, there's a rule that imported variables should correspond to file names, e.g:
+معمولاً، برای جلوگیری از این موضوع و حفظ یکنواختی کد، قاعده ای وجود دارد که متغیرهای import شده باید مطابق با نام فایل‌ها باشند، به عنوان مثال:
 
 ```js
 import User from './user.js';
@@ -294,13 +294,13 @@ import func from '/path/to/func.js';
 ...
 ```
 
-Still, some teams consider it a serious drawback of default exports. So they prefer to always use named exports. Even if only a single thing is exported, it's still exported under a name, without `default`.
+با این حال، برخی تیم‌ها این را یک نقطه ضعف جدی export پیش فرض می‌دانند. بنابراین ترجیح می‌دهند همیشه از import نامگذاری شده استفاده کنند. حتی اگر فقط یک چیز صادر شود، همچنان تحت یک نام export می‌شود، بدون `default`.
 
-That also makes re-export (see below) a little bit easier.
+این همچنین export مجدد (رجوع کنید به زیر) را اندکی آسان تر می‌کند.
 
-## Re-export
+## export مجدد
 
-"Re-export" syntax `export ... from ...` allows to import things and immediately export them (possibly under another name), like this:
+ساختار "export مجدد" `export ... from ...‎` این امکان را فراهم می‌سازد تا چیزها را import کنیم و بعد ازآن بتوانیم آن را export کنیم (احتمالا تحت نامی دیگر)، مانند:
 
 ```js
 export {sayHi} from './say.js'; // re-export sayHi
@@ -308,11 +308,11 @@ export {sayHi} from './say.js'; // re-export sayHi
 export {default as User} from './user.js'; // re-export default
 ```
 
-Why would that be needed? Let's see a practical use case.
+چرا این امر مورد نیاز است؟ بیایید یک کاربرد عملی ببینیم.
 
-Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow us to publish and distribute such packages, but we don't have to use them), and many modules are just "helpers", for internal use in other package modules.
+فرض کنید درحال نوشتن یک "پکیج" هستیم: یک پوشه با تعداد زیادی ماژول، که برخی از عملکردهای آن به بیرون export می‌شود (ابزارهایی مانند NPM به ما اجازه انتشار و توزیع چنین پکیج‌هایی را می‌دهد، اما اینجا نیازی به استفاده از آنها نیست) و ماژول‌های زیادی فقط "کمکی" هستند، برای استفاده داخلی در سایر ماژول‌های پکیج.
 
-The file structure could be like this:
+ساختار فایل ممکن است به این شکل باشد:
 ```
 auth/
     index.js
@@ -326,26 +326,26 @@ auth/
         ...
 ```
 
-We'd like to expose the package functionality via a single entry point.
+می‌خواهیم عملکرد پکیج را از طریق یک نقطه ورودی در معرض نمایش قرار دهیم.
 
-In other words, a person who would like to use our package, should import only from the "main file" `auth/index.js`.
+به عبارت دیگر، شخصی که می‌خواهد از پکیج ما استفاده کند، فقط باید "فایل اصلی" `auth/index.js` را import کند.
 
-Like this:
+مانند:
 
 ```js
 import {login, logout} from 'auth/index.js'
 ```
 
-The "main file", `auth/index.js` exports all the functionality that we'd like to provide in our package.
+"فایل اصلی"، `auth/index.js` ، همه عملکردهایی را که می‌خواهیم در پکیج خود ارائه دهیم export می‌کند.
 
-The idea is that outsiders, other programmers who use our package, should not meddle with its internal structure, search for files inside our package folder. We export only what's necessary in `auth/index.js` and keep the rest hidden from prying eyes.
+ایده این است که بیرونی‌ها ، برنامه نویسان دیگری که از پکیج ما استفاده می‌کنند ، نباید دخالتی در فایل ها و ساختار پکیج داشته باشند. ما ففط آنچه را که لازم است در `auth/index.js` پکیج خود export می‌کنیم و بقیه را از چشم های کنجکاو پنهان نگه می‌داریم.
 
-As the actual exported functionality is scattered among the package, we can import it into `auth/index.js` and export from it:
+از آنجایی که عملکرد export شده واقعا در سراسر پکیج پراکنده است، می‌توانیم آن را در `auth/index.js` که نقطه ارتباط پکیج با بیرون است import کنیم و سپس از آنجا export بگیریم:
 
 ```js
 // 📁 auth/index.js
 
-// import login/logout and immediately export them
+// شده export شده و سپس بلافاصله import ابتدا login/logout
 import {login, logout} from './helpers.js';
 export {login, logout};
 
@@ -355,9 +355,9 @@ export {User};
 ...
 ```
 
-Now users of our package can `import {login} from "auth/index.js"`.
+اکنون کاربران پکیج ما می‌توانند از `import {login} from "auth/index.js"‎` استفاده کنند.
 
-The syntax `export ... from ...` is just a shorter notation for such import-export:
+ساختار `export ... from ...‎` فقط یک نمایش مختصر از همین import/export است:
 
 ```js
 // 📁 auth/index.js
@@ -369,13 +369,13 @@ export {default as User} from './user.js';
 ...
 ```
 
-The notable difference of `export ... from` compared to `import/export` is that re-exported modules aren't available in the current file. So inside the above example of `auth/index.js` we can't use re-exported `login/logout` functions.
+تفاوت قابل توجه `export ... from‎` نسبت به `import/export` این است که در اولی ماژول ها در فایل جاری در دسترس نیستند، بنابر این در مثال بالا نمی‌توان از توابع `login/logout` در فایل `auth/index.js` استفاده کرد.
 
-### Re-exporting the default export
+### export مجدد export پیش فرض
 
-The default export needs separate handling when re-exporting.
+هنگام export مجدد، export پیش فرض (export default) نیاز به دستکاری جداگانه دارد.
 
-Let's say we have `user.js` with the `export default class User` and would like to re-export it:
+فرض کنید `user.js` با `export default class User` و می‌خواهیم آن را مجدد export کنیم:
 
 ```js
 // 📁 user.js
@@ -384,71 +384,71 @@ export default class User {
 }
 ```
 
-We can come across two problems with it:
+ممکن است با دو مشکل مواجه شویم:
 
-1. `export User from './user.js'` won't work. That would lead to a syntax error.
+1. عبارت `export User from './user.js'‎` کار نمی‌کند. این به خطای نحوی (سینتکس) منجر می‌شود.
 
-    To re-export the default export, we have to write `export {default as User}`, as in the example above.
+    برای export مجدد export پیش فرض، باید بنویسیم `export {default as User} from './user.js'‎`، مانند مثال بالا.
 
-2. `export * from './user.js'` re-exports only named exports, but ignores the default one.
+2. عبارت `export * from './user.js'‎` فقط export های نامگذاری شده را export مجدد می‌کند، اما export پیش فرض را نادیده می‌گیرد.
 
-    If we'd like to re-export both named and default exports, then two statements are needed:
+    اگر بخواهیم هم export نامگذاری شده و هم پیش فرض را export مجدد کنیم، آنگاه دو عبارت لازم است:
     ```js
     export * from './user.js'; // to re-export named exports
     export {default} from './user.js'; // to re-export the default export
     ```
 
-Such oddities of re-exporting a default export are one of the reasons why some developers don't like default exports and prefer named ones.
+چنین عجایبی از export مجددِ export پیش فرض یکی از دلایلی است که برخی توسعه دهندگان از export پیش فرض خوششان نمی‌آید و ترجیح می‌دهند از export نامگذاری شده استفاده کنند.
 
-## Summary
+## جمع بندی
 
-Here are all types of `export` that we covered in this and previous articles.
+در اینجا انواع `export` را که در این مقاله و مقالات قبلی پوشش داده‌ایم، مرور می‌کنیم.
 
-You can check yourself by reading them and recalling what they mean:
+می‌توانید خود را با خواندن آنها و به یاد آوردن معنایشان بررسی کنید:
 
-- Before declaration of a class/function/..:
-  - `export [default] class/function/variable ...`
-- Standalone export:
-  - `export {x [as y], ...}`.
-- Re-export:
-  - `export {x [as y], ...} from "module"`
-  - `export * from "module"` (doesn't re-export default).
-  - `export {default [as y]} from "module"` (re-export default).
+- export قبل از تعریف کلاس / تابع / ... :
+  - `export [default] class/function/variable ...‎`
+- export مستقل (standalone export):
+  - `export {x [as y], ...}‎`.
+- export مجدد (re-export):
+  - `export {x [as y], ...} from "module"‎`
+  - `export * from "module"‎` (doesn't re-export default).
+  - `export {default [as y]} from "module"‎` (re-export default).
 
 Import:
 
-- Importing named exports:
-  - `import {x [as y], ...} from "module"`
-- Importing the default export:
-  - `import x from "module"`
-  - `import {default as x} from "module"`
-- Import all:
-  - `import * as obj from "module"`
-- Import the module (its code runs), but do not assign any of its exports to variables:
-  - `import "module"`
+- import از export نامگذاری شده:
+  - `import {x [as y], ...} from "module"‎`
+- import از export پیش فرض:
+  - `import x from "module"‎`
+  - `import {default as x} from "module"‎`
+- import همه:
+  - `import * as obj from "module"‎`
+- import کردن ماژول (کد آن اجرا می‌شود)، اما هیچ یک از export های آن به متغیر خاصی اختصاص نمی‌یابد.
+  - `import "module"‎`
 
-We can put `import/export` statements at the top or at the bottom of a script, that doesn't matter.
+می‌تونیم عبارات `import/export` را در بالا یا پایین اسکریپت قرار دهیم، اهمیتی ندارد.
 
-So, technically this code is fine:
+بنابراین از نظر فنی این کد درست است:
 ```js
 sayHi();
 
 // ...
 
-import {sayHi} from './say.js'; // import at the end of the file
+import {sayHi} from './say.js'; // شده import در انتهای فایل
 ```
 
-In practice imports are usually at the start of the file, but that's only for more convenience.
+در عمل import ها معمولا در ابتدای فایل قرار دارند، اما این فقط برای راحتی بیشتر است.
 
-**Please note that import/export statements don't work if inside `{...}`.**
+**لطفاً توجه داشته باشید که عبارات import/export در داخل `{...}` کار نمی‌کنند.**
 
-A conditional import, like this, won't work:
+یک import شرطی مانند زیر، کار نمی‌کند:
 ```js
 if (something) {
   import {sayHi} from "./say.js"; // Error: import must be at top level
 }
 ```
 
-...But what if we really need to import something conditionally? Or at the right time? Like, load a module upon request, when it's really needed?
+اما اگر واقعاً نیاز به import شرطی داشتیم چه؟ مثلاً بارگذاری یک ماژول هنگامی که واقعاً لازم است؟ چه باید کرد؟
 
-We'll see dynamic imports in the next article.
+در مقاله بعدی import های پویا (dynamic imports) را خواهیم دید.