loopback-next icon indicating copy to clipboard operation
loopback-next copied to clipboard

npm start build stuff and is too slow

Open gagarine opened this issue 3 years ago • 3 comments

On a project made with the cli npm start launch the following command:

"start": "node -r source-map-support/register .",

This basically clean and build the full project and then start it in a dev mode.

This command can take forever to run. Azure App Service ping app and has a 230 timeout before they shutdown the container. On a small instance, the container will be shutdown before loopback has a chance to start. It's anyway a waste of ressource has Azure run build (in the build process, so no timeout) and then start (in startup script).

I belive npm start should run "start": "node ./dist/index.js", instead. A specific command for dev could be introduced such as "dev": "npm run build && node -r source-map-support/register .",.

Those are my current scripts:

  "scripts": {
    "build": "npm run clean & npm run copy-files && lb-tsc",
    "build:watch": "lb-tsc --watch",
    "pretest": "npm run build",
    "migrate": "npm run build && node ./dist/migrate",
    "openapi-spec": "npm run build && node ./dist/openapi-spec",
    "dev": "npm run build && node -r source-map-support/register .",
    "start": "node ./dist/index.js",
    "clean": "lb-clean dist *.tsbuildinfo .eslintcache",
    "copy-files": "mkdir -p dist && cp -r ./backend ./src/data ./dist"
  },

gagarine avatar Jul 28 '21 19:07 gagarine

Hi @gagarine, apologies for not reviewing your issue earlier.

I'm hesitant on creating a new script called dev (or similar) as usually this implies a live-reload feature.

Perhaps we could move the build to a NPM prestart lifecycle script instead. That way, npm start --ignore-scripts can be used to avoid rebuilding the project.

achrinza avatar Aug 17 '21 16:08 achrinza

I understand. But I'm not sure how familiar people are with --ignore-scripts, also cloud platform do not use that by default. I'm also not familiar enough with nodejs "custom and best practices". But for me, start is for production and does not contain build phase.

I reached on Microsoft about this problem. They will improve their documentation around those kind of problems, and eventually introduce new options.

gagarine avatar Aug 18 '21 11:08 gagarine

The behavior of npm start was changed a year ago in this commit, as a fix for The application can't start after deleting some model, repository, and controllers . Though that issue is indeed fixed by the new prestart command, in my opinion npm start should be used in production deployments, where deleted files should never occur. For development, npm build:watch is much more useful.

In other words, we now have a very slow npm start as a default, in order to fix a problem that should be quite rare, if I understand it correctly.

In our case, deployment with the prestart takes over a minute, instead of just seconds. The "solution" is more or less to revert that commit: either remove prestart, or create a separate command just like start but with another name so that prestart does not get triggered as well. I would much prefer for npm start to have its old & fast behavior - perhaps another solution for that issue would be to print during npm start that files need to be built beforehand, and that build:watch is more useful for development.

0x0aNL avatar Oct 11 '21 13:10 0x0aNL

The same problem is so slow when run project in local

pookdeveloper avatar Sep 30 '22 08:09 pookdeveloper