nest-app | My first nest.js app , use nest.js and typeORM | Web Framework library

After a day's review of the project, I was:

• importing a class from the middleware that was using a library of the backend.

• using a library from the backend in the frontend

To fix the issues also complies with best-practices.

I have split the class in the middleware into two classes: one for the frontend, one for the backend. I have refactored the code so that the backend library was not necessary on the frontend. I ended up just fixing two files. And all the errors dissapeared.

So if you encounter something similar, double check whether or not you use some backend libraries/classes in your frontend.

As suggested by Bruce Zhang in his comment I will post the solution I found by myself.

So, the cause of the error was quite silly indeed.

1.) Using Plesk controlling panel (in IIS-server), irrespective of whether the NestJs application is deployed to site root or sub folder (like the default dist folder ), it is essential to get path settings to project to refer correctly:

Now, in the image above, path settings to project are correct when deployed to sub folder (i.e. default build folder dist). My error was that path reference for the Application Startup File was "/dist/main.js" as it should be just main.js.

After this simple correction app started normally with default IIS-port (port 80 and for SSL-protected connection 443). The main.ts -file does not have to anything else than just the following with the IIS default port fetched automatically via process.env.PORT:

After big research, I found a similar issue here: docker-compose: nodejs container not communicating with Postgres container

For some reason wait for it wasn't working (not sure if is a windows issue), that sh file is not mandatory to wait until database start, you can use depends_on to indicate that the server should start after a specified service:

Not sure without the code but got similar mismatches once upon a time in nest core packages. Check out package.json and ensure that all @nest packages have the same version, as sometimes they have 'breaking' changes even if it wasn't major release.

For an abstract example, something like that gave me errors related to core when building production: