[PTP-939] chore: add linting policy

[cdias900]

No description provided.

[codacy-production]

❌ Codacy found a critical Error Prone issue: 'data' is defined but never used.

The issue that ESLint is pointing out is that the data parameter is defined in the arrow function assigned to channel.port1.onmessage, but it is never used within that function. This is often an indication of unnecessary code, and it could potentially be a sign that there was an intention to use data that was not fulfilled, which could lead to bugs or misunderstandings about how the code works.

To resolve this issue, we can simply remove the unused data parameter from the function definition. Here's the suggested change:

Suggested change

	channel.port1.onmessage = ({ data }) => {
	channel.port1.onmessage = () => {

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .duty_amt on an any value.

The issue here is that l3DataSummary is being treated as an any type, and TypeScript (with ESLint rules enabled) is warning that accessing .duty_amt on a value of type any is unsafe because it assumes that the property exists and is of the expected type without any type checking. This can lead to runtime errors if l3DataSummary does not have the property .duty_amt or if it is not of the expected type.

To fix this issue, you should ensure that l3DataSummary has a specific type that includes the .duty_amt property as a number. This would typically involve defining an interface or type for l3DataSummary. However, since you asked for a single line change, I will assume that validate function is generic and can be used to ensure type safety.

Here's the code suggestion to add a generic type parameter to the validate function call:

Suggested change

	if (l3DataSummary.duty_amt && !validate(l3DataSummary.duty_amt, 'number')) {
	if (l3DataSummary.duty_amt && !validate<number>(l3DataSummary.duty_amt, 'number')) {

This change assumes that the validate function is designed to accept a type parameter that can enforce the type check at compile time. If it's not the case, you would need to define the type for l3DataSummary or cast it to a known type with the expected properties.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: A record is preferred over an index signature.

Suggested change

	metadata?: { [key: string | number]: string | number | boolean };
	metadata?: Record<string | number, string | number | boolean>;

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .tax_ind on an any value.

The issue identified by ESLint is that the property tax_ind is being accessed on l3DataSummary which is implicitly typed as any. In TypeScript, the any type disables all further type checking, and accessing properties on an any type value is generally considered unsafe because it bypasses the compiler's type checking.

To fix this issue, you should ensure that l3DataSummary has a specific type where tax_ind is known to be a property with a specific type (most likely a string, given the context). Assuming l3DataSummary should be of type L3DataSummaryType where tax_ind is defined, you would add a type to l3DataSummary. If L3DataSummaryType is not already defined, you should define it according to the structure of l3DataSummary.

If the type is already defined, the code suggestion to fix the issue would be to add a type annotation to l3DataSummary. Here's the single line change:

Suggested change

	if (!Object.values(TaxIndicatorType).includes(l3DataSummary.tax_ind)) {
	if (!validate((l3DataSummary as L3DataSummaryType).tax_ind, 'string')) {

This line assumes that L3DataSummaryType is the correct type that describes the structure of l3DataSummary and that it includes the tax_ind property. If L3DataSummaryType does not exist, you will need to define it appropriately to match the structure of l3DataSummary.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Array type using 'Array' is forbidden. Use 'T[]' instead.

Suggested change

	siblings: Array<keyof achElementIds>;
	siblings: (keyof achElementIds)[];

[codacy-production]

⚠️ Codacy found a medium Best Practice issue: Unnecessary conditional, value is always truthy.

The issue that ESLint is pointing out is that the conditional check if (onSuccess) is unnecessary because it is implying that onSuccess could be falsy (like null, undefined, 0, false, or an empty string), but the linter has determined that in the context of this code, onSuccess is always a truthy value. This means that the check is redundant and can be removed.

However, without the broader context of the entire codebase, it's not clear if the linter's determination is correct or if this is a false positive. If onSuccess is indeed always truthy, the conditional is unnecessary. If onSuccess might be falsy in some cases, the conditional is needed to prevent runtime errors.

Assuming the linter is correct and onSuccess is always truthy, the line should be changed to directly assign the handler without the conditional check:

Suggested change

	if (onSuccess) tagFrame.onSuccess = (message: any) => onSuccess(message.data);
	tagFrame.onSuccess = (message: any) => onSuccess(message.data);

If the linter is incorrect and onSuccess can be falsy, the code should not be changed, and you might need to configure the linter to understand the possible states of onSuccess correctly.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Avoid referencing unbound methods which may cause unintentional scoping of this.
If your function does not access this, you can annotate it with this: void, or consider using an arrow function instead.

The issue here is that this.handleFeeMessage is being passed as a callback function to common.handleHostedFieldMessage. If handleFeeMessage is a method that relies on this to access the current instance of the class, passing it without binding this can lead to errors when the method is called, because this will not refer to the class instance anymore.

To fix this, you can either explicitly bind this to the method when passing it as a callback or use an arrow function which lexically binds this and does not have its own this context. Here's how you can bind this explicitly using .bind(this):

Suggested change

	this.handleFeeMessage,
	this.handleFeeMessage.bind(this),

This ensures that when handleFeeMessage is called, it will have the correct this context.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe return of an any typed value.

The issue that ESLint is pointing out is that the .map() function is returning an array with elements of type any. In TypeScript, using the any type is considered unsafe because it bypasses the compiler's type checking. To fix this issue, we should explicitly define the type of the elements that are being returned by the .map() function.

Assuming that sibling.type is supposed to be a string (you would replace string with the appropriate type if it's different), the line should be updated to include a type assertion like this:

Suggested change

	const processedElementTypes = value.elements.siblings.map(sibling => sibling.type);
	const processedElementTypes = value.elements.siblings.map(sibling => sibling.type as string);

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Unexpected any. Specify a different type.

Suggested change

	export const cardPresentObserver = (cb: (value: any) => void) =>
	export const cardPresentObserver = (cb: (value: unknown) => void) =>

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .order_num on an any value.

The issue identified by ESLint is that l3DataSummary is being treated as an any type, which means that TypeScript's type checking is effectively being bypassed. Accessing .order_num on an object that is implicitly or explicitly typed as any is unsafe because there is no guarantee that the property exists or that it is of the expected type.

To fix this issue, you should ensure that l3DataSummary has a specific type that includes the order_num property as a string. If the type of l3DataSummary is already defined elsewhere in the code, you should reference that type. If not, you should define an interface or type for it.

For the sake of this example, let's assume that l3DataSummary should be of type L3DataSummaryType. You would then modify the line where l3DataSummary is used to include a type assertion, ensuring that TypeScript treats l3DataSummary as an object of type L3DataSummaryType rather than any.

Here's the single line change with a type assertion:

Suggested change

	if (l3DataSummary.order_num && !validate(l3DataSummary.order_num, 'string')) {
	if ((l3DataSummary as L3DataSummaryType).order_num && !validate((l3DataSummary as L3DataSummaryType).order_num, 'string')) {

Please note that in a real-world scenario, you should define L3DataSummaryType with the appropriate properties and their types to match the structure of l3DataSummary. If l3DataSummary is already typed elsewhere, replace L3DataSummaryType with the actual type name.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: 'ready' is defined but never used.

The issue reported by ESLint indicates that the parameter ready in the function passed to handleMessage within readyObserver is defined but never used. This can happen when you define a parameter in a function but do not use it within the function body. In TypeScript and JavaScript, if a parameter is not used, it can be omitted or replaced with an underscore _ to indicate that it is intentionally unused.

Since readyObserver is intended to call the callback cb with a fixed value true, there is no need to define a parameter for the function passed to handleMessage. To fix this issue, you can remove the unused parameter or replace it with an underscore _. Here's the suggested code change:

export const readyObserver = (cb: (ready: true) => void) =>
  messaging.handleMessage(messaging.readyTypeMessage, () => {
    cb(true);
  });

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe assignment of an any value.

The issue here is that the variable dualScreenLeft is implicitly typed as any, which is a type that TypeScript uses to represent any JavaScript value when the type is unknown. Using any bypasses TypeScript's type checking, which can lead to runtime errors if the value of dualScreenLeft is not what the code expects it to be.

To fix this issue, you should ensure that dualScreenLeft has a specific type, such as number, which is appropriate for its usage in mathematical operations. If dualScreenLeft is intended to be a number, you should explicitly define its type or ensure it is cast to a number before using it in the calculation.

Here's the code suggestion that adds a type assertion to dualScreenLeft to ensure it's treated as a number:

Suggested change

	const left = width / 2 - w / 2 + dualScreenLeft;
	const left = width / 2 - w / 2 + (dualScreenLeft as number);

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe argument of type any assigned to a parameter of type ErrorMessage | FieldsReadyMessage | PromiseLike<ErrorMessage | FieldsReadyMessage>.

The issue here is that the data being passed to the resolve function is of type any, which is unsafe because it does not guarantee that data is of the expected type ErrorMessage | FieldsReadyMessage. TypeScript expects a more specific type to ensure type safety.

To fix this issue, you should assert the type of data to be either ErrorMessage or FieldsReadyMessage before resolving the promise. Here's how you could do that:

Suggested change

	resolve(data);
	resolve(data as ErrorMessage | FieldsReadyMessage);

This type assertion tells TypeScript that you're confident data is of the type ErrorMessage | FieldsReadyMessage. However, be aware that type assertions can potentially introduce runtime errors if the data is not actually of the asserted type, so they should be used with caution and ideally only when you're certain of the data's type.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe argument of type any assigned to a parameter of type string.

The issue here is that the stage variable is initially typed as any due to the assignment from keyParts[1], which is an element of an array that was created by splitting a string of unknown format. Since TypeScript is a statically typed language, using any is considered unsafe because it bypasses the compiler's type checking.

To fix the issue, we should ensure that stage is treated as a string before performing operations that are specific to strings, such as calling includes. This can be done by asserting the type of stage where it's being used.

Here's the code suggestion to fix the issue:

Suggested change

	if (['new', 'old'].includes(stage)) {
	if (['new', 'old'].includes(stage as string)) {

By using a type assertion (as string), we're telling TypeScript that we're certain stage is a string, which should satisfy the linter's type safety check. However, it is important to note that using type assertions bypasses the compiler's type checking and should be used with care. If there's a chance that stage could be something other than a string, additional runtime checks should be implemented to ensure safety.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: 'message' is defined but never used.

The issue that ESLint is pointing out is that within the type definition of validTargetFunc, the parameter message is defined, but it is never used in the function signature. This might be misleading because it suggests that the function takes an argument that it actually does not use, which could be a sign of incomplete implementation or an unnecessary definition.

To resolve this issue, we can either implement the usage of message within the functions that will use this type or, if the parameter is not needed, remove it from the type definition.

Assuming that message should indeed be a parameter for functions of type validTargetFunc, but the current codebase does not yet use it, I would suggest keeping the parameter in the type definition and ensuring that functions of this type will use it in the future. However, if the parameter is unnecessary, the following suggestion removes it:

Suggested change

	type validTargetFunc = (message: { type: any; element?: ElementTypes }) => boolean;
	type validTargetFunc = () => boolean;

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .frame on an any value.

The issue identified by ESLint is that the element object is implicitly typed as any, which is a type that TypeScript uses to represent a value that can be anything. When you access the frame property of element, TypeScript cannot guarantee that frame actually exists on element, because any bypasses the compiler's type checking. This can potentially lead to runtime errors if frame is not a property of element.

To fix this issue, you should define an interface or type that describes the structure of element, including the frame property and its type. Then, you can use this interface or type to type element properly, which should resolve the ESLint error.

Here's a single line change that assumes you have an interface or type named ElementType that includes a frame property:

Suggested change

	element.frame.session = session;
	value.elements.transacting.forEach((element: ElementType) => {

Please note that you will need to define the ElementType interface or type somewhere in your codebase if you haven't already. Here's an example of what that interface might look like:

        interface FrameType {
          apiKey?: string;
          styles?: any; // Replace `any` with a more specific type if possible
          placeholders?: any; // Replace `any` with a more specific type if possible
          metadata?: any; // Replace `any` with a more specific type if possible
          removeEventListeners?: any; // Replace `any` with a more specific type if possible
          feeMode?: any; // Replace `any` with a more specific type if possible
          amount?: any; // Replace `any` with a more specific type if possible
          session?: any; // Replace `any` with a more specific type if possible
          processedElements?: any[]; // Replace `any` with a more specific type if possible
          readyPort?: any; // Replace `any` with a more specific type if possible
          // ... other properties of frame
        }
        
        interface ElementType {
          containerId: string;
          frame: FrameType;
          // ... other properties of element
        }

After defining the interface, ensure that the objects in value.elements.transacting confirm to the ElementType interface, and the ESLint error should be resolved.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe assignment of an any value.

The issue that ESLint is pointing out is related to the use of TypeScript's any type. The any type is a way to opt-out of TypeScript's static type checking, which means that you can assign anything to it and it will not complain. However, this defeats the purpose of using TypeScript, which is to provide a type-safe environment.

In the line let stage = keyParts[1];, the variable keyParts is implicitly of type any because it comes from splitting the key parameter, which is also typed as any. This means that the assignment to stage is unsafe because keyParts[1] could be anything – not necessarily a string or even defined.

To fix this issue, we should first make sure that key is of type string before splitting it. Since the validate function is intended to check this, we should ensure that validate is called before the split operation. However, assuming that validate is correctly implemented and used, we can add a type assertion to the keyParts variable to indicate to TypeScript that we know the type of the contents after the split operation.

Here's the single line change suggestion to add a type assertion:

Suggested change

	let stage = keyParts[1];
	const keyParts = key.split('-') as string[];

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access ['pt-token'] on an any value.

The issue that ESLint is reporting is that the member access token['pt-token'] is being performed on a value that has an any type. In TypeScript, any is a type that can represent any JavaScript value with no constraints. When we use any, we lose the benefits of TypeScript's type safety. Accessing properties on an any type value is unsafe because it bypasses the compiler checks and can lead to runtime errors if the property doesn't exist or is of an unexpected type.

To fix this issue, we should avoid using any and instead define a proper type for the token object. Assuming that getData function returns a promise that resolves to an object with a known structure, we can define an interface or type for it.

Here's the code suggestion to define the type for the token and use it:

    interface TokenResponse {
      'pt-token'?: string;
      origin?: string;
      challengeOptions?: object;
    }
    
    const token: TokenResponse = await getData(transactionEndpoint, apiKey);

Please note that in a real-world scenario, you would need to ensure that the getData function is typed to return a Promise<TokenResponse> to match this interface. The interface TokenResponse is designed with optional properties to reflect the fact that pt-token might not always be present, which is why you're checking for its existence in the if statement.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Do not access Object.prototype method 'isPrototypeOf' from target object.

Suggested change

	return obj && DataView.prototype.isPrototypeOf(obj);
	return obj && Object.prototype.isPrototypeOf.call(DataView.prototype, obj);

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe argument of type any assigned to a parameter of type string.

The issue identified by ESLint is that the feeMode parameter is of type any, which is not safe because it disables TypeScript's static type checking. When using .includes(), the expected type of the elements in the array should match the type of the argument being checked. Since common.MERCHANT_FEE and common.SERVICE_FEE are likely strings, feeMode should also be typed as string to ensure type safety.

Here's the suggested line change to fix the issue:

Suggested change

	if (![common.MERCHANT_FEE, common.SERVICE_FEE].includes(feeMode)) {
	const isValidFeeMode = (feeMode: string): ErrorResponse | null => {

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium Best Practice issue: Unnecessary conditional, value is always truthy.

The ESLint linter is indicating that the condition in the line if (onError) tagFrame.onError = onError; is unnecessary because it believes onError will always be truthy. However, this may not actually be the case; the conditional is there to check if the onError callback is provided before assigning it to tagFrame.onError.

If onError is indeed optional and can be undefined or null, then the linter's warning is a false positive, possibly due to incorrect type information or a misconfiguration of the linter. In this case, you would want to ensure that onError is correctly typed as an optional parameter and that ESLint understands this.

However, if onError is always provided and the linter is correct, then the conditional is unnecessary and you can directly assign onError to tagFrame.onError without checking it first. The following code suggestion assumes that the linter is correct and that onError is always truthy:

Suggested change

	if (onError) tagFrame.onError = onError;
	tagFrame.onError = onError;

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .tax_amt on an any value.

The issue here is that l3DataSummary is typed as any, which means TypeScript's type checking is effectively turned off for this variable. Accessing properties like .tax_amt on a variable of type any can lead to runtime errors if those properties don't exist, since TypeScript won't be able to catch these issues at compile time.

To fix this issue, you should avoid using any and instead define a more specific type that describes the shape of l3DataSummary. If you must use any due to the nature of the code and you are sure that the property access is safe, you can use an optional chaining operator (?.) to prevent runtime errors if the property is undefined or null. However, this is just a workaround and does not solve the underlying issue of using any.

Here's a single line change to use optional chaining:

Suggested change

	if (l3DataSummary.tax_amt && !validate(l3DataSummary.tax_amt, 'number')) {
	if (l3DataSummary?.tax_amt && !validate(l3DataSummary.tax_amt, 'number')) {

This change will ensure that the property access on l3DataSummary is safe, but it's important to note that the real fix should involve replacing any with a proper type definition for l3DataSummary.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Use "@ts-expect-error" instead of "@ts-ignore", as "@ts-ignore" will do nothing if the following line is error-free.

Suggested change

	// @ts-ignore this will just set receipt description to undefined if it doesn't exist
	// @ts-expect-error this will just set receipt description to undefined if it doesn't exist

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .dest_postal_code on an any value.

The issue here is that l3DataSummary is being treated as an any type, which means TypeScript does not have any specific type information for this object. Accessing a property on an any type is considered unsafe because TypeScript cannot verify that the property exists, is of the expected type, or that it's being used correctly. This can lead to runtime errors if the assumptions about the structure of l3DataSummary are incorrect.

To fix this issue, you should define an interface or a type for l3DataSummary that specifies the expected structure of the object, including the dest_postal_code property as a string. This way, TypeScript can enforce type safety and the linter will not complain about unsafe member access.

Here's a single line change that assumes you have an interface L3DataSummary defined elsewhere in your code:

Suggested change

	if (l3DataSummary.dest_postal_code && !validate(l3DataSummary.dest_postal_code, 'string')) {
	if (l3DataSummary.dest_postal_code && !validate((l3DataSummary as L3DataSummary).dest_postal_code, 'string')) {

By using a type assertion with as L3DataSummary, you're telling TypeScript that you know l3DataSummary has the structure defined by the L3DataSummary interface. However, keep in mind that you should have the L3DataSummary interface defined with the appropriate properties to make this solution work. If it's not already defined, you'll need to create it based on the known structure of l3DataSummary.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .containerId on an any value.

The issue that ESLint has identified here is that the property .containerId is being accessed on an object element which has an implicit any type. In TypeScript, using the any type is generally discouraged because it bypasses the compiler's type checking. Accessing properties on an any type is considered unsafe because it assumes the property exists and is of the expected type, which may not be the case, and this could lead to runtime errors.

To fix this issue, you should define a more specific type for the element object that includes the containerId property with the expected type (for example, if containerId is expected to be a string, the property should be typed as such).

Assuming you have a type ElementType that includes a containerId of type string, you would modify the forEach callback function to explicitly type the element parameter as ElementType. Here is the code suggestion:

Suggested change

	const container = document.getElementById(element.containerId);
	value.elements.transacting.forEach((element: ElementType) => {

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Array type using 'Array' is forbidden. Use 'T[]' instead.

Suggested change

	transacting: Array<keyof achElementIds>;
	transacting: (keyof achElementIds)[];

[codacy-production]

Codacy has a fix for the issue: Array type using 'Array' is forbidden. Use 'T[]' instead.

Suggested change

	transacting: Array<'card-present'>;
	transacting: 'card-present'[];

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe return of an any typed value.

The issue identified by ESLint is that the arrow function transacting => transacting.type is returning a value that is implicitly typed as any. In TypeScript, the any type is a way to opt-out of the type-checking system, which means that no compile-time checks are performed on operations involving any typed values. This can lead to runtime errors that are hard to track down because TypeScript can't help you with type safety.

To resolve this issue, you should explicitly define the type of transacting so that TypeScript knows what type is expected to be. Assuming that transacting is an object with a property type of a certain type (let's say string for this example), you can annotate the parameter with that type.

Here's the single line change suggestion to fix the issue:

Suggested change

	transacting => transacting.type,
	transacting => transacting.type as string,

Alternatively, if there's a defined interface or type for the transacting object, you should use that instead of string. For example, if there's an interface TransactingElement with a type property, you would write:

Suggested change

	transacting => transacting.type,
	transacting => (transacting as TransactingElement).type,

This tells TypeScript what the structure of transacting is expected to be, thus avoiding the unsafe return of an any typed value.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Unexpected any. Specify a different type.

Suggested change

	export const buttonClickTypeMessage = (message: { type: any }) =>
	export const buttonClickTypeMessage = (message: { type: unknown }) =>

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe assignment of an any value.

The issue here is that TypeScript's @ts-ignore directive is being used to suppress a type error that occurs when assigning a value that could potentially be of type any to a property that is expected to be a string. TypeScript is a statically typed language, and using any bypasses the compiler's type checking, which is not safe and can lead to runtime errors.

The unsafe assignment happens because the expression (metadata['pay-theory-reference'] as string) is casting the value to a string without actually checking if it is a string. If metadata['pay-theory-reference'] is not a string, this could lead to unexpected behavior.

To fix this issue, we should perform a runtime check to ensure that the value is indeed a string before assigning it. If it's not a string, we should provide a fallback value that is a string (e.g., an empty string) or handle the case appropriately. Here's how you could do that:

Suggested change

	reference: inputParams.reference || (metadata['pay-theory-reference'] as string), //@ts-ignore this will just set send receipt to undefined if it doesn't exist
	reference: typeof inputParams.reference === 'string' ? inputParams.reference : (typeof metadata['pay-theory-reference'] === 'string' ? metadata['pay-theory-reference'] : undefined),

This suggestion uses a ternary operator to check if inputParams.reference is a string, and if not, it then checks if metadata['pay-theory-reference'] is a string before assigning it. If neither value is a string, it defaults to undefined, which is a safe fallback for a string property that may not be present. This way, we avoid using any and ensure type safety.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Unexpected any. Specify a different type.

Suggested change

	export const cashObserver = (cb: (value: any) => void) =>
	export const cashObserver = (cb: (value: unknown) => void) =>

[codacy-production]

Codacy has a fix for the issue: Do not access Object.prototype method 'isPrototypeOf' from target object.

Suggested change

	return obj && DataView.prototype.isPrototypeOf(obj);
	return obj && Object.prototype.isPrototypeOf.call(DataView.prototype, obj);

[codacy-production]

Codacy has a fix for the issue: Unexpected any. Specify a different type.

Suggested change

	export const stateTypeMessage = (message: { type: any }) =>
	export const stateTypeMessage = (message: { type: unknown }) =>

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unexpected character ('}' (code 125)): was expecting double-quote to start field name

The issue here is that there's a trailing comma after the last key-value pair in the JSON object, which is not allowed in the JSON format. JSON requires that the last element in an object or array should not be followed by a comma.

Here's the single line change to fix the issue:

Suggested change

	}
	"moduleResolution": "node"

By removing the trailing comma, the JSON becomes properly formatted and should no longer raise a linting error from Jackson Linter.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Array type using 'Array' is forbidden. Use 'ElementTypes[]' instead.

Suggested change

	protected _requiredValidFields: Array<ElementTypes>;
	protected _requiredValidFields: ElementTypes[];

[codacy-production]

❌ Codacy found a critical Error Prone issue: Avoid referencing unbound methods which may cause unintentional scoping of this.
If your function does not access this, you can annotate it with this: void, or consider using an arrow function instead.

The issue here is that the method this.handleFeeCalcReconnect is passed as a callback without being properly bound to the this context of the class. When the callback is called, this will not refer to the class instance, which can lead to bugs if this.handleFeeCalcReconnect uses this to access class properties or methods.

To fix this issue, you can use an arrow function to preserve the this context. Here's the single line code suggestion:

      (event: { type: any }) => event.type === 'pt-static:fee_calc_reconnect',
      (event) => this.handleFeeCalcReconnect(event),

This change creates an arrow function that calls this.handleFeeCalcReconnect with the correct this binding. Arrow functions do not have their own this context; they inherit this from the surrounding scope, which in this case is the class instance.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe argument of type any assigned to a parameter of type string.

The issue here is that TypeScript, which is a statically typed superset of JavaScript, expects that the argument passed to document.getElementById be of type string. However, the linter has detected that sibling.containerId is of type any, which is not safe because it could potentially be a non-string value at runtime, causing unexpected behavior or errors.

To fix this issue, we need to ensure that sibling.containerId is treated as a string when passed to document.getElementById. This can be done by explicitly casting sibling.containerId to a string or by ensuring that its type is known to be a string at compile-time. If we are certain that sibling.containerId will always be a string, we can use TypeScript's type assertion feature to cast it.

Here's the single line change with a type assertion:

Suggested change

	const container = document.getElementById(sibling.containerId);
	const container = document.getElementById(sibling.containerId as string);

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .frame on an any value.

The issue identified by ESLint is that the property frame is being accessed on the variable element, which is implicitly typed as any. In TypeScript, the any type is essentially a way to opt-out of the type-checking system, which means that no compile-time checks are performed on operations involving values of this type. This can lead to runtime errors if the frame property does not exist on the element object or if it is accessed in an incorrect way.

To fix this issue, you should provide a more specific type for element that includes the frame property with the expected structure. If you do not have a type already defined for this purpose, you would need to define one. However, for the sake of this scenario, let's assume that you have a type called ElementType that has the frame property. The single line change would be to add a type assertion when element is being used.

Here is the suggested code change:

Suggested change

	element.frame.session = session;
	value.elements.transacting.forEach((element: ElementType) => {

This change assumes that ElementType is the correct type that includes a frame property with the appropriate sub-properties. If ElementType is not the correct type, you should replace it with the appropriate type that reflects the structure of element.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Unexpected any. Specify a different type.

Suggested change

	export const buttonReadyTypeMessage = (message: { type: any }) =>
	export const buttonReadyTypeMessage = (message: { type: unknown }) =>

[codacy-production]

Codacy has a fix for the issue: Expected indentation of 4 spaces

Suggested change

	w +
	w +

[codacy-production]

⚠️ Codacy found a medium Best Practice issue: Unnecessary conditional, value is always truthy.

The issue that ESLint is reporting is that the onCancel callback is always considered truthy in the context of the conditional check. This might be because onCancel is either always defined or it is not optional, so checking for its existence is unnecessary.

However, without the broader context of how onCancel is defined, it's hard to provide an accurate suggestion. If onCancel is indeed always defined, then the conditional check is indeed unnecessary and you can directly call onCancel() without checking its existence.

Here's the suggested code change:

Suggested change

	if (onCancel) onCancel();
	onCancel();

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .frame on an any value.

The issue here is that TypeScript's type system cannot guarantee the safety of accessing the .frame property on element because element is implicitly typed as any. When a variable is of type any, TypeScript does not perform any type checking on it, which means that accessing properties or calling methods on such a variable can potentially lead to runtime errors if those properties or methods do not exist.

To address this issue, you should define a more specific type for element that includes the frame property with the expected structure. Assuming frame is an object with a certain known structure, you would define an interface or type for it and then use type assertion to tell TypeScript that element is of that type.

Here's a single line change that uses type assertion for the element variable before accessing its frame property:

Suggested change

	element.frame.amount = amount;
	(element as ElementType).frame.amount = amount;

In this suggestion, ElementType should be a type or interface that you've defined elsewhere in your code that includes the frame property with its expected structure. If ElementType is not already defined, you would need to define it based on the structure you expect element to have. Here's an example of how you might define it:

        interface FrameType {
          apiKey?: string;
          styles?: any; // Replace 'any' with a more specific type if possible
          placeholders?: any; // Replace 'any' with a more specific type if possible
          metadata?: any; // Replace 'any' with a more specific type if possible
          removeEventListeners?: any; // Replace 'any' with a more specific type if possible
          feeMode?: any; // Replace 'any' with a more specific type if possible
          amount?: any; // Replace 'any' with a more specific type if possible
          session?: any; // Replace 'any' with a more specific type if possible
          processedElements?: any[]; // Replace 'any' with a more specific type if possible
          readyPort?: any; // Replace 'any' with a more specific type if possible
        }
        
        interface ElementType {
          containerId: string;
          frame: FrameType;
        }

By using type assertion, you're informing TypeScript that you know more about the type than it can infer on its own, which helps to avoid potential runtime errors and allows TypeScript to provide better type checking.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .frame on an any value.

The issue here is that TypeScript's type-checking mechanism cannot guarantee the safety of the member access operation on sibling.frame because sibling is implicitly typed as any. Accessing properties on a value of type any bypasses compile-time type checks, which can lead to runtime errors if the object does not have the expected structure.

To resolve this issue, we should explicitly type the siblings array so that TypeScript knows the shape of the objects it contains, and can ensure that the .frame property access is type-safe.

Assuming that we have a type definition for the objects contained within the siblings array, such as SiblingType, which includes a frame property, the code suggestion would be to add a type annotation to the map callback parameter:

Suggested change

	sibling.frame.placeholders = placeholders;
	const siblingsElements = value.elements.siblings.map((element: SiblingType) => element.frame);

Note that you need to define SiblingType beforehand to match the expected structure of the siblings' objects, including the frame property. If SiblingType is not already defined, you would need to create an appropriate interface or type.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Use "@ts-expect-error" to ensure an error is actually being suppressed.

Suggested change

	// @ts-ignore this will just set receipt description to undefined if it doesn't exist
	// @ts-expect-error this will just set receipt description to undefined if it doesn't exist

[codacy-production]

❌ Codacy found a critical Error Prone issue: 'error' is defined but never used.

The issue here is that the error parameter in the arrow function within errorObserver is defined but it's never used within the function body. This typically occurs when the function has been defined with parameters that are not utilized when the function is executed, which can lead to confusion or errors in the code. However, in this case, the error parameter is indeed used when calling the callback cb, so the ESLint error might be a false positive or the result of an incomplete code snippet.

If we were to assume that there is indeed an issue and the error parameter is not supposed to be used, we could modify the function to ignore the parameter. But since the error parameter is used for the callback, the ESLint issue might be incorrect. If the error persists and you want to explicitly indicate that the parameter is intentionally unused, you could prefix it with an underscore, which is a common convention to indicate unused variables. However, this change is not necessary if the parameter is being used as it is in the provided code snippet.

Here's the code suggestion to prefix the parameter with an underscore to satisfy the linter, assuming the error message is accurate:

export const errorObserver = (cb: (error: string) => void) =>
  messaging.handleMessage(
    messaging.errorTypeMessage,
    (message: { error: string; type: string }) => {
      cb(message.error);
    },
  );

Please note that this suggestion is based on the assumption that the ESLint error message is accurate, which doesn't seem to be the case given the provided code snippet. If the error parameter is indeed being used as intended, then no change is necessary, and you may need to review your ESLint configuration or ensure that the rest of the code is provided to accurately diagnose the issue.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe assignment of an any value.

The issue described by ESLint, "Unsafe assignment of an any value," typically occurs when a value with the any type is assigned to a variable or property, and TypeScript's strict type checking is not being enforced. This can lead to runtime errors that are not caught at compile time because the any type is essentially opting out of type checking.

In the provided code snippet, the issue seems to be that this.handleFeeCalcReconnect is being assigned a value that has an any type. However, without additional context or the actual implementation of handleFeeCalcReconnect, it's hard to provide a precise solution. Assuming handleFeeCalcReconnect is a method of the class that needs to be bound to the current instance (this), the issue might be related to the method itself not being typed correctly.

To address the ESLint error, you would need to ensure that handleFeeCalcReconnect is properly typed. If the method is indeed part of the class and not typed correctly, you should define its type within the class. However, since the error message is about the assignment, and we can't change the method signature within a single line, the best we can do is to add a type assertion to the assignment to satisfy ESLint that we know what we're doing. This is not a true fix but rather a way to silence the linter for this line, assuming we know that the method is correctly implemented and typed elsewhere in the code.

Here's how you can assert the type of this.handleFeeCalcReconnect to be a specific function type instead of any:

Suggested change

	this.handleFeeCalcReconnect = this.handleFeeCalcReconnect.bind(this);
	this.handleFeeCalcReconnect = this.handleFeeCalcReconnect.bind(this) as unknown as (/* function type here */);

Replace /* function type here */ with the actual function type of handleFeeCalcReconnect.

Please note that this suggestion is a workaround to silence the linter and should only be used if you are confident that the method is properly typed elsewhere in your codebase. The proper fix would involve ensuring that handleFeeCalcReconnect has a defined type that is not any.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .error on an any value.

The issue identified by ESLint is that the message object is implicitly typed as any, which means TypeScript does not have any type information about it. Accessing the .error property on an any type is considered unsafe because there is no guarantee that the property exists, which could potentially lead to runtime errors if message doesn't have an error property.

To fix this issue, you should define a type for the message object that includes the error property. Assuming that message is expected to have an error property of type string, you could create an interface or type for it. However, since the task requires a single line change, we'll use a type assertion to specify the expected type of the message object.

Here's the suggested code change:

Suggested change

	onError(message.error);
	onError((message as { error: string }).error);

This change tells TypeScript that we expect message to be an object with a property error of type string, which safely allows us to access message.error.

---

This comment was generated by an experimental AI tool.

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe member access .error on an any value.

The issue identified by ESLint is that the expression e?.error || e?.message || e is attempting to access properties .error and .message on a value e that could potentially be of type any. In TypeScript, the any type is considered unsafe because it bypasses the compiler's type checking. When you access properties on a value of type any, TypeScript cannot guarantee that those properties exist, which could lead to runtime errors if those properties are not present on the object.

To fix this issue, we should first ensure that the error e is of a type that is known to have the properties .error and .message. If we cannot guarantee the type of e, we should at least narrow down the type to something safer than any before accessing its properties.

Here's a possible code suggestion to fix the issue:

Suggested change

	return common.handleError(e?.error || e?.message || e);
	return common.handleError('error' in e ? e.error : 'message' in e ? e.message : e);

This code uses the in operator to check if the properties .error and .message exist on the object e before trying to access them. It's a safer approach because it does not assume the presence of these properties and will default to e itself if neither property is found. This change assumes that e is an object; if e could also be a primitive, further checks would be needed.

---

This comment was generated by an experimental AI tool.

[codacy-production]

Codacy has a fix for the issue: Unexpected any. Specify a different type.

Suggested change

	export const checkoutBarcodeReceivedTypeMessage = (message: { type: any }) =>
	export const checkoutBarcodeReceivedTypeMessage = (message: { type: unknown }) =>

[codacy-production]

❌ Codacy found a critical Error Prone issue: Unsafe return of an any typed value.

The issue here is that the token object returned by the getData function is implicitly typed as any. In TypeScript, the any type is considered unsafe because it bypasses the compiler's type checking. Since the token object is expected to have a specific shape, including the 'pt-token' string property, we should define an interface or type for it to ensure type safety.

To fix the issue, we need to define a type or interface that describes the expected structure of the token object and then use that type to annotate the return value of the getData function. Since the code fragment provided doesn't include the getData function definition or the exact structure of the token, I'll assume a generic interface for the purpose of this example. You will need to adjust the interface according to the actual data structure.

Here's the single line change to add a type annotation to the returned token:

Suggested change

	return token;
	const token = await getData(transactionEndpoint, apiKey) as TokenType;

In this suggestion, TokenType should be a type or interface that you've defined elsewhere in your codebase that matches the structure of the object returned by getData. For example:

      interface TokenType {
        'pt-token': string;
        // ... other properties expected in the token object
      }

Remember to replace TokenType with the actual type or interface that corresponds to the data structure returned by getData.

---

This comment was generated by an experimental AI tool.