eslint-plugin-nextfriday 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2024 Next Friday Co., Ltd.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,179 @@
+# eslint-plugin-nextfriday
+
+A comprehensive ESLint plugin providing custom rules and configurations for Next Friday development workflows.
+
+## Installation
+
+```bash
+npm install --save-dev eslint-plugin-nextfriday
+# or
+yarn add --dev eslint-plugin-nextfriday
+# or
+pnpm add -D eslint-plugin-nextfriday
+```
+
+## Usage
+
+### Flat Config (ESLint 9+)
+
+#### Base Configuration (for pure JS/TS projects)
+
+```js
+import nextfriday from "eslint-plugin-nextfriday";
+
+export default [nextfriday.configs.base];
+// or use the recommended preset
+export default [nextfriday.configs["base/recommended"]];
+```
+
+#### React Configuration
+
+```js
+import nextfriday from "eslint-plugin-nextfriday";
+
+export default [nextfriday.configs.react];
+// or use the recommended preset
+export default [nextfriday.configs["react/recommended"]];
+```
+
+#### Next.js Configuration
+
+```js
+import nextfriday from "eslint-plugin-nextfriday";
+
+export default [nextfriday.configs.nextjs];
+// or use the recommended preset
+export default [nextfriday.configs["nextjs/recommended"]];
+```
+
+### Manual Configuration
+
+If you prefer to configure rules manually:
+
+```js
+import nextfriday from "eslint-plugin-nextfriday";
+
+export default [
+  {
+    plugins: {
+      nextfriday,
+    },
+    rules: {
+      // Base rules (suitable for all projects)
+      "nextfriday/no-emoji": "error",
+      "nextfriday/file-kebab-case": "error",
+      "nextfriday/md-filename-case-restriction": "error",
+      "nextfriday/prefer-destructuring-params": "error",
+      "nextfriday/no-explicit-return-type": "error",
+      "nextfriday/prefer-import-type": "error",
+      // JSX rule (only for React/Next.js projects)
+      "nextfriday/jsx-pascal-case": "error",
+    },
+  },
+];
+```
+
+### Legacy Config
+
+#### Base Configuration
+
+```js
+module.exports = {
+  plugins: ["nextfriday"],
+  extends: ["plugin:nextfriday/base"], // or "plugin:nextfriday/base/recommended"
+};
+```
+
+#### React Configuration
+
+```js
+module.exports = {
+  plugins: ["nextfriday"],
+  extends: ["plugin:nextfriday/react"], // or "plugin:nextfriday/react/recommended"
+};
+```
+
+#### Next.js Configuration
+
+```js
+module.exports = {
+  plugins: ["nextfriday"],
+  extends: ["plugin:nextfriday/nextjs"], // or "plugin:nextfriday/nextjs/recommended"
+};
+```
+
+## Rules
+
+| Rule                                                                       | Description                                                  | Fixable |
+| -------------------------------------------------------------------------- | ------------------------------------------------------------ | ------- |
+| [no-emoji](docs/rules/NO_EMOJI.md)                                         | Disallow emojis in code                                      | ❌      |
+| [file-kebab-case](docs/rules/FILE_KEBAB_CASE.md)                           | Enforce kebab-case filenames for .ts and .js files           | ❌      |
+| [jsx-pascal-case](docs/rules/JSX_PASCAL_CASE.md)                           | Enforce PascalCase filenames for .jsx and .tsx files         | ❌      |
+| [md-filename-case-restriction](docs/rules/MD_FILENAME_CASE_RESTRICTION.md) | Enforce SNAKE_CASE filenames for .md files                   | ❌      |
+| [prefer-destructuring-params](docs/rules/PREFER_DESTRUCTURING_PARAMS.md)   | Enforce destructuring for functions with multiple parameters | ❌      |
+| [no-explicit-return-type](docs/rules/NO_EXPLICIT_RETURN_TYPE.md)           | Disallow explicit return types on functions                  | ✅      |
+| [prefer-import-type](docs/rules/PREFER_IMPORT_TYPE.md)                     | Enforce using 'import type' for type-only imports            | ✅      |
+
+## Configurations
+
+### Base Configurations (for pure JS/TS projects)
+
+#### `base`
+
+Basic configuration without JSX-specific rules:
+
+- `nextfriday/no-emoji`: `"error"`
+- `nextfriday/file-kebab-case`: `"error"`
+- `nextfriday/md-filename-case-restriction`: `"error"`
+- `nextfriday/prefer-destructuring-params`: `"error"`
+- `nextfriday/no-explicit-return-type`: `"error"`
+- `nextfriday/prefer-import-type`: `"error"`
+
+#### `base/recommended`
+
+Same as `base` configuration (recommended preset for pure JS/TS projects).
+
+### React Configurations
+
+#### `react`
+
+Includes all base rules plus React-specific rules:
+
+- All base rules above
+- `nextfriday/jsx-pascal-case`: `"error"`
+
+#### `react/recommended`
+
+Same as `react` configuration (recommended preset for React projects).
+
+### Next.js Configurations
+
+#### `nextjs`
+
+Includes all rules suitable for Next.js projects:
+
+- All base rules
+- `nextfriday/jsx-pascal-case`: `"error"`
+
+#### `nextjs/recommended`
+
+Same as `nextjs` configuration (recommended preset for Next.js projects).
+
+## Features
+
+- **File naming enforcement**: Ensure consistent file naming conventions across your project
+- **Import optimization**: Automatically suggests better import patterns for TypeScript
+- **Code cleanup**: Helps remove unnecessary explicit type annotations
+- **React component conventions**: Enforces naming standards for JSX/TSX files
+- **Clean code practices**: Prevents emoji usage and enforces parameter destructuring
+
+## Need Help?
+
+If you encounter any issues or have questions:
+
+- Check the [rule documentation](docs/rules) for detailed examples
+- Report bugs or request features at: <https://github.com/next-friday/eslint-plugin-nextfriday/issues>
+
+## License
+
+MIT - feel free to use this plugin in your projects!

