https://serverless-stack.com/ logo
Join Slack
Powered by
Gating `SST v0.56.2` issue local only, pipeline wo...
# help
d
Gating 
SST v0.56.2
issue local only, pipeline works fine. 
yarn build --stage dvb-idx
results in these 3 errors…
t
Do you happen to have lambda code alongside stacks code
d
yes
we’ve done this since the beginning though.
@thdxr
MyStack.ts
is stack code… and everything in 
lambdas
gets built into separate functions.
t
Ok I'm going to try and recreate this, something is going on where esbuild is including MyStack.ts when building
I'm afk right now for a few hours though
d
we also use our own 
tsconfig.json
ideally we will be renaming 
lib
to 
src
, we’ve never really liked the naming of lib or how I’ve seen others separate stack and lambda code. Didn’t know that could even be an issue. And hasn’t been till now. 😞
@thdxr @Frank Any thoughts on this. We’re pretty much dead in the water, not knowing what else to try to get this resolved. It really makes no sense. I mean, we have changed nothing in our repo, it works in the pipeline but not locally on two machines. The version of SST / CDK is yarn.lock ’d so what could possibly have changed? Do you guys push micro releases against the same SST version for CLI or something?
t
I'm looking at this this morning
We don't overwrite releases but are you 100% sure that this version was working before?
And what version is it again
d
it’s working now in our pipeline and has always worked locally as well. It’s likely within the last 5-6 days
t
In your pipeline can you tell what SST version it is?
d
the pipeline uses the version in the committed 
package.json
.. no? so it should reliably be using 
"@serverless-stack/cli": "0.56.2",
happy to zoom/huddle and share screen if it would help
t
So a fresh clone of this repo, installing deps, and running fails?
d
yes
on two machines (macbook pro)
However, the 
master
branch WORKS locally… but there is much less in that branch then in 
feat-dev
t
Copy code
@klickmarketing/cdk-constructs
Where does this come from?
d
that is our lib
t
But is it in another repo published to npm?
d
yes private npm
locked to that version
t
are you using yarn?
d
in both yes
our lib is a monorepo 
yarn + lerna
t
ok in the main repo do a fresh clone and install with 
yarn install --frozen-lockfile
d
ah yes… we ARE doing that in the pipe
lemme try
t
If this is the issue you got bit by a really poor design choice in NPM
The creator actually wrote a thread on this yesterday apologizing lol
d
lol…. of course
and assuming yarn doesn’t fix that issue
t
No they chose to stick with the same behavior, but let's see if it fixes
I'll explain if it does
d
kk running 
yarn install --frozen-lockfile
now
fresh clone
clearing existing AWS stacks…
@thdxr now did you want me to run … 
yarn build --stage dvb-idx
which is what I was running before?
or 
yarn deploy --stage dvb-idx
t
try build
d
kk sec
same error @thdxr 😞
t
can you send me your package lock
d
yes
t
Your lock looks fine, is it at all possible your pipeline is running an older version of SST?
d
I’m open to that thought…. but how would that work if the pipe uses the same lock file and same package.json
t
Some kind of caching? I'm not too sure how your pipeline is working consistently
d
there is caching based on lock file
Open in Slack
PreviousNext
Powered by