diff --git a/crates/oxc_linter/src/rules/import/extensions.rs b/crates/oxc_linter/src/rules/import/extensions.rs
index afa7bfa0da103..cda3bc00fc46f 100644
--- a/crates/oxc_linter/src/rules/import/extensions.rs
+++ b/crates/oxc_linter/src/rules/import/extensions.rs
@@ -391,7 +391,16 @@ declare_oxc_lint!(
     ///
     /// ### Why is this bad?
     ///
-    /// ESM-based file resolve algorithms (e.g., the one that Vite provides) recommend specifying the file extension to improve performance.
+    /// ESM-based file resolve algorithms (e.g., the one that Vite provides) recommend
+    /// specifying the file extension to improve performance. Without extensions, the
+    /// bundler must check for various possible file extensions, which can slow down
+    /// the build process on large projects. In addition, common ESM environments
+    /// (such as browsers and Node.js) typically require fully specified relative imports,
+    /// which means extensionless imports are not supported there.
+    ///
+    /// For personal preference and compatibility reasons, the rule also allows configuration
+    /// to _disallow_ extensions in imports. This is generally not recommended, but it can be
+    /// done if preferred.
     ///
     /// ### Examples
     ///
@@ -438,13 +447,28 @@ declare_oxc_lint!(
     /// ```js
     /// // Configuration: { "vue": "always", "ts": "never" }
     /// import Component from './Component.vue'; // ✓ OK - .vue configured as "always"
-    /// import utils from './utils';              // ✓ OK - .ts configured as "never"
-    /// import styles from './styles.css';        // ✓ OK - .css not configured, ignored
+    /// import utils from './utils';             // ✓ OK - .ts configured as "never"
+    /// import styles from './styles.css';       // ✓ OK - .css not configured, ignored
     ///
     /// // Configuration: ["ignorePackages", { "js": "never", "ts": "never" }]
     /// import foo from './foo';                  // ✓ OK - no extension
     /// import bar from 'lodash/fp';              // ✓ OK - package import, ignored (ignorePackages sets this to true)
     /// ```
+    ///
+    /// ### Differences compared to `eslint-plugin-import`
+    ///
+    /// If you see differences between this rule implementation and the original `eslint-plugin-import`
+    /// rule, please note that there are some intentional, inherent differences in the behavior of this
+    /// rule and the original.
+    ///
+    /// Oxlint understands and can resolve TypeScript paths out-of-the-box. If your ESLint
+    /// configuration did not include `eslint-import-resolver-typescript` or similar, then the original
+    /// rule will not have been able to resolve TypeScript paths correctly, and so the behavior
+    /// between ESLint and Oxlint may differ. Generally, this means that Oxlint will catch _more_
+    /// valid violations than the original rule, though this depends on the specific configuration.
+    ///
+    /// Oxlint is also able to resolve multiple `tsconfig.json` files in a single repo, and so in a
+    /// monorepo setup will be more capable with regards to resolving file paths.
     Extensions,
     import,
     restriction,
diff --git a/crates/oxc_linter/src/rules/import/no_named_as_default.rs b/crates/oxc_linter/src/rules/import/no_named_as_default.rs
index 5ef579a75ad5f..e87593ab52c09 100644
--- a/crates/oxc_linter/src/rules/import/no_named_as_default.rs
+++ b/crates/oxc_linter/src/rules/import/no_named_as_default.rs
@@ -42,7 +42,7 @@ declare_oxc_lint!(
     /// ```javascript
     /// // foo.js
     /// export default 'foo';
-    /// export const bar = 'baz';
+    /// export const bar = true;
     /// ```
     ///
     /// Examples of **incorrect** code for this rule:
@@ -56,6 +56,16 @@ declare_oxc_lint!(
     /// // Valid: correctly importing default export with a non-conflicting name.
     /// import foo from './foo.js';
     /// ```
+    ///
+    /// ### Differences compared to `eslint-plugin-import`
+    ///
+    /// If you see differences between this rule implementation and the original `eslint-plugin-import`
+    /// rule, please note that the behavior may differ in certain cases due to differences in how
+    /// module resolution is implemented and configured.
+    ///
+    /// For example, the original rule may require additional resolver configuration to handle certain
+    /// imports, especially when TypeScript paths are used or in monorepo setups with multiple
+    /// `tsconfig.json` files.
     NoNamedAsDefault,
     import,
     suspicious