fix: resolve @sasjs/core macros from the project's own node_modules f… - #1454
Merged
Conversation
…irst
Previously getNodeModulePath('@sasjs/core') used unscoped require.resolve,
which always found @sasjs/cli's own bundled @sasjs/core dependency before
the user's project - so running `npm i @sasjs/core` to pick up a new macro
had no effect until the next CLI release. getNodeModulePath now accepts an
optional fromDir, and setConstants tries process.projectDir first, falling
back to the CLI-relative lookup only when the project has no local install.
Coverage reportTotal coverage
Show files with reduced coverage 🔻Reduced coverage
Report generated by 🧪jest coverage report action from 4ac5a8e |
tmoody
previously approved these changes
Jul 10, 2026
allanbowe
reviewed
Jul 10, 2026
tmoody
approved these changes
Jul 10, 2026
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.
Issue
Closes #1449
Intent
sasjs compileignored a project's ownnode_modules/@sasjs/core:getNodeModulePath('@sasjs/core')used unscopedrequire.resolve, which walks up from@sasjs/cli's own install location and always found the CLI's bundled@sasjs/corefirst. Runningnpm i @sasjs/corein a project to pick up a new/updated macro had no effect until the next@sasjs/clirelease.Implementation
getNodeModulePathnow takes an optionalfromDir, passed asrequire.resolve'spathsoption, to anchor resolution at a given directory instead of the CLI's own location.setConstantsnow resolves@sasjs/corein three steps, matching the documented order:macroCorePathenv var (explicit override, unchanged)node_modules/@sasjs/core(new, viagetNodeModulePath('@sasjs/core', process.projectDir))@sasjs/cli's own bundled@sasjs/core(existing fallback, now used only when the project has nothing installed)Test plan
getNodeModulePathtest inutils.spec.ts: real (non-mocked) temp dir with its ownnode_modules/<fake-module>, unresolvable withoutfromDir, resolvable with itsetConstants.spec.tstests: project-scoped lookup wins and skips the fallback; fallback is used (in the right order) when the project has nothing installed; updated call-count assertions on the two pre-existing testscompile.spec.ts(21 tests) andbuild.spec.ts(13 tests), which compile real SAS files against real@sasjs/coremacros — no regressionsdocs/diagrams/sasjs-compile.mdto describe the new resolution orderChecks
npm run lint:fix).npm test).Reviewer checks