https://serverless-stack.com/ logo
Join Slack
Powered by
I’m curious why we build our own path to `.bin/tsc...
# sst
b
I’m curious why we build our own path to 
.bin/tsc
in cdkHelpers.ts vs. letting the system resolve this using $PATH? or other node module resolution strategies? I believe my latest mono-repo issue (rushjs, which symlinks 
node_modules
) deals with this “custom” module command resolution for 
tsc
I presume it’s to use your own 
typescript
dependency’s 
.bin/tsc
I presume? to keep framework in sync and building properly etc?
f
Hey @Blake E, yeah the function pretty much looks up the path to the 
tsc
executable in the node_modules by doing a require.
b
yeah, wondering why this is required to find path in-code vs. using node_module default resolution - (w/o knowing the wherefores here) I’d suggest a more vanilla approach which would move closer native support for pnpm and rushjs. In the meantime, I can probably work-around by symlinking to expectant folder structure
f
@Jay might be more familiar on this. From what I gathered, it seems by doing a 
required
, it is using the node_module’s default resolution?
b
well, suffice it to say, my 
tsc
is not in the location that is expected,
Copy code
/**
 * Finds the path to the tsc package executable by converting the file path of:
 * /Users/spongebob/serverless-stack/node_modules/typescript/dist/index.js
 * to:
 * /Users/spongebob/serverless-stack/node_modules/.bin/tsc
 */
pnpm
and rushjs.io use symlinks to create a single folder of installed packages (to avoid phantom dependencies) and symlinks into 
node_modules
. I’m not full read into the default module resolution spec that node implements (yet), but my 
tsc
is not located in folder beside 
typescript
. I can get the error and be more specific about my issues (I’ve already worked around it so will need to backtrack)
I guess, I’m just always weary when building these paths outside of node itself, as node has a full spec for package discovery. I imagine the use of 
require.resolve
should’ve accounted for this, but yeah - I don’t think ya’ll need to worry about this for now.
I was just hoping to understand why the path seeking in the first place, so my work-around(s) patch(es) don’t ignore something important.
f
Ah I see. Yeah that makes sense. We want to support pnpm and rushjs down the road. Or at least make SST more extensible.
3 Views
Open in Slack
PreviousNext
Powered by