@arcgis/eslint-config 5.2.0-next.99 → 6.0.0-next.1

package/dist/chunks/disabledRules.js

@@ -0,0 +1,6 @@
+function disabledRules(names) {
+  return Object.fromEntries(names.map((name) => [name, "off"]));
+}
+export {
+  disabledRules as d
+};

package/dist/{makePlugin-Cvfc0MLz.js → chunks/makePlugin.js}

@@ -1,5 +1,5 @@
 import { ESLintUtils } from "@typescript-eslint/utils";
-const version = "5.2.0-next.99";
+const version = "1.0.0-0";
 const packageJson = {
   version
 };

package/dist/config/applications.js

@@ -1,35 +1,39 @@
+import { d as disabledRules } from "../chunks/disabledRules.js";
 import config$1 from "./index.js";
+const disabledApplicationRules = [
+  // Not autofixable. Can be annoying
+  "@typescript-eslint/ban-ts-comment",
+  // Less important in apps than in libraries
+  // Though, explicit return type improve TypeScript performance
+  "@typescript-eslint/explicit-function-return-type",
+  // Less important for non-public APIs.
+  // And can be tedious to refactor existing code.
+  "@typescript-eslint/max-params",
+  // No big harm in letting people do this if they want to
+  "@typescript-eslint/no-extraneous-class",
+  // A trade off between developer convenience and code quality
+  "@typescript-eslint/no-floating-promises",
+  // A convenient lazy variant, but less safe
+  "@typescript-eslint/no-unsafe-function-type",
+  // Non-customer-facing code can handle Errors in what way is most convenient
+  "@typescript-eslint/only-throw-error",
+  // Non-customer-facing code can handle Errors in what way is most convenient
+  "@typescript-eslint/prefer-promise-reject-errors",
+  // A trade off between developer convenience and code quality
+  "@typescript-eslint/promise-function-async",
+  // Let developer decide to add or omit it. If not present, creates
+  // worse exception messages.
+  "func-names",
+  // This rule is for consistency between library developers - less important for monolith apps.
+  "id-denylist",
+  // More important for library-exposed symbols than apps
+  "symbol-description"
+];
 const config = [
   ...config$1,
   {
     rules: {
-      // Not autofixable. Can be annoying
-      "@typescript-eslint/ban-ts-comment": "off",
-      // Less important in apps than in libraries
-      // Though, explicit return type improve TypeScript performance
-      "@typescript-eslint/explicit-function-return-type": "off",
-      // Less important for non-public APIs.
-      // And can be tedious to refactor existing code.
-      "@typescript-eslint/max-params": "off",
-      // No big harm in letting people do this if they want to
-      "@typescript-eslint/no-extraneous-class": "off",
-      // A convenient lazy variant, but less safe
-      "@typescript-eslint/no-unsafe-function-type": "off",
-      // Non-customer-facing code can handle Errors in what way is most convenient
-      "@typescript-eslint/only-throw-error": "off",
-      // Non-customer-facing code can handle Errors in what way is most convenient
-      "@typescript-eslint/prefer-promise-reject-errors": "off",
-      // A trade off between developer convenience and code quality
-      "@typescript-eslint/no-floating-promises": "off",
-      // A trade off between developer convenience and code quality
-      "@typescript-eslint/promise-function-async": "off",
-      // Let developer decide to add or omit it. If not present, creates
-      // worse exception messages.
-      "func-names": "off",
-      // This rule is for consistency between library developers - less important for monolith apps.
-      "id-denylist": "off",
-      // More important for library-exposed symbols than apps
-      "symbol-description": "off"
+      ...disabledRules(disabledApplicationRules)
     }
   }
 ];