Help understanding the difference between `npx nx start` and `yarn command:prod`
I added a single new dependency (
RelationMetadataModule) to WorkspaceManagerModule so I could run some logic when a workspace is activated.
This always succeeds via npx nx start. It always fails via yarn command:prod.
Thus, I can't commit my changes or I'll be blocked from using yarn command:prod for future migrations. Fwiw, using forwardRef doesn't fix.
The fact the Modules are valid with npx nx start makes me think this is a quirk of how command.ts starts the app. It probably also explains why forwardRef has no effect.
Can someone who's familiar with the codebase/NestJS explain the difference? I'm guessing it's a simple remedy for someone who knows what they're doing (clearly not me 😅 )
11 Replies
@charles explained it to me other day, maybe that's what you're looking for https://discord.com/channels/1130383047699738754/1272636146517807209/1273278434440777761
Oh that's super useful info, thanks! I still don't know why my 1-line change succeeds with
nx but fails with yarn. Hopefully charles will have an idea lol@JarWarren I don't think your issue comes from using npx nx run or yarn command
you are actually using a different entrypoint with npx nx start and yarn command:prod (server:start which is loading the AppModule vs command which is loading the CommandModule)
To use nx to run the command you should use: npx nx run twenty-server:command {my-command}
And you should face the same circular dependency issue
Could you post the whole stacktrace of your error, it should be there!
@charles Ohh ok, so it is the different entrypoints. I ran it with
nx and got the same issue, as you expected.
WebStorm adds ellipses to the middle of each row but this seems to be all of the relevant JS in the stack trace.
Not sure why the circular dependency only occurs on one entrypoint and not the other - or why forwardRef doesn't fix it. Hopefully this is a simple fix? I just wanted to add one dependency haha. Thanks a ton for taking a look!I will try to reproduce your issue on our main branch
@charles i ended up finding a different way of accomplishing what I wanted to. Thanks for looking into it!
I never did find out why the circular dependency only occurred in CommandModule and not AppModule but hopefully it never will matter haha
@JarWarren could you write down a workaround in case someone else will have the same problem in the future?
Well I never found a solution. I just ended up taking a different, better approach.
I wanted to add some extra objects (beyond People, Companies, Opportunities) whenever a new workspace was added.
Originally I generated them as Custom objects in WorkspaceManagerService
activateWorkspace. It worked perfectly when I ran the webapp, but future migrations wouldn't be able to work (see above, circular dependency, etc).
In the end I added my new objects as true Standard objects instead. I used https://discord.com/channels/1130383047699738754/1254498631680131145 as a reference for how to do it.Ok! @JarWarren out of curiosity, why not using custom objects? you need these objects to be provisioned on multiple workspaces?
@charles Yeah. I wanted to add some landscaping-specific stuff to all workspaces. Adding them as Custom seemed like a smaller lift initially, since most of the work would've already been done for me.
In the end it was probably better to just go and add them as official Standard objects tho
Yes these should be standard object
Later in Twenty dévelopment we will introduce the notion of plugins or modules that will be enable to declare their own standard objects