package/docs/rules/FILE_KEBAB_CASE.md

@@ -0,0 +1,75 @@
+# file-kebab-case
+
+Enforce kebab-case filenames for .ts and .js files.
+
+## Rule Details
+
+This rule enforces that all TypeScript (.ts) and JavaScript (.js) files use kebab-case naming convention for their **filenames**. Kebab-case uses lowercase letters and hyphens to separate words, making filenames more consistent and URL-friendly.
+
+**This rule checks the filename, not the code content.**
+
+## Examples
+
+**Incorrect** filenames for this rule:
+
+- `MyFile.ts` (PascalCase)
+- `camelCase.js` (camelCase)
+- `PascalCase.ts` (PascalCase)
+- `snake_case.js` (snake_case)
+- `UPPERCASE.ts` (UPPERCASE)
+- `My File.js` (contains spaces)
+
+**Correct** filenames for this rule:
+
+- `my-file.ts`
+- `kebab-case.js`
+- `single.ts`
+- `file-with-numbers-123.js`
+- `user-service.ts`
+- `api-utils.ts`
+
+## Code Examples
+
+The content of the file doesn't matter - only the filename is checked:
+
+```typescript
+// INCORRECT: File: MyFile.ts (incorrect filename)
+export const myFunction = () => {
+  return "Hello World";
+};
+```
+
+```typescript
+// CORRECT: File: my-file.ts (correct filename)
+export const myFunction = () => {
+  return "Hello World";
+};
+```
+
+```javascript
+// INCORRECT: File: UserService.js (incorrect filename)
+class UserService {
+  getUser() {
+    return {};
+  }
+}
+```
+
+```javascript
+// CORRECT: File: user-service.js (correct filename)
+class UserService {
+  getUser() {
+    return {};
+  }
+}
+```
+
+## When Not To Use It
+
+If your project has established naming conventions that conflict with kebab-case, or if you're working with frameworks that require specific filename patterns, you may want to disable this rule.
+
+## Notes
+
+- This rule only applies to `.ts` and `.js` files
+- Other file types (`.jsx`, `.tsx`, `.json`, etc.) are ignored
+- Single word filenames are considered valid kebab-case

