Lint class member order (#872)

Author: edwardfoyle

.changeset/thirty-onions-hear.md

@@ -0,0 +1,2 @@
+---
+---

.eslintrc.cjs

@@ -83,6 +83,7 @@ module.exports = {
     ],
     '@typescript-eslint/restrict-template-expressions': 'error',
     '@typescript-eslint/consistent-type-definitions': ['error', 'type'],
+    '@typescript-eslint/member-ordering': 'error',
     '@shopify/prefer-early-return': 'error',
     'check-file/filename-blocklist': [
       'error',

.prettierignore

@@ -11,3 +11,4 @@ expected-cdk-out
 .changeset/pre.json
 concurrent_workspace_script_cache.json
 scripts/components/api-changes-validator/test-resources/working-directory
+test-projects

packages/auth-construct/src/construct.ts

@@ -217,6 +217,26 @@ export class AmplifyAuth
     );
   }
 
+  /**
+   * Attach a Lambda function trigger handler to the UserPool in this construct
+   * @param event - The trigger event operation
+   * @param handler - The function that will handle the event
+   */
+  addTrigger = (
+    event: TriggerEvent,
+    handler: IFunction | AmplifyFunction
+  ): void => {
+    if ('resources' in handler) {
+      this.userPool.addTrigger(
+        UserPoolOperation.of(event),
+        handler.resources.lambda
+      );
+    } else {
+      // handler is an IFunction
+      this.userPool.addTrigger(UserPoolOperation.of(event), handler);
+    }
+  };
+
   /**
    * Create Auth/UnAuth Roles
    * @returns DefaultRoles
@@ -813,24 +833,4 @@ export class AmplifyAuth
       payload: output,
     });
   };
-
-  /**
-   * Attach a Lambda function trigger handler to the UserPool in this construct
-   * @param event - The trigger event operation
-   * @param handler - The function that will handle the event
-   */
-  addTrigger = (
-    event: TriggerEvent,
-    handler: IFunction | AmplifyFunction
-  ): void => {
-    if ('resources' in handler) {
-      this.userPool.addTrigger(
-        UserPoolOperation.of(event),
-        handler.resources.lambda
-      );
-    } else {
-      // handler is an IFunction
-      this.userPool.addTrigger(UserPoolOperation.of(event), handler);
-    }
-  };
 }

packages/backend-deployer/src/cdk_deployer.ts

@@ -67,6 +67,59 @@ export class CDKDeployer implements BackendDeployer {
     return this.tryInvokeCdk(InvokableCommand.DESTROY, backendId, ['--force']);
   };
 
