chore: cleanup docs, profiling config, and tests - #58
Merged
Conversation
Performance Comparison (same runner)Improvements
Stable
|
scolladon
force-pushed
the
chore/remove-alm-references
branch
from
August 17, 2026 10:12
28d6e33 to
ab6f94c
Compare
|
Preview build for this pull request: sf plugins install https://pkg.pr.new/dataset-loader@5483178 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explain your changes
Removes every
ALMreference from the repository.ALMwas never a product concept — it was leftover naming from a private Salesforce environment. A full sweep confirms zero occurrences insrc/,messages/,CHANGELOG.md,CONTRIBUTING.md,DESIGN.md,RUN_BOOK.md,package.json, or the CI workflows, and the phrase "Application Lifecycle Management" appears nowhere.Every occurrence was one of two data values, so no runtime behaviour changes — nothing under
src/is touched.1.
sfCLI org aliases —profiling/profiling.config.json,profiling/PROFILING.mdalm-xrmrusource-org-aalm-prodsource-org-balm-devsource-org-calm-devopsanalytics-org2. CRM Analytics dataset names —
README.md, three test filesALM_LightningPageViewLightningPageViewALM_AccountsAccountsALM_ImportedAccountsImportedAccountsALM_UserLoginTest_UserLoginALM_USERSTest_USERSALM_XTest_XThe README examples drop the prefix entirely so they read as generic, publishable config. Test fixtures adopt the
Test_prefix thatprofiling/profiling.config.jsonalready used forTest_LightningPageView/Test_User, rather than inventing a new convention.Recorded profiling measurements (timings, RSS, part counts) are a historical record and were left untouched.
Does this close any currently open issues?
No.
Any particular element that can be tested locally
No new parameters and no behaviour change to any existing one.
Any other comments
Action required before the next profiling run. The
profiling/org aliases are live infrastructure —sfmust be able to resolve the new names orprofiling/prepare.shwill fail:profiling/prepare.shitself needed no change — it references entry names (pageviews-xrmru,pageviews-prod) and CSV filenames, never an org alias.Deliberately left alone:
src/domain/metadata-types.ts—fiscalMonthOffset, a substring false positive and the onlyalmmatch in all ofsrc/pageviews-xrmru,users-xrmru-file) and fixture payloads (XRMRU,00Dxrmru) — these are labels and test data, not ALM references. Side effect:profiling/PROFILING.mdnow has rows readingpageviews-xrmru | source-org-a. Happy to genericize those in a follow-up if wanted.supervision.config.json,recovery.json,crma-load.config.json,lpv.config.json) — out of scope, and editing them would change what a local run actually does.Second commit:
build:dependency bumpsRebased onto
main(#55). That commit turnednpm outdatedinto a blocking drift gate, whichmaincould not pass — 11 pins had fallen behind latest, so every PR was red.osv-scannerwas also failing on two advisories. Neither was caused by the ALM rename (that commit touches 6 files of string literals and no dependency file), but both are fixed here so this PR can go green.Advisories cleared (
npm audit fix, lockfile only —npm auditnow reports 0):js-yaml(dev, transitive)nanoid(dev, transitive)Pins moved to latest per the CONTRIBUTING rule that pins track current latest; all stay exact, no ranges introduced:
@salesforce/core9.1.0→9.1.2 ·@biomejs/biome2.5.7→2.5.8 ·@commitlint/cli21.2.1→21.2.2 ·@commitlint/config-conventional21.2.0→21.2.2 ·@oclif/plugin-help6.2.56→6.2.58 ·@types/node26.1.2→26.2.0 ·jscpd5.0.14→5.0.15 ·knip6.32.0→6.32.2 ·pkg-pr-new0.0.87→0.0.88 ·@stryker-mutator/core+@stryker-mutator/vitest-runner9.6.1→10.0.0 (major)npm outdatednow exits 0.Pre-existing issue found, deliberately not fixed here
Mutation testing is already broken on
main, independent of this PR. Stryker crashes during sandbox setup:Stryker's
TSConfigPreprocessorcalls a TypeScript API thattypescript@7no longer exposes. I verified this is not a regression from the major bump by pinning back to 9.6.1 and reproducing the identical crash. Themutation-testingjob iscontinue-on-errorand skips whensrc/is untouched, so it does not block. Worth its own issue.