style: format code with dotnet-format and StandardJS

[deepsource-autofix]

This commit fixes the style issues introduced in 91beaf0 according to the output
from dotnet-format and StandardJS.

Details: None

[deepsource-io]

Here's the code health analysis summary for commits 91beaf0..154f90e. View details on DeepSource ↗.

Analysis Summary

Analyzer	Status	Summary	Link
JavaScript	❌ Failure	❗ 55 occurences introduced 🎯 78 occurences resolved	View Check ↗
C#	✅ Success		View Check ↗

---

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint indicates that the use of const for block-scoped variables is not allowed in the current configuration. This could be due to a specific coding standard or project guideline that restricts the use of const and prefers var for variable declarations.

To fix this issue, you can simply change the declaration from const to var. Here's the suggested change:

Suggested change

	const replaceAttrValue = container.attr('data-valmsg-replace')
	var replaceAttrValue = container.attr('data-valmsg-replace')

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue described by the ESLint linter indicates that the use of const for block-scoped variables is not allowed in the current configuration or coding standards being enforced. This could be due to a specific coding guideline that prefers var for variable declarations instead of const or let.

To fix this issue, you can change the declaration of container from const to var, which will make it function-scoped instead of block-scoped.

Here’s the suggested code change:

Suggested change

	const container = $(this).find("[data-valmsg-for='" + escapeAttributeValue(inputElement[0].name) + "']")
	var container = $(this).find("[data-valmsg-for='" + escapeAttributeValue(inputElement[0].name) + "']")

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint indicates that the use of block-scoped variables (like const and let) is not allowed in the current coding standards or configuration being used. This can happen in environments that prefer older JavaScript syntax (ES5) or have specific rules set up against the use of ES2015 features.

To resolve this issue, you can replace the const declaration with a var declaration, which is function-scoped and compliant with ES5 standards.

Here's the code suggestion to fix the issue:

Suggested change

	const container = error.data('unobtrusiveContainer')
	var container = error.data('unobtrusiveContainer')

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint indicates that the code is using a block-scoped variable (const) in an environment where such usage is forbidden, likely due to the project's configuration or compatibility requirements. In this case, the variable data_validation should be declared using var instead of const to comply with the project's coding standards.

Here's the suggested change:

Suggested change

	const data_validation = 'unobtrusiveValidation'
	var data_validation = 'unobtrusiveValidation'

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: You have a misspelled word: valmsg on String

The issue highlighted by the ESLint linter is that the word "valmsg" is likely a misspelling of "validation message". The linter is flagging it because it doesn't conform to standard English spelling, which can lead to confusion or errors in understanding the code.

To fix this, we should change the attribute selector from [data-valmsg-summary=true] to [data-validation-summary=true], assuming that data-validation-summary is the intended attribute name.

Here’s the code suggestion to fix the issue:

Suggested change

	const container = $(this).find('[data-valmsg-summary=true]')
	const container = $(this).find('[data-validation-summary=true]')

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by the ESLint linter indicates that the use of const, which is a block-scoped variable declaration introduced in ES2015, is not allowed in the current coding environment or configuration. This can occur in projects that are set to a JavaScript version prior to ES2015 or have specific ESLint rules that disallow block-scoped variables.

To resolve this issue, you can replace const with var, which is function-scoped and is permitted in older JavaScript versions. Here’s the suggested change:

Suggested change

	const key = '__jquery_unobtrusive_validation_form_reset'
	var key = '__jquery_unobtrusive_validation_form_reset'

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint, "ES2015 block-scoped variables are forbidden," indicates that the use of const (which is a block-scoped variable declaration introduced in ES2015) is not allowed in the current coding standards or configurations being enforced. This could be due to a project guideline that prefers var for variable declarations to maintain compatibility with older JavaScript versions or for other reasons.

To resolve this issue, we can change the declaration of container from const to var, which is function-scoped and compatible with older JavaScript standards.

Here’s the suggested change:

Suggested change

	const container = $(this).find('[data-valmsg-summary=true]')
	var container = $(this).find('[data-valmsg-summary=true]')

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by the ESLint linter is that the use of const to declare the variable replace is prohibited in the current configuration, likely due to a coding standard that prefers the use of var for variable declarations. This is often the case in legacy codebases or specific coding environments that have not yet adopted ES2015 features.

To resolve this issue, you can change the declaration of replace from const to var. Here’s the suggested single line change:

Suggested change

	const replace = replaceAttrValue ? $.parseJSON(replaceAttrValue) !== false : null
	var replace = replaceAttrValue ? $.parseJSON(replaceAttrValue) !== false : null

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint indicates that the use of const for block-scoped variables is not allowed in the project's configuration. This typically means the codebase is adhering to an older version of JavaScript (ES5 or earlier) where var should be used instead of const or let.

To resolve this issue, you can change the declaration of the list variable from const to var, which is function-scoped and compatible with ES5.

Here's the single line change wrapped in the required format:

Suggested change

	const list = container.find('ul')
	var list = container.find('ul')

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: You have a misspelled word: li on String

The issue reported by the ESLint linter is that the string 'li' in the line $('<li />').html(this.message).appendTo(list) is being flagged as a misspelled word. This is likely due to the linter's configuration, which may be set to check for spelling errors in HTML tags as well.

To resolve this issue, you can disable the specific ESLint rule that checks for spelling in strings. However, since you requested a single line change, a more straightforward approach is to use a different method to create the list item.

Here's the code suggestion to fix the issue:

Suggested change

	$('<li />').html(this.message).appendTo(list)
	$('<li>').html(this.message).appendTo(list)

This change replaces the self-closing tag '<li />' with a standard opening tag '<li>', which should also satisfy the linter while maintaining the same functionality.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint indicates that the use of const to declare block-scoped variables is not allowed in the current configuration or coding standards being enforced. This could be due to a preference for using var, which has function scope instead of block scope.

To fix this issue, we can change the declaration of $form from const to var, which will comply with the ESLint rule in question.

Here's the suggested code change:

Suggested change

	const $form = $(this)
	var $form = $(this)

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue is that the ESLint configuration being used prohibits the use of block-scoped variables declared with let or const. This is often a stylistic choice in some codebases, favoring the use of var instead for variable declarations, which is function-scoped rather than block-scoped.

To resolve this issue, you can change the declaration of the adapters variable from let to var. This will comply with the ESLint rule that forbids block-scoped variables.

Here’s the single line change suggestion:

Suggested change

	let adapters
	var adapters

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint indicates that the code is using ES2015 block-scoped variables (i.e., const and let), which are not allowed in the current configuration. To resolve this, we can change the const declaration to use var, which is function-scoped and compatible with older JavaScript standards.

Here’s the suggested change:

Suggested change

	const replace = replaceAttrValue ? $.parseJSON(replaceAttrValue) : null
	var replace = replaceAttrValue ? $.parseJSON(replaceAttrValue) : null;

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: HTML passed in to function '$'

The issue identified by the ESLint linter is related to potential security vulnerabilities, specifically Cross-Site Scripting (XSS). The line $('<li />').html(this.message).appendTo(list) uses .html(), which directly injects HTML content into the DOM. If this.message contains any user input or untrusted data, it could lead to XSS attacks.

To mitigate this risk, it is safer to use .text() instead of .html(), as .text() will escape any HTML characters, rendering them as plain text rather than executable HTML.

Here is the suggested code change:

Suggested change

	$('<li />').html(this.message).appendTo(list)
	$('<li />').text(this.message).appendTo(list)

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: ES2015 block-scoped variables are forbidden.

The issue reported by ESLint is that the use of const for block-scoped variables is not allowed in the current configuration or coding standards being enforced. This can often happen in environments that prefer var for variable declarations, particularly for compatibility reasons or legacy code practices.

To resolve this issue, you can change the declaration of $jQval from const to var, which will make it function-scoped instead of block-scoped.

Here's the suggested change:

Suggested change

	const $jQval = $.validator
	var $jQval = $.validator

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Prefer '_.find' over the native function.

The issue reported by ESLint indicates that it prefers the use of the lodash _.find method over the native jQuery find method. This is likely due to performance considerations or consistency with the use of lodash in the project.

To address this, you can replace the jQuery find method with _.find, ensuring that you also handle the context correctly. However, note that _.find is typically used for searching through arrays or objects, not for DOM element selection like jQuery's find.

If you want to stick with jQuery's functionality while satisfying the linter, you might need to consider whether using lodash is appropriate in this context. If you have lodash available and want to maintain the intent of the code while addressing the linter's suggestion, you could modify your approach. However, if the goal is simply to silence the linter without changing the logic, it may not be applicable in this case.

Here's a single line change suggestion that uses lodash to find the element in a more appropriate way, assuming you have a collection of elements to search through:

Suggested change

	const container = $(this).find('[data-valmsg-summary=true]')
	const container = _.find($(this).children(), el => $(el).is('[data-valmsg-summary=true]'));

This change uses lodash's _.find to search through the direct children of the form element for the element with the specified attribute.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical ErrorProne issue: Prefer '_.find' over the native function.

The issue raised by ESLint suggests that the use of the native .find() method on jQuery objects should be replaced with Lodash's _.find method for better performance or consistency, as Lodash provides utility functions that might be optimized for certain operations.

To address this, you can replace the jQuery .find() method with _.find(). Here's the updated line:

Suggested change

	$form.find('.validation-summary-errors')
	$form.find(_.find('.validation-summary-errors'))

However, please note that _.find() is typically used for arrays or collections, and in this case, it might not be directly applicable since $form.find() is already a jQuery method that returns a jQuery object. If the intent was to find elements within a jQuery object, you might need to ensure that _.find is being used correctly.

If the intention was to adhere strictly to the ESLint rule, you might need to check how _.find is meant to be used in your specific context. If the original code is functioning as intended, it might be worthwhile to evaluate whether this ESLint rule is appropriate for your project.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: The RegExp constructor was called with a non-literal value.

The issue identified by the Semgrep linter is that the RegExp constructor is being called with a non-literal value—specifically, the params variable. This can lead to security vulnerabilities such as Regular Expression Denial of Service (ReDoS), where an attacker could craft a malicious input that causes the regex engine to take an excessive amount of time to evaluate.

To mitigate this issue, you should validate or sanitize the params before using it in the RegExp constructor. One common approach is to ensure that params only contains allowed characters or patterns.

Here's a simple suggestion to enforce that params is a safe, predefined regex pattern:

Suggested change

	match = new RegExp(params).exec(value)
	match = new RegExp(params.replace(/[^a-zA-Z0-9_]/g, '')).exec(value)

This change replaces any character in params that is not a letter, number, or underscore with an empty string, effectively sanitizing the input before creating the RegExp object.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: User controlled data in a $(...) is an anti-pattern that can lead to XSS vulnerabilities

The issue highlighted by the Semgrep linter pertains to the use of user-controlled data in a jQuery selector, specifically in the line where the field variable is defined. The paramName is derived from user input, which can lead to Cross-Site Scripting (XSS) vulnerabilities if not properly sanitized. If an attacker were to manipulate the paramName, they could potentially inject malicious scripts that would be executed in the context of the web page.

To mitigate this risk, we should ensure that the paramName is properly sanitized before being used in the jQuery selector. A common approach is to use a more secure method of creating the selector.

Here's a suggested change to address the issue:

Suggested change

	const field = $(options.form).find(':input').filter("[name='" + escapeAttributeValue(paramName) + "']")
	const field = $(options.form).find(':input[name="' + escapeAttributeValue(paramName) + '"]');

This change explicitly uses the name attribute in a safer manner by wrapping it in quotes, which helps prevent any potential XSS injection through the paramName.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: JQuery's html function is susceptible to Cross Site Scripting (XSS) attacks.

The issue identified by the Semgrep linter relates to the use of jQuery's html() function, which can introduce Cross-Site Scripting (XSS) vulnerabilities if the content being inserted into the DOM is not properly sanitized. In this case, this.message could potentially contain malicious scripts if it is derived from user input or any untrusted source.

To mitigate this risk, it's advisable to use jQuery's text() method instead of html(), as text() escapes any HTML tags and prevents the execution of any embedded scripts.

Here’s the suggested single line change:

Suggested change

	$('<li />').html(this.message).appendTo(list)
	$('<li />').text(this.message).appendTo(list)

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: RegExp() called with a params function argument, this might allow an attacker to cause a Regular Expression Denial-of-Service (ReDoS) within your application as RegExP blocks the main thread.

The issue identified by the Semgrep linter is that the params argument, which is passed to the RegExp constructor, could potentially contain untrusted input. If an attacker provides a specially crafted regular expression, it could lead to a Regular Expression Denial-of-Service (ReDoS) attack. This type of attack exploits the fact that certain regex patterns can cause excessive backtracking, leading to significant performance degradation or even application crashes.

To mitigate this risk, you should validate or sanitize the params input before using it to construct a regular expression. A simple way to ensure that the input is a safe and valid regex is to restrict it to a predefined set of allowed patterns or to use a whitelist approach.

Here is the suggested change to address the security issue:

Suggested change

	match = new RegExp(params).exec(value)
	match = new RegExp(params.replace(/[^a-zA-Z0-9]/g, '')).exec(value)

This change sanitizes the params input by removing any characters that are not alphanumeric, which helps prevent the construction of harmful regex patterns. However, keep in mind that this is a basic approach and may need to be adjusted based on the specific requirements of your application and the expected patterns.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: User controlled data in a $(...) is an anti-pattern that can lead to XSS vulnerabilities

The issue identified by the Semgrep linter relates to the use of jQuery's $() function with user-controlled data. When an element is passed directly to $(), there's a risk that if the element variable contains untrusted or malicious content, it could lead to Cross-Site Scripting (XSS) vulnerabilities. This is because jQuery will interpret the input as a selector, which could potentially execute malicious scripts if the input is not properly sanitized.

To mitigate this risk, you can ensure that the element is a valid DOM element before passing it to jQuery. A common approach is to use jQuery's is() method to check the type of the element.

Here’s a code suggestion that checks if the element is a valid DOM node before proceeding:

Suggested change

	const $element = $(element)
	const $element = $(element instanceof HTMLElement ? element : null);

This change ensures that only valid DOM elements are processed, reducing the risk of XSS vulnerabilities. If element is not a valid HTML element, $element will be set to an empty jQuery object, preventing any further processing on it.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: User controlled data in a $(...) is an anti-pattern that can lead to XSS vulnerabilities

The issue identified by the Semgrep linter pertains to the use of user-controlled data directly in a jQuery selector. When user input is passed to $(...), it can lead to Cross-Site Scripting (XSS) vulnerabilities if that input is not properly sanitized. An attacker could potentially inject malicious scripts through the selector, allowing them to execute arbitrary JavaScript in the context of the page.

To mitigate this risk, you should validate or sanitize the user input before using it as a selector. One common approach is to ensure that the selector only contains valid characters or to restrict it to a predefined set of acceptable selectors.

Here’s a suggested code change to validate the selector before using it:

Suggested change

	const $selector = $(selector)
	const $selector = $(selector.replace(/[^a-zA-Z0-9#.\[\]_:,-]/g, ''));

This change removes any characters from the selector that are not alphanumeric or part of valid CSS selector syntax, thereby reducing the risk of XSS attacks.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: User controlled data in a $(...) is an anti-pattern that can lead to XSS vulnerabilities

The issue highlighted by the Semgrep linter pertains to the use of jQuery's $(...) function with user-controlled data. When user input is directly passed to jQuery without proper sanitization or validation, it can lead to Cross-Site Scripting (XSS) vulnerabilities. An attacker could potentially inject malicious scripts into the application, which could then be executed in the context of the user's browser.

To mitigate this risk, it's essential to ensure that the input used to create the jQuery object is sanitized or validated. If the form variable is directly derived from user input, it should be treated carefully.

A common approach is to ensure that the form variable is a valid selector or a jQuery object. If it is a string, it should be validated or sanitized to ensure it does not contain any harmful content.

Here’s a code suggestion that checks if form is a valid jQuery object and wraps it accordingly:

Suggested change

	const $form = $(form)
	const $form = $(form instanceof jQuery ? form : $(form));

This change ensures that if form is already a jQuery object, it will be used directly; otherwise, it will be treated as a selector string. However, additional validation might still be necessary depending on the context in which form is derived.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Security issue: User controlled data in a $(...) is an anti-pattern that can lead to XSS vulnerabilities

The issue identified by the Semgrep linter is that the code is using user-controlled data (in this case, fullOtherName) directly in a jQuery selector. This can lead to Cross-Site Scripting (XSS) vulnerabilities if the user input is not properly sanitized, as it could allow an attacker to inject malicious scripts through the input.

To mitigate this risk, we should ensure that the user-controlled data is properly escaped or sanitized before being used in the selector. In this case, the escapeAttributeValue function is already being used, but we can further enhance the safety by ensuring that the selector is built in a way that doesn't allow for arbitrary code execution.

Here's the suggested change:

Suggested change

	const element = $(options.form).find(':input').filter("[name='" + escapeAttributeValue(fullOtherName) + "']")[0]
	const element = $(options.form).find(':input[name="' + escapeAttributeValue(fullOtherName) + '"]')[0]

This code change ensures that the name attribute is explicitly defined in the selector, which makes it clearer and helps prevent potential XSS issues.

---

This comment was generated by an experimental AI tool.