S1848: CDK new object reported as "useless" code, false positive

Make sure to read this post before raising a thread here:
How to Report a False-positive / False-negative :white_check_mark:

What language is this for? Typescript (likely exists in javascript and ?python? as well)
Which rule? S1848
Why do you believe it’s a false-positive/false-negative?
Often in CDK, you will instantiate a new object and not assign it to a variable. Since a new object maps to a real resource, this is valid. You don’t always do things with those downstream resources.
Using SonarCloud, Sonarlint (vscode, connected to SonarCloud)

How can we reproduce the problem? Give us a self-contained snippet of code (formatted text, no screenshots)

  1. Create a temp CDK project (mkdir temp && cd temp && npx cdk init --language=typescript)
  2. In lib/temp-stack.ts, edit the generated TempStack class as follows
import * as s3 from 'aws-cdk-lib/aws-s3';
export class TempStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'TempBucket', {
    // The code that defines your stack goes here

    // example resource
    // const queue = new sqs.Queue(this, 'TempQueue', {
    //   visibilityTimeout: cdk.Duration.seconds(300)
    // });

The above example is simplistic - You almost always use an s3 bucket elsewhere, so you almost always assign it to a const. However, there are many CDK resources where you do not need to reuse them. Also, in the bin/temp.ts, you instantiate stacks and often do not reference them elsewhere. An example from the generated code is below.

#!/usr/bin/env node
import "source-map-support/register";
import * as cdk from "aws-cdk-lib";
import { TempStack } from "../lib/temp-stack";

const app = new cdk.App();
new TempStack(app, "TempStack", {
  /* If you don't specify 'env', this stack will be environment-agnostic.
   * Account/Region-dependent features and context lookups will not work,
   * but a single synthesized template can be deployed anywhere. */
  /* Uncomment the next line to specialize this stack for the AWS Account
   * and Region that are implied by the current CLI configuration. */
  // env: { account: process.env.CDK_DEFAULT_ACCOUNT, region: process.env.CDK_DEFAULT_REGION },
  /* Uncomment the next line if you know exactly what Account and Region you
   * want to deploy the stack to. */
  // env: { account: '123456789012', region: 'us-east-1' },
  /* For more information, see https://docs.aws.amazon.com/cdk/latest/guide/environments.html */

Hello @dmurawsky and thank you for the feedback,

Regarding the current capabilities of the JS analyzer, we can update the S1848 (constructor-for-side-effects) to ignore the constructors from the aws-cdk-lib/aws-s3 library that produce side effects like new s3.Bucket(...) from your first example.

If you encompass such constructors into a custom class like TempStack, it becomes trickier. I will investigate this and come back to you. Are classes that extend cdk.Stack meant to implement side effects in constructors?


1 Like

I’m not sure I understand what “Are classes that extend cdk.Stack meant to implement side effects in constructors?” means.

We will regularly build our own stacks, and they are often not assigned to a const. One of the main paradigms in CDK is to build your own stacks. Does that answer the question?

Additionally, you will likely want to ignore all constructors from aws-cdk-lib, not just s3. This will be a pervasive problem with any resource in the CDK.

Thank you for the additional information, we have opened a ticket to tackle this issue: Fix FP S1848 (`constructor-for-side-effects`): Make exception for AWS CDK resources · Issue #4357 · SonarSource/SonarJS · GitHub