+  /**
+   * Wrapper for the child process executor. Helps in unit testing as node:test framework
+   * doesn't have capabilities to mock exported functions like `execa` as of right now.
+   */
+  executeChildProcess = async (
+    command: string,
+    commandArgs: string[],
+    options: { printStdout: boolean } = { printStdout: true }
+  ) => {
+    // We let the stdout and stdin inherit and streamed to parent process but pipe
+    // the stderr and use it to throw on failure. This is to prevent actual
+    // actionable errors being hidden among the stdout. Moreover execa errors are
+    // useless when calling CLIs unless you made execa calling error.
+    let aggregatedStderr = '';
+    const aggregatorStderrStream = new stream.Writable();
+    aggregatorStderrStream._write = function (chunk, encoding, done) {
+      aggregatedStderr += chunk;
+      done();
+    };
+
+    const childProcess = execa(command, commandArgs, {
+      stdin: 'inherit',
+      stdout: 'pipe',
+      stderr: 'pipe',
+
+      // Piping the output by default strips off the color. This is a workaround to
+      // preserve the color being piped to parent process.
+      extendEnv: true,
+      env: { FORCE_COLOR: '1' },
+    });
+    childProcess.stderr?.pipe(aggregatorStderrStream);
+
+    if (options?.printStdout) {
+      childProcess.stdout?.pipe(process.stdout);
+    }
+
+    const cdkOutput = { deploymentTimes: {} };
+    if (childProcess.stdout) {
+      await this.populateCDKOutputFromStdout(cdkOutput, childProcess.stdout);
+    }
+
+    try {
+      await childProcess;
+      return cdkOutput;
+    } catch (error) {
+      // swallow execa error which is most of the time noise (basically child exited with exit code...)
+      // bubbling this up to customers add confusion (Customers don't need to know we are running IPC calls
+      // and their exit codes printed while sandbox continue to run). Hence we explicitly don't pass error in the cause
+      // rather throw the entire stderr for clients to figure out what to do with it.
+      throw new Error(aggregatedStderr);
+    }
+  };
+
   private invokeTsc = async (deployProps?: DeployProps) => {
     if (!deployProps?.validateAppSources) {
       return;
@@ -172,59 +225,6 @@ export class CDKDeployer implements BackendDeployer {
     return await this.executeChildProcess('npx', cdkCommandArgs);
   };
 
-  /**
-   * Wrapper for the child process executor. Helps in unit testing as node:test framework
-   * doesn't have capabilities to mock exported functions like `execa` as of right now.
-   */
-  executeChildProcess = async (
-    command: string,
-    commandArgs: string[],
-    options: { printStdout: boolean } = { printStdout: true }
-  ) => {
-    // We let the stdout and stdin inherit and streamed to parent process but pipe
-    // the stderr and use it to throw on failure. This is to prevent actual
-    // actionable errors being hidden among the stdout. Moreover execa errors are
-    // useless when calling CLIs unless you made execa calling error.
-    let aggregatedStderr = '';
-    const aggregatorStderrStream = new stream.Writable();
-    aggregatorStderrStream._write = function (chunk, encoding, done) {
-      aggregatedStderr += chunk;
-      done();
-    };
-
-    const childProcess = execa(command, commandArgs, {
-      stdin: 'inherit',
-      stdout: 'pipe',
-      stderr: 'pipe',
-
-      // Piping the output by default strips off the color. This is a workaround to
-      // preserve the color being piped to parent process.
-      extendEnv: true,
-      env: { FORCE_COLOR: '1' },
-    });
-    childProcess.stderr?.pipe(aggregatorStderrStream);
-
-    if (options?.printStdout) {
-      childProcess.stdout?.pipe(process.stdout);
-    }
-
-    const cdkOutput = { deploymentTimes: {} };
-    if (childProcess.stdout) {
-      await this.populateCDKOutputFromStdout(cdkOutput, childProcess.stdout);
-    }
-
-    try {
-      await childProcess;
-      return cdkOutput;
-    } catch (error) {
-      // swallow execa error which is most of the time noise (basically child exited with exit code...)
-      // bubbling this up to customers add confusion (Customers don't need to know we are running IPC calls
-      // and their exit codes printed while sandbox continue to run). Hence we explicitly don't pass error in the cause
-      // rather throw the entire stderr for clients to figure out what to do with it.
-      throw new Error(aggregatedStderr);
-    }
-  };
-
   private populateCDKOutputFromStdout = async (
     output: DeployResult | DestroyResult,
     stdout: stream.Readable

packages/backend-secret/src/secret_error.ts

@@ -23,6 +23,16 @@ export class SecretError extends Error {
     this.httpStatusCode = options?.httpStatusCode;
   }
 
+  /**
+   * Creates a secret error from an underlying cause.
+   */
+  static createInstance = (cause: Error): SecretError => {
+    if (cause instanceof SSMServiceException) {
+      return SecretError.fromSSMException(cause);
+    }
+    return new SecretError(cause.message, { cause });
+  };
+
   /**
    * Creates a secret error from an SSM exception.
    */
@@ -36,14 +46,4 @@ export class SecretError extends Error {
       httpStatusCode: ssmException.$metadata.httpStatusCode,
     });
   };
-
-  /**
-   * Creates a secret error from an underlying cause.
-   */
-  static createInstance = (cause: Error): SecretError => {
-    if (cause instanceof SSMServiceException) {
-      return SecretError.fromSSMException(cause);
-    }
-    return new SecretError(cause.message, { cause });
-  };
 }

packages/backend/src/backend_factory.ts

@@ -26,14 +26,15 @@ const rootStackTypeIdentifier = 'root';
 export class BackendFactory<
   T extends Record<string, ConstructFactory<ResourceProvider>>
 > {
-  private readonly stackResolver: StackResolver;
   /**
    * These are the resolved CDK constructs that are created by the inputs to the constructor
    * Used for overriding properties of underlying CDK constructs or to reference in custom CDK code
    */
   readonly resources: {
     [K in keyof T]: ReturnType<T[K]['getInstance']>;
   };
+
+  private readonly stackResolver: StackResolver;
   /**
    * Initialize an Amplify backend with the given construct factories and in the given CDK App.
    * If no CDK App is specified a new one is created