Skip to content

Recognize Apex .trigger files - #8183

Open
look wants to merge 2 commits into
github-linguist:mainfrom
look:look/apex-trigger-heuristics
Open

Recognize Apex .trigger files#8183
look wants to merge 2 commits into
github-linguist:mainfrom
look:look/apex-trigger-heuristics

Conversation

@look

@look look commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Description

Recognize Apex .trigger files from trigger declarations and sharing-qualified class declarations without resorting to the classifier. Matching is case-insensitive and supports multiline declarations; unmatched files continue through existing detection, and Shell shebang precedence is unchanged.

Reuses all existing Apex/Shell .trigger samples and adds two original Generic fixtures for multiline syntax and Shell negative coverage. No third-party samples are added. Public examples include Apex Recipes and NPSP, also discoverable through non-fork usage search.

Checklist:

  • I am adding new or changing current functionality
    • I have added or updated the tests for the new or changed functionality.

look and others added 2 commits September 8, 2026 15:19
Add targeted .trigger heuristics without changing Shell fallback or shebang precedence. Cover the existing collision samples, mixed-case multiline declarations, and ordinary shell content.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Use the Generic fixture convention for a file that should not match a heuristic, while retaining its full Shell detection assertion.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@look
look marked this pull request as ready for review September 9, 2026 20:45
@look
look requested a review from a team as a code owner September 9, 2026 20:45

@lildude lildude left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have you put the samples where you have rather than using the sample directories that already exist for these languages? "Generic" is going to cause confusion as people will start putting samples for extensions listed in generic.yaml there when they should be in the respective language directories.

We also need explicit mentioning of the licence of the samples in the PR template for all new extensions.

I'm only comment on this PR but the same applies to the others which are doing similar things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants