# Source: https://oxc.rs/docs/guide/usage/linter/rules/typescript/no-namespace.md

## Source: https://oxc.rs/docs/guide/usage/linter/rules/react/no-namespace.md

## Source: https://oxc.rs/docs/guide/usage/linter/rules/import/no-namespace.md

## What it does

Enforce a convention of not using namespaced (a.k.a. "wildcard" \*) imports.

## Why is this bad?

Namespaced imports, while sometimes used, are generally considered less ideal in modern JavaScript development for several reasons:

1. **Specificity and Namespace Pollution**:

* **Specificity**: Namespaced imports import the entire module, bringing in everything, even if you only need a few specific functions or classes. This can lead to potential naming conflicts if different modules have the same names for different functions.
* **Pollution**: Importing an entire namespace pollutes your current scope with potentially unnecessary functions and variables. It increases the chance of accidental use of an unintended function or variable, leading to harder-to-debug errors.

1. **Maintainability**:

* **Clarity**: Namespaced imports can make it harder to understand which specific functions or classes are being used in your code. This is especially true in larger projects with numerous imports.
* **Refactoring**: If a function or class name changes within the imported module, you might need to update several parts of your code if you are using namespaced imports. This becomes even more challenging when dealing with multiple namespaces.

1. **Modern Practice**:

* **Explicit Imports**: Modern JavaScript practices encourage explicit imports for specific components. This enhances code readability and maintainability.
* **Tree-Shaking**: Tools like Webpack and Rollup use tree-shaking to remove unused code from your bundles. Namespaced imports can prevent efficient tree-shaking, leading to larger bundle sizes.

## Examples

Examples of **incorrect** code for this rule:

```js
import * as user from "user-lib";

import some, * as user from "./user";
```

Examples of **correct** code for this rule:

```js
import { getUserName, isUser } from "user-lib";

import user from "user-lib";
import defaultExport, { isUser } from "./user";
```

## Configuration

This rule accepts a configuration object with the following properties:

## ignore

type: `string[]`

default: `[]`

An array of glob strings for modules that should be ignored by the rule.
For example, `["*.json"]` will ignore all JSON imports.

## How to use

To **enable** this rule using the config file or in the CLI, you can use:

::: code-group

```json [Config (.oxlintrc.json)]
{
  "plugins": ["import"],
  "rules": {
    "import/no-namespace": "error"
  }
}
```

```bash [CLI]
oxlint --deny import/no-namespace --import-plugin
```

:::

## References

* Rule Source