Merge remote-tracking branch 'origin/main' into dependabot/npm_and_ya…

…rn/word-wrap-1.2.4

README.md

@@ -33,7 +33,7 @@ The table that will be inserted into the `readme.md` will have the following str
 ...
 ```
 
-The number of `#` characters needed for the section titles is dynamically calculated, and the title of the `Parameters` section can be configured via the [configuration file](#configuration-file). The `README.md` file with a `# Parameters` section must be created before running the tool.
+The number of `#` characters needed for the section titles is dynamically calculated, and the title of the `Parameters` section can be configured via the [configuration file](#configuration-file). The `README.md` file with a `## Parameters` section must be created before running the tool, the `Parameters` section should have two `#` or more symbols.
 
 ## Requirements
 
@@ -120,6 +120,34 @@ Currently supported modifiers:
 
 The modifiers are also customizable via the [configuration file](#configuration-file).
 
+In case you are adding a `custom modifier` to a parameter that does not have value in the values file
+you must add one of the `supported modifiers` as last modifier.
+
+Example:
+
+Values file
+
+```yaml
+# @param noDefaultValue [number, nullable] Description
+# noDefaultValue: 1
+```
+
+Custom configuration snippet:
+
+```json
+{
+  ...
+    "modifiers": {
+    "array": "array",
+    "object": "object"
+    "string": "string"
+    "nullable": "nullable",
+    "number": "number"
+  },
+  ...
+}
+```
+
 ## Configuration file
 
 The configuration file has the following structure:

SECURITY.md

@@ -2,47 +2,40 @@
 
 The community has adopted this security disclosure and response policy to ensure we responsibly handle critical issues.
 
-
 ## Supported Versions
 
 For a list of support versions that this project will potentially create security fixes for, please refer to the Releases page on this project's GitHub and/or project related documentation on release cadence and support.
 
-
 ## Reporting a Vulnerability - Private Disclosure Process
 
 Security is of the highest importance and all security vulnerabilities or suspected security vulnerabilities should be reported to this project privately, to minimize attacks against current users  before they are fixed. Vulnerabilities will be investigated and patched on the next patch (or minor) release as soon as possible. This information could be kept entirely internal to the project.
 
 If you know of a publicly disclosed security vulnerability for this project, please **IMMEDIATELY** contact the maintainers of this project privately. The use of encrypted email is encouraged.
 
+**IMPORTANT: Do not file public issues on GitHub for security vulnerabilities**. To report a vulnerability or a security-related issue, please contact the maintainers with enough details through one of the following channels:
 
-**IMPORTANT: Do not file public issues on GitHub for security vulnerabilities**
-
-To report a vulnerability or a security-related issue, please contact the maintainers with enough details through one of the following channels: 
 * Directly via their individual email addresses
 * Open a [GitHub Security Advisory](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability). This allows for anyone to report security vulnerabilities directly and privately to the maintainers via GitHub. Note that this option may not be present for every repository.
 
-The report will be fielded by the maintainers who have committer and release permissions. Feedback will be sent within 3 business days, including a detailed plan to investigate the issue and any potential workarounds to perform in the meantime. 
+The report will be fielded by the maintainers who have committer and release permissions. Feedback will be sent within 3 business days, including a detailed plan to investigate the issue and any potential workarounds to perform in the meantime.
 
 Do not report non-security-impacting bugs through this channel. Use GitHub issues for all non-security-impacting bugs.
 
-
 ## Proposed Report Content
 
 Provide a descriptive title and in the description of the report include the following information:
 
-*   Basic identity information, such as your name and your affiliation or company.
-*   Detailed steps to reproduce the vulnerability  (POC scripts, screenshots, and logs are all helpful to us).
-*   Description of the effects of the vulnerability on this project and the related hardware and software configurations, so that the maintainers can reproduce it.
-*   How the vulnerability affects this project's usage and an estimation of the attack surface, if there is one.
-*   List other projects or dependencies that were used in conjunction with this project to produce the vulnerability.
-
+* Basic identity information, such as your name and your affiliation or company.
+* Detailed steps to reproduce the vulnerability  (POC scripts, screenshots, and logs are all helpful to us).
+* Description of the effects of the vulnerability on this project and the related hardware and software configurations, so that the maintainers can reproduce it.
+* How the vulnerability affects this project's usage and an estimation of the attack surface, if there is one.
+* List other projects or dependencies that were used in conjunction with this project to produce the vulnerability.
 
 ## When to report a vulnerability
 
-*   When you think this project has a potential security vulnerability.
-*   When you suspect a potential vulnerability but you are unsure that it impacts this project.
-*   When you know of or suspect a potential vulnerability on another project that is used by this project.
-
+* When you think this project has a potential security vulnerability.
+* When you suspect a potential vulnerability but you are unsure that it impacts this project.
+* When you know of or suspect a potential vulnerability on another project that is used by this project.
 
 ## Patch, Release, and Disclosure
 
@@ -56,14 +49,12 @@ The maintainers will respond to vulnerability reports as follows:
 6. The maintainers will work on fixing the vulnerability and perform internal testing before preparing to roll out the fix.
 7. Once the fix is confirmed, the maintainers will patch the vulnerability in the next patch or minor release, and backport a patch release into all earlier supported releases.
 
-
 ## Public Disclosure Process
 
 The maintainers publish the public advisory to this project's community via GitHub. In most cases, additional communication via Slack, Twitter, mailing lists, blog, and other channels will assist in educating the project's users and rolling out the patched release to affected users.
 
 The maintainers will also publish any mitigating steps users can take until the fix can be applied to their instances. This project's distributors will handle creating and publishing their own security advisories.
 
-
 ## Confidentiality, integrity and availability
 
 We consider vulnerabilities leading to the compromise of data confidentiality, elevation of privilege, or integrity to be our highest priority concerns. Availability, in particular in areas relating to DoS and resource exhaustion, is also a serious security concern. The maintainer team takes all vulnerabilities, potential vulnerabilities, and suspected vulnerabilities seriously and will investigate them in an urgent and expeditious manner.

lib/builder.js

@@ -36,7 +36,7 @@ function applyModifiers(param, config) {
           // modifier specifies the default value.
           break;
         default:
-          throw new Error(`Unknown modifier: ${modifier}`);
+          throw new Error(`Unknown modifier: ${modifier} for parameter ${param.name}`);
       }
     });
   }