package/docs/rules/JSX_PASCAL_CASE.md

@@ -0,0 +1,69 @@
+# jsx-pascal-case
+
+Enforce PascalCase filenames for .jsx and .tsx files.
+
+## Rule Details
+
+This rule enforces that JSX and TSX files use PascalCase naming convention for their **filenames**. This is a common pattern in React applications where components are typically named with PascalCase.
+
+**This rule checks the filename, not the code content.**
+
+## Examples
+
+**Incorrect** filenames for this rule:
+
+- `my-component.jsx` (kebab-case)
+- `userProfile.jsx` (camelCase)
+- `user_profile.tsx` (snake_case)
+- `component.jsx` (lowercase)
+- `MYCOMPONENT.tsx` (UPPERCASE)
+- `My Component.jsx` (contains spaces)
+- `My.Component.tsx` (contains dots)
+
+**Correct** filenames for this rule:
+
+- `MyComponent.jsx`
+- `UserProfile.tsx`
+- `App.jsx`
+- `LoginForm.tsx`
+- `UserProfile2.jsx` (PascalCase with numbers)
+
+## Code Examples
+
+The content of the file doesn't matter - only the filename is checked:
+
+```jsx
+// INCORRECT: File: my-component.jsx (incorrect filename)
+export default function MyComponent() {
+  return <div>Hello</div>;
+}
+```
+
+```jsx
+// CORRECT: File: MyComponent.jsx (correct filename)
+export default function MyComponent() {
+  return <div>Hello</div>;
+}
+```
+
+```tsx
+// INCORRECT: File: user-profile.tsx (incorrect filename)
+export default function UserProfile() {
+  return <div>Profile</div>;
+}
+```
+
+```tsx
+// CORRECT: File: UserProfile.tsx (correct filename)
+export default function UserProfile() {
+  return <div>Profile</div>;
+}
+```
+
+## When Not To Use
+
+If your project uses different naming conventions for JSX/TSX files, you can disable this rule.
+
+## Related Rules
+
+- [file-kebab-case](./FILE_KEBAB_CASE.md) - For regular TypeScript and JavaScript files

package/docs/rules/MD_FILENAME_CASE_RESTRICTION.md

@@ -0,0 +1,88 @@
+# md-filename-case-restriction
+
+Enforce SNAKE_CASE filenames for .md files.
+
+## Rule Details
+
+This rule enforces that all Markdown (.md) files use SNAKE_CASE naming convention for their **filenames**. SNAKE_CASE uses UPPERCASE letters and underscores to separate words. This helps maintain consistency for documentation files and ensures they stand out from regular code files.
+
+**This rule checks the filename, not the file content.**
+
+## Examples
+
+**Correct** filenames for this rule:
+
+- `README.md` (SNAKE_CASE)
+- `CHANGELOG.md` (SNAKE_CASE)
+- `CONTRIBUTING.md` (SNAKE_CASE)
+- `LICENSE.md` (SNAKE_CASE)
+- `USER_GUIDE.md` (SNAKE_CASE)
+- `INSTALLATION_GUIDE.md` (SNAKE_CASE)
+- `TROUBLESHOOTING_GUIDE.md` (SNAKE_CASE)
+- `GUIDE_2024.md` (SNAKE_CASE with numbers)
+- `LICENSE_MIT.md` (SNAKE_CASE with underscores)
+
+**Incorrect** filenames for this rule:
+
+- `readme.md` (lowercase)
+- `user-guide.md` (kebab-case)
+- `userGuide.md` (camelCase)
+- `UserGuide.md` (PascalCase)
+- `myREADME.md` (mixed case)
+- `User guide.md` (contains spaces)
+
+## Code Examples
+
+The content of the file doesn't matter - only the filename is checked:
+
+```markdown
+<!-- INCORRECT: File: readme.md (incorrect filename) -->
+
+# My Project
+
+This is a sample project.
+```
+
+```markdown
+<!-- CORRECT: File: README.md (correct filename) -->
+
+# My Project
+
+This is a sample project.
+```
+
+```markdown
+<!-- INCORRECT: File: user-guide.md (incorrect filename) -->
+
+# User Guide
+
+Follow these steps to get started.
+```
+
+```markdown
+<!-- CORRECT: File: USER_GUIDE.md (correct filename) -->
+
+# User Guide
+
+Follow these steps to get started.
+```
+
+## Valid Patterns
+
+### SNAKE_CASE
+
+- All letters are UPPERCASE
+- Uses underscores to separate words
+- May contain numbers
+- Examples: `README.md`, `USER_GUIDE.md`, `GUIDE_2024.md`, `LICENSE_MIT.md`
+
+## When Not To Use It
+
+If your project has established naming conventions for documentation that conflict with this rule, or if you need to maintain compatibility with external tools that expect specific markdown filename patterns, you may want to disable this rule.
+
+## Notes
+
+- This rule only applies to `.md` files
+- Other file types are ignored
+- Single word filenames must be UPPERCASE (e.g., `README.md`, `LICENSE.md`)
+- Underscores are used to separate words in multi-word filenames

