loopback-next
loopback-next copied to clipboard
npm start build stuff and is too slow
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"
},
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.
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.
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.
The same problem is so slow when run project in local