feat: adopt @sasjs/lint 4.1.0

[sasjs-dev]

Summary

Bumps @sasjs/lint 2.7.0 -> 4.1.0 in api/ - api/package.json plus both lockfile entries (2 files, 5 lines).

What lands with it

release	kind	effect on the api
3.0.0	breaking	noUndeclaredMacros / noUnusedMacros on by default
4.0.0	breaking	an absent setting falls back to its documented default
4.1.0	minor	new noUnusedLibnames rule, off by default

The Studio gains the two macro rules

api/src/utils/lintConfig.ts carries the api's own default configuration - it is seeded to the drive root as /.sasjslint at startup, and it is the fallback when that file cannot be read. It does not name noUndeclaredMacros or noUnusedMacros, so under 3.0.0 both are now on:

rules enabled by the api's default config
  2.7.0: 12
  4.1.0: 14   (+ noUndeclaredMacros, noUnusedMacros)

A Studio buffer that invokes a macro without declaring it in the header is now flagged, and a header entry the file never uses is flagged too. The macros that ship with SAS - %scan, %sysfunc and the other macro functions, along with the language keywords such as %if and %do - are always considered declared, so only project macros are reported.

The rules are applied to everyone rather than pinned off in the api's default config. #459 treated noSingleAsteriskComments as opt-in, but that was to protect an installed base; there is none here, so the lint defaults stand. noUnusedLibnames stays off, as it is off by default in 4.1.0.

4.0.0 does not affect the api

The api's default configuration names maxLineLength (80) and hasMacroNameInMend (true) explicitly, so the change that makes an omitted setting fall back to its documented default has nothing to act on. Every setting 4.0.0 touches is explicit there, and hasDoxygenHeader: false is preserved.

Verification

• npm ci - installs cleanly, lockfile in sync.
• npx tsc --noEmit - clean against 4.1.0, so the LintConfig, lintText and formatText usage in lintConfig.ts, lintProgram.ts and controllers/code.ts is unchanged.
• The api suite run on both sides and compared:

	2.7.0 (base)	4.1.0 (bump)
Test Suites	18 failed, 19 passed, 37 total	18 failed, 19 passed, 37 total
Tests	306 failed, 181 passed, 487 total	306 failed, 181 passed, 487 total

The failing-suite list is identical too, so the bump changes no suite's outcome. All 18 are the specs that need a live server and a MongoDB binary (auth, localLogin, sessionCookie, permission, user, drive, appStreamListing, ...).

The code controller spec, which covers the /code/lint and /code/format endpoints, is not among them - it passes on both sides.

No source change is needed.

[sasjs-dev]

Reviewed the full diff for sasjs/server #460 (api/package.json + api/package-lock.json: @sasjs/lint 2.7.0 -> 4.1.0) plus repo-level hardening (CI audit gates, .npmrc, gitleaks hook, release config).

Findings:

• .github/workflows/build.yml:66 - the "Audit Web dependencies" step runs npm audit --audit-level=high, which is not strict: moderate and low advisories pass the gate. The documented reason (react-router moderate advisories pending react-router-dom 7) is understood, but the gate must fail on any production vulnerability. Use the default level or --audit-level=low and track the react-router migration separately, or scope with --omit=dev.
• Commit subject "feat: adopt @sasjs/lint 4.1.0" is a pure dependency bump. semantic-release (.releaserc) will cut a minor release from it. A lint toolchain bump is chore(deps)/build, not a new capability; use "chore(deps): bump @sasjs/lint to 4.1.0" unless a lint behaviour change is user-visible.
• CI is not green at this head: security, lint, build-web and build-api have passed, but "Container build and scan" is still in progress (mergeable_state unstable). Not ready to merge until it completes.

3 findings above for review.

[github-actions]

🎉 This PR is included in version 1.19.0 🎉

The release is available on:

• GitHub release
• v1.19.0

Your semantic-release bot 📦🚀

[sasjs-dev]

Adding the targeted confirmation for the lint/format endpoints, since the body only cited it indirectly (via the full-suite comparison).

npx jest src/routes/api/spec/code.spec.ts --forceExit    # lint 4.1.0 in node_modules
Test Suites: 1 passed, 1 total
Tests:       10 passed, 10 total
Time:        6.606 s

10/10 pass - the same ten tests that #459 cited when it adopted 2.7.0. So the /code/lint and /code/format controllers behave under 4.1.0, not just compile.

Worth noting for anyone running this spec by hand: it completes in about seven seconds, but jest does not exit afterwards, so a wrapper timeout looks like a hang. That is the missing forceExit in the api jest config, not the spec - add --forceExit and it returns cleanly. It is also why the spec passes inside the full suite while appearing to hang when run alone.