Repository navigation
fix(deps): bump @sasjs/utils to 3.6.5 - #1477
Conversation
3.6.5 restores the strictness of the URL validators. #268 replaced the `valid-url` dependency with a local implementation, and the replacement was more permissive: the URL parser normalises a backslash to a forward slash for special schemes, so `validateServerUrl('http:\\server')` was accepted where `valid-url` rejected it. The literal http(s):// prefix is now required, the scheme comparison is case-insensitive, and control characters the parser would strip are rejected. The previous release was 3.6.4, which restored @types/prompts as a dependency.
Coverage reportTotal coverage
Show files with reduced coverage 🔻Reduced coverage
Report generated by 🧪jest coverage report action from 794d33d |
![sasjs-dev[bot]](https://avatars.githubusercontent.com/u/67858352?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed the manifest and lockfile change at the head: @sasjs/utils 3.6.4 -> 3.6.5, exact pin, lockfile in sync including the nested @sasjs/adapter and @sasjs/lint copies (both pin utils 3.6.4 exactly, so the retained nested 3.6.4 is correct resolution, not drift), CI green at the head with the strict audit step. The bump itself is clean - both findings below are standing manifest issues the stale/ghost pass re-surfaced at this head, not regressions from this PR.
-
src/utils/utils.ts:7 and src/commands/run/run.ts:25 -
import axios from 'axios'(also src/utils/spec/utils.spec.ts:22) is undeclared in package.json: it resolves only through @sasjs/adapter's transitive pin (axios 1.20.0, package-lock.json), so an adapter release that drops or re-versions axios breaks the CLI build with no signal from npm or the lockfile. Declare axios in dependencies at the version the tree resolves. Raised previously (review on #1476) and still present at this head. -
package.json stale declarations, confirmed by import scan and unchanged by this PR: tslib 2.8.1 (line 122 - no import and no importHelpers in tsconfig.json), jwt-decode 3.1.2 (line 82), lodash.groupby 4.6.0 (line 83 - src imports lodash.uniqby, never groupby), @types/debug 4.1.13 (line 100), @types/find 0.2.4 (line 101), @types/lodash.groupby 4.6.9 (line 104). None is referenced from src, scripts, or configs. Candidates for a follow-up cleanup PR, previously raised on #1476.
2 findings above for review.
1 participant
Bumps
@sasjs/utilsto 3.6.5, which restores the strictness of the URL validators.Why
#268 replaced the
valid-urldependency with a local implementation, and the replacement was more permissive. The URL parser normalises a backslash to a forward slash for special schemes:so
validateServerUrlaccepted inputvalid-urlrejected. 3.6.5 requires the literalhttp(s)://prefix, compares the scheme case-insensitively, and rejects the control characters the parser would silently strip.It surfaced downstream:
@sasjs/vscode-extension'sinput.spec.tsasserts such URLs are rejected, and that suite passes on utils 3.6.2 and fails on 3.6.4.Verified
npm run build: exit 0, 0 TS errors (checked without a pipe, so the exit code is the build's)printVersion, which needs a globally installed@sasjs/cliand fails identically onmainnpm audit --omit=dev: 0 vulnerabilitiesMerge with squash or rebase
A merge commit's
Merge pull request #NNNsubject is invisible to semantic-release, which walks only the first-parent chain.Note for the next release
@sasjs/adapterand@sasjs/lintpin@sasjs/utilsexactly, at 3.6.4, so this install nests a second copy of utils under each. Nothing breaks here - the build is clean - but it is the same exact-pin ripple that blocked the extension earlier. Both would need a release on 3.6.5 for the tree to converge on one copy.