diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml index bffde53..ffe8879 100644 --- a/.github/FUNDING.yml +++ b/.github/FUNDING.yml @@ -1,5 +1,4 @@ # https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository github: D3strukt0r patreon: d3strukt0r -open_collective: d3strukt0r buy_me_a_coffee: d3strukt0r diff --git a/.github/ISSUE_TEMPLATE/1-bug-report.yml b/.github/ISSUE_TEMPLATE/1-bug-report.yml deleted file mode 100644 index 5c232b4..0000000 --- a/.github/ISSUE_TEMPLATE/1-bug-report.yml +++ /dev/null @@ -1,50 +0,0 @@ -name: Bug report 🐛 -description: Existing feature does not behave as expected. -labels: [kind/bug, status/to verify] -body: - - type: markdown - attributes: - value: | - Before reporting a bug, make sure you are up-to-date and the problem is/was not reported already. - - type: textarea - id: problem-description - attributes: - label: Problem description - description: - Please describe encountered problem and provide the background of it - maybe including contextual information and images. - validations: - required: true - - type: textarea - id: to-reproduce - attributes: - label: To reproduce - description: | - Steps to reproduce the behavior: - - 1. Go to '...' - 2. Click on '....' - 3. Scroll down to '....' - 4. See error - - Please use markdown syntax for each code snippet. - validations: - required: true - - type: input - id: version - attributes: - label: Version - description: Provide the action version in X.Y.Z format - validations: - required: true - - type: checkboxes - id: terms - attributes: - label: Contribution Checks - options: - - label: I have verified if this problem was already reported - required: false - - label: - I am familiar with ["Feature or - bug?"](https://github.com/iwf-web/eslint-coding-standard/blob/master/.github/feature-or-bug.md) - required: false diff --git a/.github/ISSUE_TEMPLATE/2-feature-request.yml b/.github/ISSUE_TEMPLATE/2-feature-request.yml deleted file mode 100644 index 6f72411..0000000 --- a/.github/ISSUE_TEMPLATE/2-feature-request.yml +++ /dev/null @@ -1,41 +0,0 @@ -name: Feature request 🚀 -description: - I have a suggestion about a new feature (and may want to implement it)! -labels: [kind/feature request, status/to verify] -body: - - type: markdown - attributes: - value: | - Before requesting a new feature, make sure your version is up-to-date. - - > [!IMPORTANT] - > For initial ideas it's preferable to use [discussions](https://github.com/iwf-web/eslint-coding-standard/discussions). - - As a maintainers we prefer to have only actionable issues in the backlog, with clear definition of done, - that's why Discussions are the best way to start. When scope of the request is established, then actual issue can be created. - - type: textarea - id: feature-request - attributes: - label: Feature request - description: - Please describe the feature you would like to see implemented. - validations: - required: true - - type: input - id: discussion-reference - attributes: - label: Link to Discussion where feature request was formed - placeholder: https://github.com/iwf-web/eslint-coding-standard/discussions/ - validations: - required: false - - type: checkboxes - id: terms - attributes: - label: Contribution Checks - options: - - label: I have verified if this feature request was already discussed - required: false - - label: - I am familiar with ["Feature or - bug?"](https://github.com/iwf-web/eslint-coding-standard/blob/master/.github/feature-or-bug.md) - required: false diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml deleted file mode 100644 index f43ea22..0000000 --- a/.github/ISSUE_TEMPLATE/config.yml +++ /dev/null @@ -1,5 +0,0 @@ -blank_issues_enabled: false -contact_links: - - name: Community Support - url: https://github.com/iwf-web/eslint-coding-standard/discussions - about: Please ask and answer questions here. diff --git a/.github/PULL_REQUEST_TEMPLATE/default.md b/.github/PULL_REQUEST_TEMPLATE/default.md deleted file mode 100644 index e69de29..0000000 diff --git a/.github/feature-or-bug.md b/.github/feature-or-bug.md deleted file mode 100644 index 996c311..0000000 --- a/.github/feature-or-bug.md +++ /dev/null @@ -1,25 +0,0 @@ -# Is it a feature or a bug ? - -Sometimes it's a bit tricky to define if given change proposal or change request -is adding new feature or fixing existing issue. This document is providing more -clarity about categorisation we use. - -## Bug - -Example of bugs: - -- crash during application or rule execution -- wrong changes are applied during "fixing codebase" process -- issue with generated report - -## Feature - -Example of features: - -- introduction of new rule -- enhancement of existing rule to cover more cases (for example adding support - for newly introduced PHP syntax) -- introduction of new ruleset -- update of existing ruleset (for example adjusting it to match newest style of - given community or adding newly implemented rule that was supposed to be - followed by style of given community, yet not implemented as a rule before) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 361ca26..59dfa68 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -2,9 +2,9 @@ name: CI on: push: - branches: [main] + branches: [main, develop] pull_request: - branches: [main] + branches: [main, develop] permissions: contents: read @@ -22,7 +22,7 @@ jobs: node-version: 24.x - name: Install pnpm - uses: pnpm/action-setup@v4 + uses: pnpm/action-setup@v5 - name: Get pnpm cache directory path id: pnpm-cache-dir-path diff --git a/.github/workflows/label.yml b/.github/workflows/label.yml index 239c1a8..af0ebd0 100644 --- a/.github/workflows/label.yml +++ b/.github/workflows/label.yml @@ -2,14 +2,15 @@ name: Labeler on: [pull_request] +permissions: + contents: read + pull-requests: write # Adding Existing Labels + issues: write # Creating New Labels + jobs: label: name: Label PR runs-on: ubuntu-latest - permissions: - contents: read - pull-requests: write # Adding Existing Labels - issues: write # Creating New Labels steps: - name: Label PR uses: actions/labeler@v6 diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 8e21a80..bbe977a 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -5,14 +5,13 @@ on: branches: - main -permissions: - contents: write - issues: write - pull-requests: write - jobs: release-please: runs-on: ubuntu-latest + permissions: + contents: write + issues: write + pull-requests: write outputs: release_created: ${{ steps.release.outputs.release_created }} steps: @@ -39,7 +38,7 @@ jobs: registry-url: https://registry.npmjs.org - name: Install pnpm - uses: pnpm/action-setup@v4 + uses: pnpm/action-setup@v5 - name: Get pnpm cache directory path id: pnpm-cache-dir-path diff --git a/ACKNOWLEDGMENTS.md b/ACKNOWLEDGMENTS.md deleted file mode 100644 index f059265..0000000 --- a/ACKNOWLEDGMENTS.md +++ /dev/null @@ -1,5 +0,0 @@ -# Acknowledgments - -This project uses code from the following libraries: - -- None yet diff --git a/AUTHORS.md b/AUTHORS.md deleted file mode 100644 index 10da331..0000000 --- a/AUTHORS.md +++ /dev/null @@ -1,5 +0,0 @@ -# Project Authors - -## Developers - -* **Manuele** - [D3strukt0r](https://github.com/D3strukt0r) diff --git a/CLAUDE.md b/CLAUDE.md index 2dc9b6e..0c94fb1 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -25,8 +25,8 @@ Note: Tests are not yet implemented. The package exports two configs from separate entry points: -- **`iwfStandardTs`** (`src/standard-ts.ts`) — Full config with TypeScript strict checking, React, and all style rules. Imports and extends the JS config. -- **`iwfStandardJs`** (`src/standard-js.ts`) — Base config with React and style rules, without TypeScript. +- **`iwfWebStandardTs`** (`src/standard-ts.ts`) — Full config with TypeScript strict checking, React, and all style rules. Imports and extends the JS config. +- **`iwfWebStandardJs`** (`src/standard-js.ts`) — Base config with React and style rules, without TypeScript. - **`src/index.ts`** — Barrel re-export of both configs. `standard-js.ts` also exports `baseOptions` and `baseRules` constants, which `standard-ts.ts` imports to extend with TS-specific rules. @@ -35,15 +35,15 @@ The package exports two configs from separate entry points: ```typescript // TypeScript project -import { iwfStandardTs } from '@iwf-web/eslint-coding-standard'; -export default iwfStandardTs(); +import { iwfWebStandardTs } from '@iwf-web/eslint-coding-standard'; +export default iwfWebStandardTs(); // JavaScript-only project -import { iwfStandardJs } from '@iwf-web/eslint-coding-standard'; -export default iwfStandardJs(); +import { iwfWebStandardJs } from '@iwf-web/eslint-coding-standard'; +export default iwfWebStandardJs(); // Subpath imports also available -import { iwfStandardTs } from '@iwf-web/eslint-coding-standard/standard-ts'; +import { iwfWebStandardTs } from '@iwf-web/eslint-coding-standard/standard-ts'; ``` Both functions accept `(options?, ...userConfigs)` — options override `antfu()` defaults, userConfigs are additional ESLint flat config objects appended after the IWF rules. diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index 5ad6a16..0000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,83 +0,0 @@ -# Contributor Covenant Code of Conduct - -## Our Pledge - -We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. - -We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. - -## Our Standards - -Examples of behavior that contributes to a positive environment for our community include: - -* Demonstrating empathy and kindness toward other people -* Being respectful of differing opinions, viewpoints, and experiences -* Giving and gracefully accepting constructive feedback -* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience -* Focusing on what is best not just for us as individuals, but for the overall community - -Examples of unacceptable behavior include: - -* The use of sexualized language or imagery, and sexual attention or advances of any kind -* Trolling, insulting or derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or email address, without their explicit permission -* Other conduct which could reasonably be considered inappropriate in a professional setting - -## Enforcement Responsibilities - -Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. - -Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. - -## Scope - -This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [web-solutions@iwf.ch]. All complaints will be reviewed and investigated promptly and fairly. - -All community leaders are obligated to respect the privacy and security of the reporter of any incident. - -## Enforcement Guidelines - -Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: - -### 1. Correction - -**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. - -**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. - -### 2. Warning - -**Community Impact**: A violation through a single incident or series of actions. - -**Consequence**: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. - -### 3. Temporary Ban - -**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior. - -**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. - -### 4. Permanent Ban - -**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. - -**Consequence**: A permanent ban from any sort of public interaction within the community. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at [https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. - -Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder][Mozilla CoC]. - -For answers to common questions about this code of conduct, see the FAQ at [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at [https://www.contributor-covenant.org/translations][translations]. - -[homepage]: https://www.contributor-covenant.org -[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html -[Mozilla CoC]: https://github.com/mozilla/diversity -[FAQ]: https://www.contributor-covenant.org/faq -[translations]: https://www.contributor-covenant.org/translations diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md deleted file mode 100644 index e954fc8..0000000 --- a/CONTRIBUTING.md +++ /dev/null @@ -1,114 +0,0 @@ -# Contributing - -Please note we have a [code of conduct](CODE_OF_CONDUCT.md), please follow it in all your interactions with the project. - -## Submitting bugs - -### Due diligence - -Before submitting a bug, please do the following: - -* Perform basic troubleshooting steps: - - * Make sure you’re on the latest version. If you’re not on the most recent version, your problem may have been solved already! Upgrading is always the best first step. - * Try older versions. If you’re already on the latest release, try rolling back a few minor versions (e.g. if on 1.7, try 1.5 or 1.6) and see if the problem goes away. This will help the devs narrow down when the problem first arose in the commit log. - * Try switching up dependency versions. If the software in question has dependencies (other libraries, etc) try upgrading/downgrading those as well. - -* Search the project’s bug/issue tracker to make sure it’s not a known issue. -* If you don’t find a pre-existing issue, consider checking with the mailing list and/or IRC channel in case the problem is non-bug-related. - -### What to put in your bug report - -Make sure your report gets the attention it deserves: bug reports with missing information may be ignored or punted back to you, delaying a fix. The below constitutes a bare minimum; more info is almost always better: - -* What version of the core programming language interpreter/compiler are you using? For example, if it’s a Python project, are you using Python 2.7.3? Python 3.3.1? PyPy 2.0? -* What operating system are you on? Windows? (Vista? 7? 32-bit? 64-bit?) Mac OS X? (10.7.4? 10.9.0?) Linux? (Which distro? Which version of that distro? 32 or 64 bits?) Again, more detail is better. -* Which version or versions of the software are you using? Ideally, you followed the advice above and have ruled out (or verified that the problem exists in) a few different versions. -* How can the developers recreate the bug on their end? If possible, include a copy of your code, the command you used to invoke it, and the full output of your run (if applicable.) - - * A common tactic is to pare down your code until a simple (but still bug-causing) “base case” remains. Not only can this help you identify problems which aren’t real bugs, but it means the developer can get to fixing the bug faster. - -## Contributing changes - -### Licensing of contributed material - -Keep in mind as you contribute, that code, docs and other material submitted to open source projects are usually considered licensed under the same terms as the rest of the work. - -The details vary from project to project, but from the perspective of this document’s authors: - -* Anything submitted to a project falls under the licensing terms in the repository’s top level [LICENSE.txt](LICENSE.txt) file. - - * For example, if a project’s LICENSE is BSD-based, contributors should be comfortable with their work potentially being distributed in binary form without the original source code. - -* Per-file copyright/license headers are typically extraneous and undesirable. Please don’t add your own copyright headers to new files unless the project’s license actually requires them! - - * Not least because even a new file created by one individual (who often feels compelled to put their personal copyright notice at the top) will inherently end up contributed to by dozens of others over time, making a per-file header outdated/misleading. - -### Version control branching - -* Always make a new branch for your work, no matter how small. This makes it easy for others to take just that one set of changes from your repository, in case you have multiple unrelated changes floating around. - - * A corollary: don’t submit unrelated changes in the same branch/pull request! The maintainer shouldn’t have to reject your awesome bugfix because the feature you put in with it needs more review. - -* Base your new branch off of the appropriate branch on the main repository (`develop`): - - * Bug fixes should be based on the branch named after the oldest supported release line the bug affects. - - * E.g. if a feature was introduced in 1.1, the latest release line is 1.3, and a bug is found in that feature - make your branch based on 1.1. The maintainer will then forward-port it to 1.3 and master. - * Bug fixes requiring large changes to the code or which have a chance of being otherwise disruptive, may need to base off of master instead. This is a judgement call – ask the devs! - * New features should branch off of the `develop` branch. - - * Note that depending on how long it takes for the dev team to merge your patch, the copy of `develop` you worked off of may get out of date! If you find yourself ‘bumping’ a pull request that’s been sidelined for a while, make sure you rebase or merge to latest `develop` to ensure a speedier resolution. - -### Code formatting - -* Follow the style you see used in the primary repository! Consistency with the rest of the project always trumps other considerations. It doesn’t matter if you have your own style or if the rest of the code breaks with the greater community - just follow along. -* Python projects usually follow the PEP-8 guidelines (though many have minor deviations depending on the lead maintainers’ preferences.) - -### Documentation isn’t optional - -It’s not! Patches without documentation will be returned to sender. By “documentation” we mean: - -* Docstrings (for Python; or API-doc-friendly comments for other languages) must be created or updated for public API functions/methods/etc. (This step is optional for some bugfixes.) - - * Don’t forget to include versionadded/versionchanged ReST directives at the bottom of any new or changed Python docstrings! - - * Use versionadded for truly new API members – new methods, functions, classes or modules. - * Use versionchanged when adding/removing new function/method arguments, or whenever behavior changes. - -* New features should ideally include updates to prose documentation, including useful example code snippets. -* All submissions should have a changelog entry crediting the contributor and/or any individuals instrumental in identifying the problem. - -### Tests aren’t optional - -Any bugfix that doesn’t include a test proving the existence of the bug being fixed, may be suspect. Ditto for new features that can’t prove they actually work. - -We’ve found that test-first development really helps make features better architected and identifies potential edge cases earlier instead of later. Writing tests before the implementation is strongly encouraged. - -### Full example - -Here’s an example workflow for a project `theproject` hosted on GitHub, which is currently in version 1.3.x. Your username is `yourname` and you’re submitting a basic bugfix. - -#### Preparing your Fork - -* Click ‘Fork’ on GitHub, creating e.g. `yourname/theproject`. -* Clone your project: `git clone git@github.com:yourname/theproject`. -* `cd theproject` -* Create and activate a virtual environment. -* Install the development requirements: `pip install -r dev-requirements.txt`. -* Create a branch: `git checkout -b foo-the-bars 1.3.` - -#### Making your Changes - -* Add changelog entry crediting yourself. -* Write tests expecting the correct/fixed functionality; make sure they fail. -* Hack, hack, hack. -* Run tests again, making sure they pass. -* Commit your changes: `git commit -m "Foo the bars"` - -#### Creating Pull Requests - -* Push your commit to get it back up to your fork: `git push origin HEAD` -* Visit GitHub, click handy “Pull request” button that it will make upon noticing your new branch. -* In the description field, write down issue number (if submitting code fixing an existing issue) or describe the issue + your fix (if submitting a wholly new bugfix). -* Hit ‘submit’! And please be patient - the maintainers will get to you when they can. diff --git a/CONTRIBUTORS.md b/CONTRIBUTORS.md deleted file mode 100644 index b2354f6..0000000 --- a/CONTRIBUTORS.md +++ /dev/null @@ -1,17 +0,0 @@ -# Contributors - -## Special thanks for all the people who had helped this project so far - -- **Manuele** - [D3strukt0r](https://github.com/D3strukt0r) - -See also the full list of [contributors](https://github.com/iwf-web/eslint-coding-standard/contributors) who participated in this project. - -## I would like to join this list. How can I help the project? - -We're currently looking for contributions for the following: - -- [ ] Bug fixes -- [ ] Translations -- [ ] etc... - -For more information, please refer to our [CONTRIBUTING](CONTRIBUTING.md) guide. diff --git a/README.md b/README.md index 1a1bb58..20f5483 100644 --- a/README.md +++ b/README.md @@ -10,14 +10,15 @@ A standardized ESLint configuration package for IWF projects. Built on top of [@ The package provides two configs: -- **Standard TypeScript** (`iwfStandardTs`) — Full config with TypeScript strict checking, React, and all style rules. Use this for TypeScript projects. -- **Standard JavaScript** (`iwfStandardJs`) — Base config with React and style rules, without TypeScript. Use this for JS-only projects. +- **Standard TypeScript** (`iwfWebStandardTs`) — Full config with TypeScript strict checking, React, and all style rules. Use this for TypeScript projects. +- **Standard JavaScript** (`iwfWebStandardJs`) — Base config with React and style rules, without TypeScript. Use this for JS-only projects. The TypeScript config extends the JavaScript one, so all JS/React rules are included automatically. Both configs build on `@antfu/eslint-config` with the following customizations: ### Code Style + - **Semicolons**: Required at statement ends - **Curly braces**: Required for all control statements - **Arrow functions**: Parentheses around single parameters @@ -26,16 +27,19 @@ Both configs build on `@antfu/eslint-config` with the following customizations: - **Quote style**: Single quotes, with object properties quoted only when required ### TypeScript + - Strict type checking enabled with project-based tsconfig detection - Allows promises in event handlers (e.g., `onClick`) - Relaxed `any` type restrictions for third-party library interoperability ### React + - Full React support with hooks linting - Allows common child manipulation patterns (`cloneElement`, `children.map`, etc.) - Const declarations allowed for components ### Disabled Features + - JSONC, YAML, and Markdown linting disabled ## Getting Started @@ -64,17 +68,17 @@ Create an `eslint.config.js` (or `eslint.config.ts`) file in your project root: #### TypeScript projects ```js -import { iwfStandardTs } from '@iwf-web/eslint-coding-standard'; +import { iwfWebStandardTs } from '@iwf-web/eslint-coding-standard'; -export default iwfStandardTs(); +export default iwfWebStandardTs(); ``` #### JavaScript-only projects ```js -import { iwfStandardJs } from '@iwf-web/eslint-coding-standard'; +import { iwfWebStandardJs } from '@iwf-web/eslint-coding-standard'; -export default iwfStandardJs(); +export default iwfWebStandardJs(); ``` #### Subpath imports @@ -82,8 +86,8 @@ export default iwfStandardJs(); Each config is also available as a direct subpath import: ```js -import { iwfStandardTs } from '@iwf-web/eslint-coding-standard/standard-ts'; -import { iwfStandardJs } from '@iwf-web/eslint-coding-standard/standard-js'; +import { iwfWebStandardTs } from '@iwf-web/eslint-coding-standard/standard-ts'; +import { iwfWebStandardJs } from '@iwf-web/eslint-coding-standard/standard-js'; ``` #### With Custom Options @@ -91,9 +95,9 @@ import { iwfStandardJs } from '@iwf-web/eslint-coding-standard/standard-js'; You can pass options to override the default configuration: ```js -import { iwfStandardTs } from '@iwf-web/eslint-coding-standard'; +import { iwfWebStandardTs } from '@iwf-web/eslint-coding-standard'; -export default iwfStandardTs({ +export default iwfWebStandardTs({ typescript: { tsconfigPath: './tsconfig.app.json', }, @@ -105,9 +109,9 @@ export default iwfStandardTs({ You can append additional ESLint flat config objects: ```js -import { iwfStandardTs } from '@iwf-web/eslint-coding-standard'; +import { iwfWebStandardTs } from '@iwf-web/eslint-coding-standard'; -export default iwfStandardTs( +export default iwfWebStandardTs( {}, { rules: { @@ -117,9 +121,18 @@ export default iwfStandardTs( ); ``` +### Migration from v1 + +The function names have been updated to match the `@iwf-web` package scope: + +- `iwfStandardTs` → `iwfWebStandardTs` +- `iwfStandardJs` → `iwfWebStandardJs` + +The old names still work but are deprecated and will be removed in the next major version. + ## Contributing -Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on our code of conduct and the process for submitting pull requests. +Please read [CONTRIBUTING.md][contributing] for details on our code of conduct and the process for submitting pull requests. This project uses [Conventional Commits](https://www.conventionalcommits.org/) for automated releases and changelog generation. @@ -129,21 +142,32 @@ We use [SemVer](http://semver.org/) for versioning. For available versions, see ## Authors -All authors can be found in the [AUTHORS.md](AUTHORS.md) file. +### Special thanks for all the people who had helped this project so far -Contributors can be found in the [CONTRIBUTORS.md](CONTRIBUTORS.md) file. +- **Manuele** - [D3strukt0r](https://github.com/D3strukt0r) See also the full list of [contributors][gh-contributors] who participated in this project. +### I would like to join this list. How can I help the project? + +We're currently looking for contributions for the following: + +- [ ] Bug fixes +- [ ] Translations +- [ ] etc... + +For more information, please refer to our [CONTRIBUTING.md][contributing] guide. + ## License This project is licensed under the MIT License - see the [LICENSE.txt](LICENSE.txt) file for details. ## Acknowledgments -A list of used libraries and code with their licenses can be found in the [ACKNOWLEDGMENTS.md](ACKNOWLEDGMENTS.md) file. +This project currently uses no third-party libraries or copied code. [license]: https://github.com/iwf-web/eslint-coding-standard/blob/main/LICENSE.txt [npm]: https://www.npmjs.com/package/@iwf-web/eslint-coding-standard [gh-tags]: https://github.com/iwf-web/eslint-coding-standard/tags [gh-contributors]: https://github.com/iwf-web/eslint-coding-standard/contributors +[contributing]: https://github.com/iwf-web/.github/blob/main/CONTRIBUTING.md diff --git a/SECURITY.md b/SECURITY.md deleted file mode 100644 index 361b6b9..0000000 --- a/SECURITY.md +++ /dev/null @@ -1,18 +0,0 @@ -# Security Policy - -## Supported Versions - -Only the latest version is being supported. - - - -## Reporting a Vulnerability - -If you find a vulnerability please report it on the [issues page](https://github.com/iwf-web/eslint-coding-standard/issues) and add the tag `vulnerability`. We will then try to find the fix as soon as possible. diff --git a/SUPPORT.md b/SUPPORT.md deleted file mode 100644 index ca43484..0000000 --- a/SUPPORT.md +++ /dev/null @@ -1,3 +0,0 @@ -# How to get support - -If you need help please try to solve it by creating an issue on the [discussions page](https://github.com/iwf-web/eslint-coding-standard/discussions). diff --git a/eslint.config.ts b/eslint.config.ts index 765dd65..7b1cdb0 100644 --- a/eslint.config.ts +++ b/eslint.config.ts @@ -1,3 +1,3 @@ -import {iwfStandardTs} from './src'; +import {iwfWebStandardTs} from './src'; -export default iwfStandardTs(); +export default iwfWebStandardTs(); diff --git a/package.json b/package.json index eedf274..dc6381f 100644 --- a/package.json +++ b/package.json @@ -47,11 +47,11 @@ "eslint-plugin-react-refresh": "^0.5.0" }, "devDependencies": { - "@antfu/ni": "^28.2.0", + "@antfu/ni": "^30.0.0", "@iwf-web/tsconfig": "^1.0.1", - "eslint": "^9.39.3", + "eslint": "^10.0.3", "jiti": "^2.6.1", - "tsdown": "^0.20.3", + "tsdown": "^0.21.1", "typescript": "^5.9.3" }, "packageManager": "pnpm@10.30.3" diff --git a/src/index.ts b/src/index.ts index 43bbfde..c7f264b 100644 --- a/src/index.ts +++ b/src/index.ts @@ -1,2 +1,2 @@ -export {iwfStandardJs} from './standard-js'; -export {iwfStandardTs} from './standard-ts'; +export {iwfStandardJs, iwfWebStandardJs} from './standard-js'; +export {iwfStandardTs, iwfWebStandardTs} from './standard-ts'; diff --git a/src/standard-js.ts b/src/standard-js.ts index 5d4b57b..560edc0 100644 --- a/src/standard-js.ts +++ b/src/standard-js.ts @@ -32,7 +32,7 @@ export const baseRules: Rules = { }; // eslint-disable-next-line ts/promise-function-async -export function iwfStandardJs( +export function iwfWebStandardJs( options?: Parameters[0], ...userConfigs: Parameters[1][] ): ReturnType { @@ -47,3 +47,9 @@ export function iwfStandardJs( ...userConfigs, ); } + +/** + * @deprecated Use {@link iwfWebStandardJs} instead. Will be removed in the next major version. + */ +// TODO: Remove in next major version +export const iwfStandardJs: typeof iwfWebStandardJs = iwfWebStandardJs; diff --git a/src/standard-ts.ts b/src/standard-ts.ts index e04822c..6bacf99 100644 --- a/src/standard-ts.ts +++ b/src/standard-ts.ts @@ -13,7 +13,7 @@ const tsRules = { } satisfies Rules; // eslint-disable-next-line ts/promise-function-async -export function iwfStandardTs( +export function iwfWebStandardTs( options?: Parameters[0], ...userConfigs: Parameters[1][] ): ReturnType { @@ -40,3 +40,9 @@ export function iwfStandardTs( ...userConfigs, ); } + +/** + * @deprecated Use {@link iwfWebStandardTs} instead. Will be removed in the next major version. + */ +// TODO: Remove in next major version +export const iwfStandardTs: typeof iwfWebStandardTs = iwfWebStandardTs;