package/docs/rules/NO_EMOJI.md

@@ -0,0 +1,31 @@
+# no-emoji
+
+Disallow emoji characters in source code.
+
+## Rule Details
+
+This rule prevents the use of emoji characters in JavaScript and TypeScript source code. Emoji characters can cause encoding issues, make code harder to read on certain systems, and may not be supported in all environments.
+
+## Examples
+
+**Incorrect** code for this rule:
+
+```js
+const message = "Hello 🌍 world";
+const greeting = "Hi there! 👋";
+// Comment with emoji 😀
+const celebration = "🎉 Party time! 🎊";
+```
+
+**Correct** code for this rule:
+
+```js
+const message = "Hello world";
+const greeting = "Hi there!";
+// Comment without emoji
+const celebration = "Party time!";
+```
+
+## When Not To Use It
+
+If your team explicitly wants to allow emoji characters in source code and has no concerns about encoding or compatibility issues, you can disable this rule.

package/docs/rules/NO_EXPLICIT_RETURN_TYPE.md

@@ -0,0 +1,71 @@
+# no-explicit-return-type
+
+Disallow explicit return types on functions.
+
+This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+## Rule Details
+
+This rule encourages relying on TypeScript's type inference instead of explicitly annotating function return types. TypeScript is generally very good at inferring return types, and explicit annotations can add unnecessary verbosity to your code.
+
+**Incorrect** code for this rule:
+
+```typescript
+function getName(): string {
+  return "John Doe";
+}
+
+const getAge = (): number => {
+  return 25;
+};
+
+function processUser(): void {
+  console.log("Processing user");
+}
+
+const calculateTotal = (items: Item[]): number => {
+  return items.reduce((sum, item) => sum + item.price, 0);
+};
+```
+
+**Correct** code for this rule:
+
+```typescript
+function getName() {
+  return "John Doe"; // TypeScript infers: string
+}
+
+const getAge = () => {
+  return 25; // TypeScript infers: number
+};
+
+function processUser() {
+  console.log("Processing user"); // TypeScript infers: void
+}
+
+const calculateTotal = (items: Item[]) => {
+  return items.reduce((sum, item) => sum + item.price, 0); // TypeScript infers: number
+};
+```
+
+## Benefits
+
+- **Cleaner code**: Reduces visual clutter
+- **Automatic updates**: When implementation changes, return type updates automatically
+- **Trust TypeScript**: Leverages TypeScript's excellent type inference
+- **Consistency**: Encourages a consistent style across the codebase
+
+## When Not To Use
+
+- When you want to explicitly document the return type for API functions
+- For public library functions where return types serve as documentation
+- When the inferred type is too broad and you want to narrow it
+- In cases where explicit return types improve error messages
+
+## Auto-fixing
+
+This rule automatically removes explicit return type annotations when run with the `--fix` option.
+
+## Related Rules
+
+- No related rules

package/docs/rules/PREFER_DESTRUCTURING_PARAMS.md

