When running the fdk validate and fdk pack commands on an app, the Freshworks Developer Kit (FDK) performs linting on the app’s source code and reports possible errors. The rules that the linter goes through are a collection of best practices that the app should adhere to. Violations are displayed based on the severity category (Warning/Error) and they must be fixed before the app is submitted for approval to the Freshworks Marketplace.
Adhering to these rules ensures that the app conforms to the quality and security standards of a Freshworks Marketplace app.
Note:You can use the $fdk validate --fix command to auto-fix no-debugger and no-unreachable errors.
Avoid cross scope variable assignment (no-cross-scope-assign)
Category: Warning
Description: When writing asynchronous code, avoid declaring and assigning variables in different scopes as this can create subtle race condition bugs.
No unhandled promises (no-unhandled-promise)
Category: Warning
Description: Forgetting to handle promise rejections can lead to ambiguous behavior in the application.
Disallow non-Request API calls in the front end (no-non-client-request-model)
Category: Warning
Description: Ensure that REST API calls are made from front-end apps using the Request method to subvert many security issues and to work within the CORS policy of a browser.
Disallow logging just the error object during promise rejections (no-logging-rejections)
Category: Warning
Description: In promise rejection handlers, logging only the error object is not sufficient. The error should be reported (via notifications) to users/agents, in layperson's terms, so that they can undertake subsequent actions.
Remove unused dependencies and avoid the use of unlisted dependencies (no-dependency-mismatch)
Category: Error
Description: In serverless applications, avoid using dependencies that are declared but left unused and dependencies that are used but undeclared.
Limit cyclomatic complexity (complexity)
Category: Warning
Description: Cyclomatic complexity measures the number of linearly independent paths through a program's source code. The current threshold is 7.
Limit the depth of nested callbacks (max-nested-callbacks)
Category: Warning
Description: In asynchronous programming, when using a callback function, a common pitfall is nesting callbacks. The deeper callbacks are nested, the more difficult it is to read the code. The threshold of nested callbacks is 4.
Enforce callback error handling (handle-callback-err)
Category: Warning
Description: The callback pattern, typically used in asynchronous programming, expects an error object or null as the first argument of the callback. Forgetting to handle this can lead to ambiguous behavior in the application.
Disallow use of caller/callee (no-caller)
Category: Warning
Description: The use of arguments.caller and arguments.callee is deprecated in JavaScript. Avoid using these in ECMAScript 5, in strict mode.
Correct Approach
Avoid using arguments.caller and arguments.callee.
Disallow process.env (no-process-env)
Category: Warning
Description: The process.env object in Node.js is used to store deployment or configuration parameters. Littering it throughout a project can lead to maintenance issues, as it is another kind of global dependency.
Correct Approach
Avoid using process.env.
Disallow unused variables (no-unused-vars)
Category: Error
Description: Variables that are declared and not used anywhere in the code might be residues of incomplete refactoring. Retaining these variables takes up space in the code and can lead to confusion.
Correct Approach
Don't declare variables that are not going to be used in the code.
Disallow eval() (no-eval)
Category: Error
Description: Avoid using JavaScript's eval() function, on untrusted code, as it can open a program to several different injection attacks.
Correct Approach
Strictly avoid eval().
Disallow use of alert (no-alert)
Category: Error
Description: JavaScript's alert, confirm, and prompt functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation.
Correct Approach
Don't use alert, confirm, or prompt in front-end code. Obtain inputs via forms or Interface methods (modals or confirmation dialog) only.
Disallow the use of debugger (no-debugger)
Category: Error
Description: In the production code, avoid using debugger; as it stops the browser from running code and opens an appropriate debugger.
Correct Approach
Don't use debugger; in production apps.
Disallow unreachable code (no-unreachable)
Category: Error
Description: The return, throw, break, and continue statements unconditionally exit a block of code and any statements after them cannot be executed. Avoid having unreachable statements.
Disallow empty functions (no-empty-function)
Category: Error
Description: Empty functions can reduce code readability because readers need to guess whether it is intentional or not. Writing a clear comment for empty functions is good practice.
Third-party resource: ESLint