Happy Sunday everybody! Having a bit of a challenge debugging locally when using a monorepo setup. My repo looks like this:

project

app

server

types

SST is inside the

server

dir,

app

is for my react-native app, `types`is for my typescript types & interfaces that are shared between the two. When I run tests locally, code in

server

can `import { IType } from "@project/types"`successfully. Also, everything works flawlessly when deployed to AWS. However, when I debug a lambda function locally that uses the `import`above, I get the following error: ERROR Error: Cannot find module ‘/Users/davidmartin/dev/myapp/node_modules/@project/types/dist/index.js’. Please verify that the package.json has a valid “main” entry I can debug lambda’s locally when: 1. The lambda does NOT import from

@project/types

2. If I run `npx tsc`and put and

outdir

as “dist” in my tsconfig.json, then dist/index.js is found and debugging works But it feels weird to run `tsc`in my types directory before I debug. I don’t think I should have to do that. I don’t run

npx tsc

at other time. It’s also a bit weird now to have a `dist`directory. Thoughts?

I’m having a similar issue, I think. in my root level tsconfig.json, I have:

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@libs/*": ["libs/*"]
    },

and yet, whenever I try to import from

@libs/xyz

in my code, it doesn’t resolve and I get an error.. it’s trying to find an NPM package called

@libs

Another problem with this approach: I have to delete that `dist`directory before deploying because I’m getting this error: /Users/davidmartin/dev/myapp/packages/types/dist/index.js 26:4 error ‘DataTypes’ is assigned a value but never used no-unused-vars Fyi, DataTypes is an exported

enum

my gut says you definitely don’t want to or need to run

tsc

. but

tsconfig.json

paths

should really work. not sure why it’s not

@Sam Hulick I think your issue is different from mine. Looks like you’re using a typescript alias, and I’m importing another package from a monorepo. The difference is that the reference to `@project/types`lives in package.json as:

dependencies: {

"@project/types": "1.0.0"

}

But, I’m also using typescript aliases like you. They work all the time for me, even when debugging lambdas locally. However, my config looks a bit different from yours. In my root level tsconfig.json, I have:

"@lib": ["src/lib"],

"@lib/*": ["src/lib/*"],

Don’t remember why there are two entries, probably something I found on stackoverflow while setting it up. Perhaps try adding the first import similar to mine and see what works? Also, can you share the import statement that doesn’t work?

ah sorry, didn’t mean to hijack your thread 😅

no worries I’m sure we’ll get around to my issue too. btw, I also have this in my package.json for jest testing: “jest”: { “moduleNameMapper”: { “^@lib/(.*)$“: “<rootDir>/src/lib/$1” }

actually it’s only in VS Code where it complains.

yarn build

works just fine

oh wow, you’re right, it does build just fine that way. i get an error in my editor but not when i build:

@thdxr or@Frank ☝️ any thoughts? things are a bit odd here

Afk right now but will check in later today

no rush at all, I know it’s a weekend 🙂

And I think the build issue above is still a different issue from the one I originally posted, which I would like to keep alive in this thread.

@Sam Hulick just created an issue for the module not found case https://github.com/serverless-stack/serverless-stack/issues/662

thanks Frank! is this maybe related to

tsconfig.json

paths

not working?

Hey Sam, do you mind reposting ur original message: https://serverless-stack.slack.com/archives/C01JG3B20RY/p1628445386244400?thread_ts=1628444037.242300&amp;cid=C01JG3B20RY in the #help channel again as a separate thread? Just makes it easier to dig deeper 😁

sure thing!

thanks @Frank!

Hey @David Martin, just double checking on ur setup:

project/
  package.json
  app/
  server/
    package.json
    sst.json
  types/
    package.json

And in `server`’s package.json, you have:

dependencies: {
  "@project/types": "1.0.0"
}

And you are seeing

sst deploy

works, but

sst start

doesn’t. Is this right?

@Frank yeah for the most part. I simplified it a bit earlier. there’s a package directory. here’s a screenshot.

Do you get the error when you try to start up

sst start

? Or is it on runtime when a requests comes in?

btw when I run the debug, i’m starting in VS Code.

Got it. And is

@project

an alias, or is

@project/types

the package name for

packages/types

?

@project/types is the name of the repo in package.json: “name”: “@project/types”,

does the

types

folder have a

package.json

in it and if so, what is the

main

pointing to?

`types`does have a `package.json`and there is a

main

. at first, main pointed simply to “index”, and that failed. i’ve since changed that to point to the file that the error asked for:

dist/index.js

If I'm understanding this correctly, the issue is because

@project/types

is being treated as a normal dependency and is expected to be a compiled typescript output. So when code in

server

is looking for it, it's looking for a package.json then looking for the entrypoint. The entry point doesn't exist until you "compile" the package via

tsc

or

tsc -w

if you want to continuously build it. It's likely this doesn't happen in production because importing types don't matter in production. For "shared types" I tend not to treat them like a real package and just import the files from a shared folder

Do you consider packages in a monorepo a “normal dependency”? here’s my root package.json: { “name”: “project”, “version”: “0.1.0”, “private”: true, “workspaces”: { “packages”: [“packages/server”, “packages/app”, “packages/types”] } }

Yeah. Imagine if instead of just types, you had actual typescript code in there. You can't import that directly without it being compiled first, you'd have to build it first. Same goes for you even though you're just importing types

i agree that you’ve accurately described the way that `server`looks for

types

through the main entry of

package.json

. let me test the assumption that there should be real code in there that has to be built first. i’m going to export a function that prints hello world.

Nice - wonder how that works with long running commands like

tsc -w

if you're working across several packages

i think i know what’s going on

I was just looking to see how esbuild is used locally

i think it’s importing the ts files directly. here’s a copy/paste from the lambda function code: // ../types/index.ts var DataTypes; (function(DataTypes2) { DataTypes2[“CAT”] = “CAT”; DataTypes2[“CITY”] = “CITY”; DataTypes2[“CLAIM”] = “CLAIM”; DataTypes2[“COMMENT”] = “COMMENT”; DataTypes2[“FAVORITE”] = “FAVORITE”; DataTypes2[“HOTSPOT”] = “HOTSPOT”; DataTypes2[“IMAGE”] = “IMAGE”; DataTypes2[“IMPORTED_INSTA_POST”] = “IMPORTED_INSTA_POST”; DataTypes2[“INSTAGRAM_CONNECTION”] = “INSTAGRAM_CONNECTION”; DataTypes2[“INSTAGRAM_DATA_DELETION_REQUEST”] = ” INSTAGRAM_DATA_DELETION_REQUEST”; DataTypes2[“INSTAGRAM_SHOPCATS_USER_MAPPING”] = “INSTAGRAM_SHOPCATS_USER_MAPPING”; DataTypes2[“LIKE”] = “LIKE”; DataTypes2[“PLACE”] = “PLACE”; DataTypes2[“POST”] = “POST”; DataTypes2[“SETTING”] = “SETTING”; DataTypes2[“TAG”] = “TAG”; DataTypes2[“USER”] = “USER”; })(DataTypes || (DataTypes = {})); var printHelloWorld = () => { console.log(“hello, world”); };

It seems like for the production build it's not treated as another package but rather just another file

yeah. i mean, i doubt i’ll be the only person with a monorepo who wants to debug so it’s probably worthwhile. and i don’t think there’s anything unique or wrong with my project configuration.

Weirdly enough I think it's the production behavior that's "wrong" (even though it's desirable). Yeah adding me would be helpful my username is thdxr on github

but yeah, enjoy your sunday! this isn’t urgent because I have a temporary workaround, but it’s definitely part of the appeal of SST.

Yeah definitely need to fix this