@@ -0,0 +1,63 @@
+# prefer-destructuring-params
+
+Enforce destructuring for functions with multiple parameters.
+
+## Rule Details
+
+This rule enforces the use of object destructuring for functions that have multiple parameters. This improves code readability and makes it easier to understand what parameters a function expects.
+
+**Incorrect** code for this rule:
+
+```javascript
+function createUser(name, email, age, address) {
+  // ...
+}
+
+const processOrder = (orderId, customerId, items, total) => {
+  // ...
+};
+```
+
+**Correct** code for this rule:
+
+```javascript
+function createUser({ name, email, age, address }) {
+  // ...
+}
+
+const processOrder = ({ orderId, customerId, items, total }) => {
+  // ...
+};
+
+// Single parameter functions are allowed
+function getName(user) {
+  return user.name;
+}
+
+// Functions with no parameters are allowed
+function getCurrentTime() {
+  return new Date();
+}
+
+// Functions with already destructured parameters are allowed
+function updateUser({ name, email }, additionalData) {
+  // ...
+}
+```
+
+## Benefits
+
+- **Improved readability**: It's clear what properties are expected
+- **Better maintainability**: Adding or removing parameters is easier
+- **Self-documenting code**: Parameter names are explicit at the call site
+- **TypeScript benefits**: Better type inference and autocompletion
+
+## When Not To Use
+
+- If your project prefers traditional parameter lists
+- For performance-critical functions where destructuring overhead matters
+- When dealing with legacy code that can't be easily refactored
+
+## Related Rules
+
+- No related rules

package/docs/rules/PREFER_IMPORT_TYPE.md

@@ -0,0 +1,85 @@
+# prefer-import-type
+
+Enforce using 'import type' for type-only imports.
+
+This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+## Rule Details
+
+This rule enforces the use of TypeScript's `import type` syntax for imports that are only used for type annotations. This helps with tree-shaking and makes it clear which imports are type-only vs runtime imports.
+
+**Incorrect** code for this rule:
+
+```typescript
+import { Component } from "react";
+import { TSESTree } from "@typescript-eslint/utils";
+import { RuleContext } from "@typescript-eslint/utils";
+
+interface Props {
+  component: Component;
+  tree: TSESTree.Node;
+  context: RuleContext<string, unknown[]>;
+}
+```
+
+**Correct** code for this rule:
+
+```typescript
+import type { Component } from "react";
+import type { TSESTree } from "@typescript-eslint/utils";
+import type { RuleContext } from "@typescript-eslint/utils";
+
+interface Props {
+  component: Component;
+  tree: TSESTree.Node;
+  context: RuleContext<string, unknown[]>;
+}
+```
+
+**Allowed runtime imports:**
+
+```typescript
+import React from "react";
+import { ESLintUtils } from "@typescript-eslint/utils";
+import * as utils from "./utils";
+
+// Mixed imports are also supported
+import { ESLintUtils, type TSESTree } from "@typescript-eslint/utils";
+```
+
+## Benefits
+
+- **Better tree-shaking**: Type-only imports are completely removed from the bundle
+- **Clearer intent**: Makes it obvious which imports are for types vs runtime
+- **Faster compilation**: TypeScript can optimize type-only imports
+- **Bundle size**: Reduces final JavaScript bundle size
+
+## Detection Logic
+
+The rule identifies type-only imports by checking if:
+
+1. The imported identifier starts with an uppercase letter (indicating a type/interface)
+2. It's not a known runtime import like `ESLintUtils` or `RuleTester`
+3. The import is not already using `import type`
+
+## Auto-fixing
+
+This rule automatically converts regular imports to `import type` when appropriate:
+
+```typescript
+// Before
+import { TSESTree } from "@typescript-eslint/utils";
+
+// After (auto-fixed)
+import type { TSESTree } from "@typescript-eslint/utils";
+```
+
+## When Not To Use
+
+- If your project doesn't use TypeScript
+- When you prefer to keep all imports as regular imports for consistency
+- If you have specific bundling requirements that don't benefit from type-only imports
+
+## Related Rules
+
+- [@typescript-eslint/consistent-type-imports](https://typescript-eslint.io/rules/consistent-type-imports/) - Similar rule from typescript-eslint