2.4.2.4 release notes

2.4.2.4

  • Issue 2980 - IC now displays the project's .aerrc file contents, if present, in the Apex test run configuration editor so that it's obvious exactly what command-line options will be used when executing Apex tests via aer. It's still possible to configure additional aer command-line options on a per-run config basis in the run configuration editor as well.
  • Issue 2924 - Added a new deployment Apex test level, RunDependentTests, that is conceptually similar to RunRelevantTests, but the set of tests to be executed is computed by IC before deployment — and then executed using the RunSpecifiedTests test level — instead of being computed by the Salesforce server.
    • There are notable differences in how IC computes transitive dependents vs. how Salesforce computes them (at least at present):
      • IC specifically computes dependent relationships with member-level granularity whereas Salesforce computes them with class-level granularity. This means that if an intermediate dependent member is found, IC will only include transitive dependents of that member whereas Salesforce will include transitive dependents of the entire containing top-level class. This can result in RunRelevantTests executing more tests than RunDependentTests, with the extras generally being unnecessary to validate the original context.
      • IC's transitive dependent calculator takes into account both direct relationships expressed via Apex references and indirect relationships expressed in other metadata types that use Apex, e.g., flows and presentation tier frameworks. This can result in RunDependentTests including tests that are not found by RunRelevantTests.
      • Salesforce will only execute dependent tests for deployment payload members that are modified relative to the server. IC will execute all dependent tests even if nothing has been modified relative to the server. This means that RunRelevantTests is significantly more efficient than RunDependentTests when deploying large payloads where only a small subset of the payload members have actually changed.
    • IC's transitive dependent calculator takes into account @IsTest(critical=true) and @IsTest(testFor=...) annotations, so existing explicit test dependency relationships are properly respected.
    • If you use this new test level and find any issues with missing/incorrect dependents, test execution failures specific to this new test level, etc., please let me know and I'll take care of them.
  • Issue 3010 - IC includes a new Apex code inspection, Access mode validation, that evaluates Apex non-test classes for correct and safe sharing mode and access mode usage.
    • This new inspection is enabled by default and included in the bundled inspection profiles, but if you have an existing inspection profile with Disable new inspections by default enabled, you will need to add it to that inspection profile explicitly.
    • The inspection includes the following configuration options:
      • Check API v67.0+ files only - When enabled, the inspection only applies to Apex classes and triggers with API v67.0 or higher. Enabled by default given the default sharing and access mode behavioral changes introduced in that API version.
      • Check database operations in classes without a sharing mode - When enabled, classes without a sharing mode that perform database operations are reported. Enabled by default.
      • Check system mode database operations in classes without a sharing mode - When enabled, system mode database operations in classes without a sharing mode are reported. Disabled by default.
      • Check user mode database operations in classes without a sharing mode - When enabled, user mode database operations in classes without a sharing mode are reported. Disabled by default.
      • Check static database operations without an acccess mode - When enabled, static database operations without an access mode are reported. Disabled by default.
      • Check dynamic database operations without an acccess mode - When enabled, dynamic database operations without an AccessLevel invocation argument are reported. Disabled by default.
    • As always, if you find false positives or negatives reported by this new inspection, or if you have ideas for how it can be improved, please let me know about them, ideally with concrete examples of issues or omissions.
  • Apex dependents-based test run configurations now include all @IsTest(critical=true)-annotated unit tests in addition to those found via dependents analysis.
  • Significantly improved the way that unit test results are displayed in the correponding Messages tabs when tests are executed as part of deployment. Now test successes and failures are displayed in their own respective sections distinct from deployment successes and failures, and all test results are hyperlinked to the respective source code, either the test method that was executed successfully or the specific line/column for which a test failure was reported.
  • Added full support for Angular UI bundle templates. Note that unlike React, Angular support requires a commercial JetBrains IDE license.
  • Added missing project templates when creating source format projects, specifically agent, angularexternalapp, angularinternalapp, reactexternalapp, and reactinternalapp.
  • Fixed an LWC TypeScript compiler error that could occur when using TypeScript 7+. I recommend using TypeScript 6 due to other potential breaking changes in TypeScript 7, specifically with ESLint, but this should at least ensure that the TypeScript 7 compiler is found and used by the IDE when compiling LWC TypeScript source files.
  • Updated the default/recommended case for Apex annotation attributes to be Camel case, leading lower instead of Camel case, leading upper. Quite frankly, I made a mistake on that specific default originally, and this change is long overdue. Annotations are analogous to classes, and their attributes are analogous to those class' fields. As a result, annotation names should follow ClassName case conventions, and their attributes should follow fieldName case conventions. I've gone back and forth on this particular decision because it changes the default Apex formatter behavior for existing users, but in the end I prefer that the default be correct based on the aforementioned case conventions. If you wish to retain the previous case convention for annotation attributes, e.g., to minimize a potentially noisy (ideally one-time) change to your existing code base, simply change Settings | Editor | Code Style | Apex | Case | Apex | Annotation attribute from Recommended to Camel case, leading upper.