2.2.0.9 release notes

 2.2.0.9

• ApexDoc enhancements ApexDoc is interesting in that there are multiple implementations out there, each with its own set of enhancements, e.g., the original ApexDoc, SfApexDoc (upon which IC2's implementation has historically been based), ApexDocs, and ApexDox VS Code (there are almost certainly others out there). It would be wonderful to see a true unified standard emerge—ideally from Salesforce—but in the interest of providing first-class IDE support for as much of the extended functionality offered by these derivative implementations as possible, I've enhanced IC2's ApexDoc support to include the effective union of these tools' supported features:
  • Support for all known ApexDoc tags including all previously supported tags and the following new (to IC2) tags:
    • @deprecated
    • @example
    • @exception and @throws - both can be used, but in the spirit of consistency one must be configured as the way to document exception handling behavior, and usages of the other are automatically replaced when formatting/repairing ApexDoc comments
    • @group
    • @group-content
    • @returns (non-standard; automatically replaced with @return when formatting/repairing ApexDoc comments)
    • @since
  • Support for all known inline formatting and cross-referencing expressions (beyond standard HTML tags and entities which were already supported) including:
    • {@link TypeName[.memberName]} - see the next note about a new way to format member links as well
    • {@code formattedAsCode}
    • `formattedAsCode`
    • <<TypeName>> - technically also supports the full type/member syntax supported by @see and {@link}, though I believe this mechanism is more targeted at linking to types by name
  • Support for # as a type/member separator in @see, {@link}, and <<..>> references. The type is optional and inferred to be the ApexDoc comment's containing type when omitted, e.g., {@link #computeValue}.
  • All ApexDoc features have been updated and enhanced as appropriate for these features including:
    • Apex > ApexDoc code style options
    • ApexDoc validation code inspection options
    • Code completion and cross-referencing/navigation as appropriate
    • ApexDoc-to-HTML rendering enhancements and improvements
    • Editor enhancements while authoring ApexDoc comments, e.g., automatic closing of paired HTML elements, inline formatting and cross-referencing expressions, etc.
  • Enhanced the way that IC2 matches @param entries when formatting/repairing ApexDoc comments to improve the likelihood of finding the correct parameter in the original list even when the original entries were malformed, reordered, etc. It's still not perfect but should yield significantly more accurate matching results when first run against an existing code base with broadly-malformed @param tags.
  • NOTE: While extensively customizable, IC2's ApexDoc support is still subject to certain biases, e.g.:
    • At present the order of tags is fixed, e.g., @param tags are always organized before the @return tag by IC2's ApexDoc comment formatter. Note that I am considering making this more flexible by allowing the user to choose the order in which tags should be arranged for both formatting and rendering purposes in addition to the current support for optional blank lines between adjacent tags.
    • Non-standard @returns tags are always replaced by standard @return tags.
    • While both @exception and @throws tags are supported, the ApexDoc formatter normalizes to the preferred tag based on formatter configuration.
    • Tags like @see should be used one per-reference. While comma-delimited lists will be retained by the formatter, IC2 provides best code completion, linking, and validation for tags of the form @see TypeName description.
• Issue 2048 - Fixed an issue where companion meta.xml file last modified timestamps were not being checked consistently when determining which files are out-of-date relative to the org.
• Issue 2053 - Removed the Lightning Lint bulk code inspection as it is no longer delivered with the CLI. Instead eslint-plugin-aura should now be used. Note that the dependency and ESLint configuration should already be in place for projects created using Salesforce DX.
• Quite a few other related fixes and improvements.