I converted my angular project to angular universal (using #ng-toolkit/universal), and I was able to build and run using the below comments without any issue in both local and server:
npm run build:prod
npm run server
When I am trying to run using pm2/forever load balancer, I am getting the below exception, so it is not at all starting/running only:
(node:15922) [DEP0005] DeprecationWarning: Buffer() is deprecated due
to security and usability issues. Please use the Buffer.alloc(),
Buffer.allocUnsafe(), or Buffer.from() methods instead.
I updated both npm / ng and tried, but still no luck.
I also googled the error, and it seems few things are deprecated in the npm packages, where as I can't do anything here as it is angular universal project and server.js files are not created from my side. (all from ng-toolkit/universal) only.
Can someone help me here please?
Related
We have a React app, based on the Hydrogen theme for Shopify (which uses vite). It was all working ok until I had to add a package and update. It then started giving the following message: Error timed out. That is it, no other error message, I looked in the logs and there was nothing remarkable in there.
I tried removing the package, and all references to it in the code. But it looks like the issue may well have been the update command. But being rather new to React and npm on Windows, I have no idea how to fix it. Things that I did try were clearing the cache using:
npm cache clean --force
Doing another update. Removing the lock file.
Does anyone have a suggestion as to a method to debug that one-line error code, or could point me in the right direction? I am running on localhost, via Windows 10.
npm error timed out image
My problem must have been a broken dependency. After a day or so of trying updates, it eventually just started working again. The update that actually worked had some vulnerabilities, so I ran an:
npm audit fix
After the npm audit fix, the code started running correctly again.
Problem
I was facing difficulty in importing one of the packages properly and using it in my MERN application in the backend. After researching and looking at the deployed code I got to know that my application is using the unwanted version of that package and thus it is causing the issue but I already changed the version in package.json before pushing. I have written unwanted here because in my case the new version of the package has bugs and that's why I want the old/previous version back but I am unable to know the exact reason or thing which is causing heroku to use the unwanted version again and again.
For Clarity:
initial version: 1.6.6 (was working fine)
then I installed version: 1.7.0 (found bugs) unwanted version
tried to go back to version: 1.6.6 but couldn't
What I have tried
The first thing I tried was setting NODE_MODULES_CACHE to false to avoid heroku from picking up old code as it has worked for me in the past. Apart from that I have I can't find any other thing.
There is nothing suspicious in the heroku logs and it builds the application without any error.
I found the solution to it if someone's looking for it. It is not much of a solution instead it's more about how heroku works.
Heroku uses npm ci instead of npm install.
npm ci installs all dependencies in respect to package-lock.json similar to npm install. The key difference here is that ci doesn't alter package-lock.json under any circumstances.
So basically, the package-lock.json was still the unwanted one in my case and heroku was installing that rather than what I pushed into package.json as it didn't matter.
So, in order to solve this issue you have two options:
You can push your updated package-lock.json. In my case I had intentionally not added package-lock.json to versioning as I thought heroku would update it so I had put it in .gitignore
You can set the USE_NPM_INSTALL environment variable to true to let Heroku know that you want to use npm install instead of npm ci to create the build environment. (NOTE: If you want to use npm install Heroku advises to use NODE_MODULES_CACHE=false as it speeds up the build time)
I went with option 1.
Link to Heroku docs: https://devcenter.heroku.com/articles/nodejs-support
I'm using serverless to create a Lambda (Node 10x).
The Lambda uses Rollup to create JS and CSS assets. But it is failing at the Rollup stage.
It runs locally using Node 10.0.0 and serverless-offline but once it gets to production, I get this error
2019-08-29T14:32:35.254Z ERROR error: { Error: Missing binding /var/task/node_modules/node-sass/vendor/linux-x64-64/binding.node
Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 10.x
Found bindings for the following environments:
- OS X 64-bit with Node.js 10.x
This usually happens because your environment has changed since running `npm install`.
Run `npm rebuild node-sass` to download the binding for your current environment.
at error (/var/task/node_modules/rollup/dist/rollup.js:224:15)
at /var/task/node_modules/rollup/dist/rollup.js:17213:17
code: 'PLUGIN_ERROR',
plugin: 'postcss',
id: '/var/task/src/css/app.scss' }
I can run npm rebuild node-sass locally and it does something to my node_modules and makes it bigger, too big in fact to deploy to AWS!
So before I go and rip things out of the app to try and get it to compile at a smaller size, is there anything else I can do regarding this node-sass environment issue?
Thanks
Solved it!
In node_modules/node-sass/vendor/ there was only a darwin-x64-64/binding.node folder/file.
From this github page I downloaded linux-x64-64__binding.node
renamed it to binding.node and created a linux-x64-64 folder and put it in there: node_modules/node-sass/vendor/linux-x64-64/binding.node
Then redeployed the lambda and all is well. I just need to remember to do that if/when I do a yarn update or similar.
I'm working on a react app and using apollo and postgraphile for graphql. I currently have to have two terminal windows open, one running
npm start
for the react-dev server, and one running
postgraphile -c 'postgresstring'
for the postgraphile server
everything works when doing this, but i'm passing the project off to the rest of my team and would like them to be able to simply run
npm start
to start both the react and postgraphile servers. I tried using the npm packages concurrently and npm-start-all to run both scripts on npm start, but every time i use npm to run the postgraphile command I get errors on trying to actually query the graphql server in graphiql saying that i have duplicate instances of graphql running. this happens even if i put the postgraphile command in it's own npm command like
"graphql": "postgraphile -c 'postgresstring'"
and run
npm run graphql
error message:
Error: Cannot use GraphQLSchema "[object Object]" from another module or realm.
Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of
other relied on modules, use "resolutions" to ensure only one version
is installed.
https://yarnpkg.com/en/docs/selective-version-resolutions
Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.
How can I run postgraphile via npm run so that i can use concurrently or npm-run-all to run both of them with a single command? note that simply using "node scripts/start.js && postgraphile -c 'postgresstring'" won't work because it waits for the start.js server to terminate before running postgraphile.
This is a common pain for people working with graphql in the Node.js ecosystem. The way to solve this is to add a "resolutions" entry to your package.json informing yarn that it should try and install just one version, graphql#0.12.x, anywhere that version satisfies the supported GraphQL ranges rather than installing multiple versions. To do so, add something like this to your package.json file:
"resolutions": {
"graphql": "0.12.x"
}
Then run yarn again and you should notice that your yarn.lock file has been updated to only reference one version of graphql.
Explanation
The first postgraphile command you're running executes the globally installed postgraphile command (installed via npm install -g postgraphile or yarn global add postgraphile); which doesn't suffer this issue because it has only its own dependencies and they don't conflict.
However for the npm run command, npm automatically adds your local ./node_modules/.bin/ folder to the beginning of $PATH and thus your local copy of postgraphile (installed via yarn add postgraphile) is being executed instead. (This is the behaviour you want!) It seems you've also installed something else that depends on graphql (perhaps Apollo Client?) and you now have two versions of graphql somewhere in your node_modules folder, each in different locations, and postgraphile is picking up a different version to graphile-build, which is causing the issue.
Happy PostGraphiling!
I'm getting a build error when running webpack in trying to deploy a project to Heroku (and only then):
remote: ERROR in chunk webpackManifest [entry]
remote: js/[name]-[chunkhash].js
remote: Chunk.entry was removed. Use hasRuntime()
remote: Child html-webpack-plugin for "../server/views/index.hbs"
It works fine for me locally, it's just on a Heroku dyno that it fails. It seems to have started failing when I started using HTMLWebpackPlugin in my build, and the error message seems to point to that module (as you can see). Googling the error gives a bunch of results, but they all seem to boil down to this issue. That issue points to extract-text-webpack-plugin as the culprit, but the comments are all outdated and the suggestion (to install a beta or rc3 version of the plugin) doesn't work since extract-text-webpack-plugin seems to have passed that now. As far as I can tell, HTMLWebpackPlugin doesn't depend on extract-text-webpack-plugin at all.
EDIT: The Heroku install uses webpack#2.6.1, locally I was on 2.5.1, but manually changing to 2.6.1 locally still wasn't able to reproduce it.
EDIT 2: Explicitly upping the dependency in my package.json to ^2.7.0 seems to have made Heroku happy
I suppose this was some sort of temporary issue, since it seems to work if explicitly using the latest version.