I have a project with a backend and frontend repository.
The frontend utilizes vue.js.
Now, I can easily clone the git repository onto my local machine. There I need to run it.
To do this, I first need to set up vue.js inside the repository...somehow, I guess.
The repository doesnt have any node or npm or whatever stuff in it. I need to install this myself, locally (I guess this was done to protect the repository from growing too big).
I learnt on the vue.js official sites how to create a new project, but in this case, I'm working in an existing project, right? So how do I get vue.js into an existing project.
Its vue-cli based btw., so I need to install vue-cli as well (or rather use the vue-cli version of vue.js)
Okay, I found the answer myself.
First, vue cli needs to be installed locally. So inside cmd cd to your local repository and execute:
npm install vue-cli
After this, install the serve functionality like this:
npm install -g serve
and then you can just do:
serve
And you get something like this on your cmd:
│ Serving! │
│ │
│ - Local: http://localhost:5000 │
│ - On Your Network: http://172.21.128.28:5000 │
│ │
│ Copied local address to clipboard! │
Optionally, you can also first build your project and then serve your dist, so after install your serve functionality, first do:
npm run build
and then
serve -s dist
and you should be fine. You can read about some of this stuff here too:
https://cli.vuejs.org/guide/deployment.html#general-guidelines
Related
So I have this NodeJS monorepo which is structured as follows:
monorepo/
├─ src/
│ ├─ libs/
│ │ ├─ types/
│ │ │ ├─ src/
│ │ │ ├─ package.json
│ ├─ some_app/
│ ├─ gcp_function/
│ │ ├─ src/
│ │ ├─ package.json
├─ package.json
Multiple projects use the same types library, so anytime a type changes, we can update all references at once. It has worked really great so far and I'm really happy with the structure.
Except now I needed to create a function on the Google Cloud Platform. In this function I also reference the types project.
The functions package.json is as follows:
{
"devDependencies": {
"#project_name/types": "*",
"npm-watch": "^0.11.0",
"typescript": "^4.9.4"
}
}
The #project_name/types refers to the src/libs/types project. This works with every project, because we have a centralised build tool.
This means the function works locally on my machine and I have no problem developing it, but as soon as I push it to Google Cloud (using the command listed below) I get the following error:
npm ERR! 404 '#project_name/types#*' is not in this registry.
I use this command to deploy from ./monorepo:
gcloud functions deploy gcp-function --gen2 --runtime nodejs16 --trigger-topic some_topic --source .\src\gcp_function
I think it's pretty clear why this happens:
Google Cloud only pushes the function, which then builds on Google Cloud Build. But because the rest of the monorepo doesn't get pushed, it doesn't work as it has no reference to #project_name/types.
I've been struggling with this issue for quite a while now.
Has anybody ever run into this issue and if so, how did you fix it?
Is there any other way to use local dependecies for Google Cloud functions? Maybe there is some way to package the entire project and send it to Google Cloud?
I have resolved this issue by using a smart trick in the CI pipeline.
In the CI I take the following steps:
Build the types and use npm pack to package it.
Copy the compressed pack to the function folder. There install it using npm i #project_name/types#file:./types.tgz. That way it gets overridden in the package.json.
Zip the entire GCP Function and push it to Google Cloud Storage.
Tell Google Cloud Functions to build and run that zip file.
In the end my CI looks a bit like this:
steps:
- name: Build types library
working-directory: ./src/libs/types
run: npm i --ignore-scripts && npm run build && npm pack
- name: Copy pack to gcp_function and install
run: cp ../libs/types/*.tgz ./types.tgz && npm i #project_name/types#file:./types.tgz
- name: Zip the current folder
run: rm -rf node_modules && zip -r function.zip ./
- name: Upload the function.zip to Google Cloud Storage
run: gsutil cp function.zip gs://some-bucket/gcp_function/function.zip
- name: Deploy to Google Cloud
run: |
gcloud functions deploy gcp_function \
--source gs://some-bucket/gcp_function/function.zip
This has resolved the issue for me. Now I don't have to publish the package to NPM (I didn't want to do that, because it doesn't fit in the monorepo narrative). And I can still develop the types which get updated live in every other project while developing.
I feel like this is useless as my conundrum has been discussed in several different threads, but nothing has worked.
I have an ExpressJS/node server deployed to AWS Elastic Beanstalk. When I first tried to deploy several weeks ago, I couldn't get it running until I finally realized one of my many dependencies (an amazing image resizing tool called Sharp) was breaking it. I uninstalled it and removed its usage in the server. Everything was fine. But I really need it--it works beautifully when I run the server on my local device.
But when I reinstall and deploy, I get this error:
npm ERR! path /var/app/staging/node_modules/sharp
npm ERR! command failed
npm ERR! command sh -c (node install/libvips && node install/dll-copy && prebuild-install) || (node install/can-compile && node-gyp rebuild && node install/dll-copy)
npm ERR! sharp: Are you trying to install as a root or sudo user? Try again with the --unsafe-perm flag
npm ERR! sharp: Please see https://sharp.pixelplumbing.com/install for required dependencies
npm ERR! sharp: Installation error: EACCES: permission denied, mkdir '/root/.npm'
The majority of answers on the web are to set unsafe-perm=true, as an environment variable, in a file named .npmrc, using a .config file in .ebextensions that gives write permissions to root... Googling anything pertaining to Sharp and Elastic Beanstalk, or my specific errors brings up an endless sea of purple links to me. But nothing has worked.
EDIT: Rather than continuing to fight to get Sharp working, I found an alternative tool called Jimp. Might be less robust than Sharp, but I really just need resizing, and it does that, so if anyone else is pulling their hair out over this issue, consider saving yourself the headache, and go with Jimp.
Please reference my "workaround" solution provided in the following GitHub Issue (Fails to install on AWS ElasticBeanstalk with node16 #3221) for a full explanation.
Solution:
Create the following Platform Hooks paths in the root directory of your application bundle.
.platform/hooks/prebuild
.platform/confighooks/prebuild
Create the following bash script (00_npm_install.sh) with execute permissions (chmod +x).
#!/bin/bash
cd /var/app/staging
sudo -u webapp npm install sharp
Validate the Application Bundle Structure.
Ex. Sample project structure:
~/my-app/
├── app.js
├── index.html
├── .npmrc_bkp
├── package.json
├── package-lock.json
├── .platform
│ ├── confighooks
│ │ └── prebuild
│ │ └── 00_npm_install.sh
│ └── hooks
│ └── prebuild
│ └── 00_npm_install.sh
└── Procfile
Deploy the Application!
Hope it helps!
I have a Laravel application that is hosted on Heroku and serves multiple Javascript games from a single domain. Everything is contained in a single Git repo. The back-end application provides OAuth and other features that are shared by all of the games. Each game is a standalone React app with its own separate node_modules folder. The folder structure looks like this:
├── package.json
├── node_modules
└── games/
└── checkers/
├── package.json
└── node_modules
└── chess/
├── package.json
└── node_modules
└── mahjongg/
├── package.json
└── node_modules
└── public/
├── app-compiled.json
└── games/
└── checkers/
└── app-compiled.js
└── chess/
└── app-compiled.js
└── mahjongg/
└── app-compiled.js
Each time I push a new version of this up to Heroku, I need to run a separate build command to compile the main web application and each of the separate React games. Basically, this is what needs to happen:
npm install
npm run production
cd games/checkers
npm install
npm run production
cd ../chess
npm install
npm run production
cd ../mahjongg
npm install
npm run production
Those commands will compile the React games and place each one under public/games/{slug}/app-compiled.js where they can be served by the common web application.
I already tried adjusting the heroku-postbuild script in my main package.json file to look like this:
"heroku-postbuild": "npm run production && cd games/checkers && npm install && npm run production && cd ../chess && npm install && npm run production && cd ../mahjongg && npm install && npm run production"
That actually works, but I'm worried that it might break at some point in the future as the build process gets bigger and more complex. Is there a better, more supported way to accomplish what I'm trying to do here?
Note that I am not open to the idea of running a separate Heroku dyno for each React app. I am eventually going to have about 30 games, and it would be cost-prohibitive to run each on a separate dyno.
I have a node project my-app that depends on my-other-lib and my-test-lib, my-other-lib also has a dependency on my-test-lib.
This structure in node_modules looks like this:
my-app
├── my-other-lib#1.0.0
└── my-test-lib#1.0.0 (dev dependency)
└── my-other-lib#1.0.0
my-app uses my-other-lib to do some stuff on the production app, my-test-lib is a framework of sorts to help with testing. my-test-lib also makes use of my-other-lib.
I'm writing a test in my-app I want to add a bit of functionality to my-other-lib to help me in that test. I don't need to change any code in my-test-lib to get this working, however I can't figure out how to get this dependency to update without bumping the dependency version in my-test-lib and releasing a new version of it. It feels like I shouldn't have to do that.
If I release my-other-lib#1.1.0, then in my-app run npm install my-other-lib#1.1.0, I end up with this node_modules structure:
my-app
├── my-other-lib#1.1.0
└── my-test-lib#1.0.0 (dev dependency)
└── my-other-lib#1.0.0
One thing that seems odd to me is that my-test-lib specifies the dependency as my-other-lib: "^1.0.0" which implies that it should be fine with using 1.1.0, but still both packages are installed in node_modules.
Is there a way to have my-test-lib use my-other-lib#1.1.0 besides bumping the version in my-test-lib and releasing my-test-lib#1.1.0? And if not, what is the point of specifying the ^ in versions listed in package.json?
my-test-lib is also a npm repository, same as my-app, so you actual structure is the following.
my-app
├── my-other-lib#1.1.0
└── my-test-lib#1.0.0 (dev dependency)
└── my-other-lib#1.0.0
my-test-lib
└── my-other-lib#1.0.0
You need to have control over my-test-lib if you want to upgrade the packages.
let's say your folder structure looks like that:
workspace
├── my-app
└── my-test-lib
The process you should follow is the following (starting from workspace):
// go to your lib
cd my-test-lib
// upgrade my-other-lib
npm upgrade my-other-lib#^1.0.0
//increase your package.json version
// publish your new version
npm publish
// go back to your app
cd ../my-app
// upgrade my-test-lib
npm upgrade my-test-lib#^1.0.0
with this you should end up with the following structure:
my-app
├── my-other-lib#1.0.0
└── my-test-lib#x.x.x (dev dependency) (the new version you published)
└── my-other-lib#1.1.0
Cheers.
For some reason on my current and previous pc, installing modules in NodeJS does not create PATH variables (Using windows 7/10). I managed to get the modules working in the past by manually editing my PATH variables, but it would be "cool" if NodeJS could do this for me...
I have just downloaded and installed NodeJS and Weinre again. npm gets added to the path variable, Weinre does not. (The same thing happend with Ionic a few weeks back, so had uninstalled it to try it again later).
I am running the command line prompt as an administrator.
Another thing which confuses me, which might be the cause of the problem is the following. I have installed NodeJS in:
C:\Program Files\nodejs"
But running "npm -g ls" gives me the following result:
C:\>npm -g ls
C:\Program Files\IBM\RAD9.1\cordova_cli
└─┬ weinre#2.0.0-pre-I0Z7U9OV
├─┬ express#2.5.11
│ ├─┬ connect#1.9.2
│ │ └── formidable#1.0.17
│ ├── mime#1.2.4
│ ├── mkdirp#0.3.0
│ └── qs#0.4.2
├─┬ nopt#3.0.4
│ └── abbrev#1.0.7
└── underscore#1.7.0
I have IBM Rational Application Developer installed, and it seems like NodeJS refers to this installation folder... :(
If the output of npm prefix -g matches C:\Program Files\IBM\RAD9.1\cordova_cli then everything is behaving as expected. You can either change your global npm prefix to your Node.js executable and reinstall the npm packages, or just add the current prefix to your PATH.
I would probably another clean reinstall of Node.js and npm. Before doing so, make sure to manually delete any existing npm modules and configs:
Run npm config ls -l, find the globalconfig line, and delete that file.
Go to the output directory of npm prefix -g and delete any node and node_modules files or directories.
Uninstall node as usual