Update for release (#4644)

README.md

@@ -9,7 +9,7 @@ This SonarSource project is a [static code analyzer](https://en.wikipedia.org/wi
 # Features
 
 - Advanced rules based on pattern matching and control flow analysis
-- [389 JS rules](https://rules.sonarsource.com/javascript) and [393 TS rules](https://rules.sonarsource.com/typescript)
+- [397 JS rules](https://rules.sonarsource.com/javascript) and [402 TS rules](https://rules.sonarsource.com/typescript)
 - [26 CSS rules](https://rules.sonarsource.com/css)
 - Compatible with ECMAScript 2015-2020
 - React JSX, Flow, Vue, and AWS lambda functions support for JavaScript and TypeScript

css-sonarpedia/sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "CSS"
   ],
-  "latest-update": "2023-12-21T17:13:56.851986Z",
+  "latest-update": "2024-03-28T12:39:07.731724Z",
   "options": {
     "no-language-in-filenames": true
   }

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S106.html

@@ -37,9 +37,9 @@ <h3>Code examples</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/">OWASP Top 10 2021 Category A9</a> - Security Logging and
-  Monitoring Failures </li>
-  <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
-  Exposure </li>
+  <li> OWASP - <a href="https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/">Top 10 2021 Category A9 - Security Logging and
+  Monitoring Failures</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
+  Exposure</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S107.html

@@ -1,5 +1,5 @@
 <h2>Why is this an issue?</h2>
-<p>Functions with a long parameter list are difficult to use, as maintainers must figure out the role of each parameter and keep track of their
+<p>Functions with a long parameter list are difficult to use because maintainers must figure out the role of each parameter and keep track of their
 position.</p>
 <pre>
 function setCoordinates(x1, y1, z1, x2, y2, z2) { // Noncompliant

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1121.html

@@ -36,6 +36,6 @@ <h4>Compliant solution</h4>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/481">MITRE, CWE-481</a> - Assigning instead of Comparing </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/481">CWE-481 - Assigning instead of Comparing</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1125.html

@@ -4,7 +4,7 @@ <h2>Why is this an issue?</h2>
 variable or expression that evaluates to a boolean value is unnecessary and can make the code harder to read and understand. The more complex a
 boolean expression is, the harder it will be for developers to understand its meaning and expected behavior, and it will favour the introduction of
 new bugs.</p>
-<h2>How to tix it</h2>
+<h2>How to fix it</h2>
 <p>Remove redundant boolean literals from expressions to improve readability and make the code more maintainable.</p>
 <pre data-diff-id="1" data-diff-type="noncompliant">
 if (someValue == true) { /* ... */ } // Noncompliant: Redundant comparison

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1126.html

@@ -1,6 +1,6 @@
 <h2>Why is this an issue?</h2>
 <p>The <code>if...else</code> statement is used to make decisions based on the truthiness of a boolean expression, and the <code>if</code> block
-executes when the expression is <code>true</code>, while the <code>else</code> block executes when the expression is false.</p>
+executes when the expression is truthy, while the <code>else</code> block executes when the expression is falsy.</p>
 <p>Wrapping a boolean expression in an <code>if...else</code> statement and returning <code>true</code> or <code>false</code> in the respective blocks
 is redundant and unnecessary. It can also make the code harder to maintain, as it adds unnecessary lines of code that need to be read and
 understood.</p>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1134.html

@@ -10,6 +10,6 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546 - Suspicious Comment</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1135.html

@@ -1,8 +1,8 @@
 <h2>Why is this an issue?</h2>
 <p>Developers often use <code>TODO</code> tags to mark areas in the code where additional work or improvements are needed but are not implemented
-immediately. However, these <code>TODO</code> tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This code smell
-class aims to identify and address such unattended <code>TODO</code> tags to ensure a clean and maintainable codebase. This description will explore
-why this is a problem and how it can be fixed to improve the overall code quality.</p>
+immediately. However, these <code>TODO</code> tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to
+identify and address unattended <code>TODO</code> tags to ensure a clean and maintainable codebase. This description explores why this is a problem
+and how it can be fixed to improve the overall code quality.</p>
 <h3>What is the potential impact?</h3>
 <p>Unattended <code>TODO</code> tags in code can have significant implications for the development process and the overall codebase.</p>
 <p>Incomplete Functionality: When developers leave <code>TODO</code> tags without implementing the corresponding code, it results in incomplete
@@ -11,8 +11,8 @@ <h3>What is the potential impact?</h3>
 Delayed bug fixes can result in more severe issues and increase the effort required to resolve them later.</p>
 <p>Impact on Collaboration: In team-based development environments, unattended <code>TODO</code> tags can hinder collaboration. Other team members
 might not be aware of the intended changes, leading to conflicts or redundant efforts in the codebase.</p>
-<p>Codebase Bloat: Accumulation of unattended <code>TODO</code> tags over time can clutter the codebase and make it difficult to distinguish between
-work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.</p>
+<p>Codebase Bloat: The accumulation of unattended <code>TODO</code> tags over time can clutter the codebase and make it difficult to distinguish
+between work in progress and completed code. This bloat can make it challenging to maintain an organized and efficient codebase.</p>
 <p>Addressing this code smell is essential to ensure a maintainable, readable, reliable codebase and promote effective collaboration among
 developers.</p>
 <h3>Noncompliant code example</h3>
@@ -23,6 +23,6 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/546">CWE-546 - Suspicious Comment</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S117.html

@@ -9,15 +9,17 @@ <h2>Why is this an issue?</h2>
 <h3>What is the potential impact?</h3>
 <p>Inconsistent naming of variables, properties, and parameters can lead to several issues in your code:</p>
 <ul>
-  <li> Reduced Readability: inconsistent variable, property, and parameter names make the code harder to read and understand; consequently, it is more
-  difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
-  <li> Difficulty in Identifying Variables: variables, properties, and parameters that don’t adhere to a standard naming convention are challenging to
-  identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
-  <li> Increased Risk of Errors: inconsistent or unclear variable, property, and parameter names lead to misunderstandings about what the variable
-  represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
-  <li> Collaboration Difficulties: in a team setting, inconsistent naming conventions lead to confusion and miscommunication among team members. </li>
-  <li> Difficulty in Code Maintenance: inconsistent naming leads to an inconsistent codebase. The code is difficult to understand, and making changes
-  feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain. </li>
+  <li> <strong>Reduced Readability</strong>: Inconsistent variable, property, and parameter names make the code harder to read and understand;
+  consequently, it is more difficult to identify the purpose of each variable, spot errors, or comprehend the logic. </li>
+  <li> <strong>Difficulty in Identifying Variables</strong>: The variables, properties, and parameters that don’t adhere to a standard naming
+  convention are challenging to identify; thus, the coding process slows down, especially when dealing with a large codebase. </li>
+  <li> <strong>Increased Risk of Errors</strong>: Inconsistent or unclear variable, property, and parameter names lead to misunderstandings about what
+  the variable represents. This ambiguity leads to incorrect assumptions and, consequently, bugs in the code. </li>
+  <li> <strong>Collaboration Difficulties</strong>: In a team setting, inconsistent naming conventions lead to confusion and miscommunication among
+  team members. </li>
+  <li> <strong>Difficulty in Code Maintenance</strong>: Inconsistent naming leads to an inconsistent codebase. The code is difficult to understand,
+  and making changes feels like refactoring constantly, as you face different naming methods. Ultimately, it makes the codebase harder to maintain.
+  </li>
 </ul>
 <p>In summary, not adhering to a naming convention for variables, properties, and parameters can lead to confusion, errors, and inefficiencies, making
 the code harder to read, understand, and maintain.</p>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1192.html

@@ -6,8 +6,8 @@ <h3>Exceptions</h3>
 String literals inside import/export statements and JSX attributes are also ignored. The same goes for statement-like string literals, e.g. <code>'use
 strict';</code>.</p>
 <h2>How to fix it</h2>
-<p>Instead, use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a
-single place.</p>
+<p>Use constants to replace the duplicated string literals. Constants can be referenced from many places, but only need to be updated in a single
+place.</p>
 <h3>Code examples</h3>
 <h4>Noncompliant code example</h4>
 <p>With the default threshold of 3:</p>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S128.html

@@ -51,6 +51,6 @@ <h3>Exceptions</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/484">MITRE, CWE-484</a> - Omitted Break Statement in Switch </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/484">CWE-484 - Omitted Break Statement in Switch</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S131.html

@@ -78,6 +78,6 @@ <h3>Exceptions</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/478">MITRE, CWE-478</a> - Missing Default Case in Switch Statement </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/478">CWE-478 - Missing Default Case in Switch Statement</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1313.html

@@ -60,8 +60,8 @@ <h2>Exceptions</h2>
 </ul>
 <h2>See</h2>
 <ul>
-  <li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
-  <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
-  Exposure </li>
+  <li> OWASP - <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">Top 10 2021 Category A1 - Broken Access Control</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
+  Exposure</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1442.html

@@ -10,8 +10,8 @@ <h3>Noncompliant code example</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
-  Exposure </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/489">MITRE, CWE-489</a> - Active Debug Code </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
+  Exposure</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/489">CWE-489 - Active Debug Code</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1444.html

@@ -1,13 +1,13 @@
 <h2>Why is this an issue?</h2>
 <p>Public <code>static</code> fields in TypeScript should be declared as <code>readonly</code> to prevent them from being modified after their initial
 assignment. This is a good practice because it makes the code safer by preventing accidental changes to these fields, which could lead to bugs that
-are hard to detect and fix.</p>
+are hard to detect.</p>
 <pre data-diff-id="1" data-diff-type="noncompliant">
 class MyClass {
     static myField = 42; // Noncompliant
 }
 </pre>
-<p>To fix this, declare you static field with the <code>readonly</code> qualifier .</p>
+<p>To fix this, declare your static field with the <code>readonly</code> qualifier.</p>
 <pre data-diff-id="1" data-diff-type="compliant">
 class MyClass {
     static readonly myField = 42;
@@ -16,6 +16,7 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h2>Documentation</h2>
 <ul>
-  <li> TypeScript Documentation - <a href="https://www.typescriptlang.org/docs/handbook/2/objects.html#readonly-properties">readonly</a> </li>
+  <li> TypeScript Documentation - <a href="https://www.typescriptlang.org/docs/handbook/2/objects.html#readonly-properties">readonly properties</a>
+  </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1523.html

@@ -37,9 +37,9 @@ <h2>Exceptions</h2>
 safe.</p>
 <h2>See</h2>
 <ul>
-  <li> <a href="https://owasp.org/Top10/A03_2021-Injection/">OWASP Top 10 2021 Category A3</a> - Injection </li>
-  <li> <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/95">MITRE, CWE-95</a> - Improper Neutralization of Directives in Dynamically Evaluated Code
-  ('Eval Injection') </li>
+  <li> OWASP - <a href="https://owasp.org/Top10/A03_2021-Injection/">Top 10 2021 Category A3 - Injection</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">Top 10 2017 Category A1 - Injection</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/95">CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval
+  Injection')</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1525.html

@@ -21,8 +21,8 @@ <h3>Compliant solution</h3>
 </pre>
 <h2>Resources</h2>
 <ul>
-  <li> <a href="https://www.owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">OWASP Top 10 2017 Category A3</a> - Sensitive Data
-  Exposure </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/489">MITRE, CWE-489</a> - Active Debug Code </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure">Top 10 2017 Category A3 - Sensitive Data
+  Exposure</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/489">CWE-489 - Active Debug Code</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1854.html

@@ -43,7 +43,7 @@ <h4>Compliant solution</h4>
 <h2>Resources</h2>
 <h3>Standards</h3>
 <ul>
-  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/563">563 - Assignment to Variable without Use ('Unused Variable')</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/563">CWE-563 - Assignment to Variable without Use ('Unused Variable')</a> </li>
 </ul>
 <h3>Related rules</h3>
 <ul>

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S1874.html

@@ -24,6 +24,6 @@ <h2>Why is this an issue?</h2>
 <h2>Resources</h2>
 <h3>Documentation</h3>
 <ul>
-  <li> <a href="https://cwe.mitre.org/data/definitions/477">MITRE, CWE-477</a> - Use of Obsolete Functions </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/477">CWE-477 - Use of Obsolete Functions</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2068.html

@@ -52,12 +52,12 @@ <h2>Compliant Solution</h2>
 </pre>
 <h2>See</h2>
 <ul>
-  <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
-  Authentication Failures </li>
-  <li> <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">OWASP Top 10 2017 Category A2</a> - Broken Authentication
+  <li> OWASP - <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">Top 10 2021 Category A7 - Identification and
+  Authentication Failures</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">Top 10 2017 Category A2 - Broken Authentication</a>
   </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/798">MITRE, CWE-798</a> - Use of Hard-coded Credentials </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/259">MITRE, CWE-259</a> - Use of Hard-coded Password </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/798">CWE-798 - Use of Hard-coded Credentials</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/259">CWE-259 - Use of Hard-coded Password</a> </li>
   <li> Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
 </ul>
 

sonar-plugin/javascript-checks/src/main/resources/org/sonar/l10n/javascript/rules/javascript/S2077.html

@@ -53,11 +53,10 @@ <h2>Exceptions</h2>
 </pre>
 <h2>See</h2>
 <ul>
-  <li> <a href="https://owasp.org/Top10/A03_2021-Injection/">OWASP Top 10 2021 Category A3</a> - Injection </li>
-  <li> <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">OWASP Top 10 2017 Category A1</a> - Injection </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/20">MITRE, CWE-20</a> - Improper Input Validation </li>
-  <li> <a href="https://cwe.mitre.org/data/definitions/89">MITRE, CWE-89</a> - Improper Neutralization of Special Elements used in an SQL Command
-  </li>
+  <li> OWASP - <a href="https://owasp.org/Top10/A03_2021-Injection/">Top 10 2021 Category A3 - Injection</a> </li>
+  <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A1_2017-Injection">Top 10 2017 Category A1 - Injection</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/20">CWE-20 - Improper Input Validation</a> </li>
+  <li> CWE - <a href="https://cwe.mitre.org/data/definitions/89">CWE-89 - Improper Neutralization of Special Elements used in an SQL Command</a> </li>
   <li> Derived from FindSecBugs rules <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_JPA">Potential SQL/JPQL Injection
   (JPA)</a>, <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_JDO">Potential SQL/JDOQL Injection (JDO)</a>, <a
   href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#SQL_INJECTION_HIBERNATE">Potential SQL/HQL Injection (Hibernate)</a> </li>