I'm aware that I can select the node version to use with NVM but, can I build two angular projects (with different ng version and node version) at the same time without issues? My scenario is a self-hosted build server (Windows) with two agents. Each of these might be, at the same time, on charge of building an Angular app with different version.
Regards
Sure you can, instead of running the globally installed ng run the local one with npx like this npx ng build, npx will use the local installed #angular/cli ng command found under ./node_modules/.bin/ of your project, npx comes installed with npm.
Another option is to add a script in package.json:
"scripts": {
"build": "ng build --prod=true --build-optimizer=true --aot=true",
},
And runt it with npm run build.
As #Andrei stated, is not possible to use NVM to set the Node version at the beginning of pipeline because it will change the version in all open consoles (so, if another pipeline with a different version of Node is running, would be affected).
Luckily, I found an easy workaround which does not require install additional tools or change package.json:
Download the node version you want as zip file
Unzip to a folder in Agent (like C:\LocalNode\node-v17.8.0-win-x64)
Add Node path to PATH environment var only for current pipeline
To add Node path only for current pipeline, we have to add a Powershell task as first task of the pipeline with the current command:
Write-Host ("##vso[task.setvariable variable=Path;]D:\LocalNode\node-v17.8.0-win-x64;$Env:Path")
Rest of the tasks of the pipeline will use the Node version from D:\LocalNode\node-v17.8.0-win-x64
If you want to create a pipeline for a different Node version, just add the version to D:\LocalNode and use the above command with the right path as first task of the pipeline. No problem if both pipelines run at the same time.
Related
I have installed Node JS and then imported an existing work project in Visual Studio Code. After that I ran npm install in the project folder, then run npm start and the app comes up fine. However, if I run an ng command I get an error telling me "ng is not valid command", even though the Angular CLI is in the modules folder.
I tried manually installing Angular CLI globally and set system path to point to the npm folder, and then the ng command works fine. What I don't understand is why do I need to install CLI globally if I just want to run that command within the project where the module is already present?
As a general rule then you will need to install globally any commands you wish to use (without NPX). This isn't really a restriction of NPM so much as it is a fundamental way in which command line programs work. The OS will only look in fixed predefined locations set in PATH. This applies to any Node based tool such as grunt or ng or whatever.
(While some systems do look for executables relative to the current working directory, or can be configured to, it's generally not a good or reliable method and NPM doesn't rely on this behaviour).
For something like the Angular CLI then installing it globally should be fine and is what many people will do. As a general rule if it is a command you want to run, rather than a dependency for a project, you can consider installing it globally. You'll notice that on the Angular CLI page the example does exactly that.
In many cases however you might want to run a command from a local project. Perhaps for a build script or something else where you want to keep it isolated. In that case you instead prefix your command with npx which will look inside the local project for commands.
I'm very new to Node Package Manager and also Vue, and I'm trying to understand what exactly is going on with using the Vue CLI.
The vue.js website has this as instructions for running the official Vue CLI:
I have a few questions about this:
Does npm install --global vue-cli need to be executed only once on a machine, or once on a directory, or once per new project you're starting? In other words, once it's on your computer, is that the last time you need to run that command, or do you need to execute this command every single new project you start?
Once a new project is initiated, are local copies of the newest version of vue (and vue-router, if selected) installed?
If I finish this project and want to deploy it, how do I then port this over to a production server?
Once in a machine, except for the rare cases where one is isolating one's npm install (such as by using nodeenv or inside a container); that's what the global option is for.
After running npm install, yes.
Running npm run build and copying the contents of the resulting dist directory to the production machine (often within a /var/www directory or similar). This can be automated further in many ways.
I'm trying to deploy a grunt based app to CC. I would like to deploy the dist version of the app, which is generated with the grunt build task. Right now, what I've done is to move my grunt devDependencies to dependencies and use the NPM postinstall hook to run the grunt build task. This way once updated NPM dependencies CC runs the task.
But, I've two issues with this approach:
1) compass is not working
2) it just doesn't feel correct to move all my grunt dependencies to dependencies. The first issue I think that I could fix it using another SCSS grunt module.
Any other alternative approach? Preferably I don't want to save my dist builds in the repository.
Can you please explain the situation a little bit more?
Normally I would follow the following steps
Local
Do the npm install
Do the grunt build
push to the cloud
Server
Set the environment as production(assuming that all your files check for the environment and load files accordingly)
I'm using grunt and also grunt plugins like grunt-contrib-copy, grunt-contrib-mincss (that listed as npm dependencies for my application).
Also I don't commit npm_modules folder and public folder, where all generated files are. And I can't figure out how to build my app (I have grunt build command) after deploy and setup my server (it's already looking for public folder).
I saw some stuff like grunt-heroku-deploy, but it seems me a bad idea to commit before upload. Maybe there are some gentle decisions... Any thoughts?
npm has a support for a postinstall step (among many others) that might be just what you're looking for.
The node.js heroku buildpack runs this command when you push to heroku to resolve build dependencies:
$ npm install --production
https://devcenter.heroku.com/articles/nodejs-support#build-behavior
If you take a look at the npm documentation, you can setup a series of scripts to run either before or after anyone runs npm install for your package. It's configured in the scripts property of package.json. The scripts property allows to run custom scripts (including grunt) when certain things happen in a package's lifecycle.
For example, to echo some text and run the grunt command whenever anyone (including Heroku) runs npm install, add this to your package.json:
{
...
"scripts": {
"postinstall": "echo postinstall time; ./node_modules/grunt-cli/bin/grunt <your task name>"
},
...
}
https://npmjs.org/doc/scripts.html
Important caveats:
You might have to change the path to the grunt binary in the postinstall script, check the error output if the grunt command doesn't execute.
grunt and grunt-cli must be listed as a dependency in your package.json so it gets installed by Heroku. Listing them under devDependencies is not sufficient since Heroku won't install those. Also, note that Heroku won't install it as a global package so to execute it on Heroku you're going to have to use a relative path (as it is configured above).
If this doesn't work (you'll probably need to fiddle with the relative paths a bit), then you might want to consider writing your own custom buildpack for Heroku.
Update
As of 0.4, the grunt package no longer contains the grunt binary, which is now part of the grunt-cli package. The answer has been updated to reflect this.
This looks like it will largely be solved when the Heroku Platorm API slug and release features make it into the mainline. At that point, you can build your code locally (or on a ci server), package it up and send it to heroku via an API call and release it from there.
This is still in the beta period and was only announced on December 19, 2013.
https://devcenter.heroku.com/articles/platform-api-deploying-slugs
I was never super happy with how many people seemed ok with checking in your generated code into git or the NPM postinstall hook. :(
Plus from a philosophical stance, doing a build during a release is simply another potential failure point.
Just for fun: Since that's not finalized yet, here's a bash script I threw together you can use for the time being to build your code on a deployment branch, commit it, deploy it to heroku and then remove the deployment branch. (I really am not a fan of bash deployment scripts, so I'm really looking forward to the platform API additions)
#!/bin/bash
set -e
# Delete current deploy branch
git branch -D deploy
# Create new deploy branch based on master
git checkout -b deploy
# Grunt comands to build our site
grunt build:production
# the dist/ directory is in my .gitignore, so forcibly add it
git add -f dist/
git commit -m "Deploying to Heroku"
# Push it up to heroku, the -f ensures that heroku won't complain
git push heroku -f deploy:master
# Switch it back to master
git checkout master
Grunt (et al.) is a build tool, not (really) something you should be packaging up and running on production. A different approach would be to use Grunt to prepare your project locally (or better on a CI server) before only pushing the built files to Heroku. As already mentioned Heroku will do an npm install on your app after its pushed which should be enough on its own to finally prepare your app.
I have it set up so that the Grunt derived/built Heroku app lives in a totally separate Git repo to my main app source code repo. So that when I do a grunt deploy it optimises and copies the relevant files to the Heroku repo, tidies it up (git add -A etc.) and then git push heroku master (or whatever).
It seems like a cleaner separation of concerns if your live servers are only responsible for running a pre-built app package.
YMMV of course, and the accepted answer above is totally valid too ... especially on a well understood and stable live environment like Heroku.
Heroku buildpack works fine for me. Great stuff.
To get this working with grunt 4.0 I followed the instructions here https://discussion.heroku.com/t/grunt-on-heroku/98/2 . The only change I had to make was to remove the path to grunt as using unix style slashes would make it fail in windows and vice versa. Luckily you don't even need to specify the path as NPM will look for grunt in the node_modules/.bin folder https://npmjs.org/doc/scripts.html#path.
make sure you have both grunt and grunt-cli installed locally in your package.json even if grunt tells you to install the cli globally: $: npm i -S grunt grunt-cli
add a postinstall step to your package.json that looks like this: "postinstall": "grunt prod"
The npm postinstall step is probably your best option, since you can invoke grunt from there. But you should also check out a custom buildpack, such as heroku-buildpack-nodejs-grunt.
This post is Rails-specific but I don't see why you couldn't use it with any back-end framework and just swap the Ruby buildpack with whatever you're using.
The solution is basically to use multi buildpacks, and have the Node/Grunt buildpack run grunt build for you right on Heroku.
Significantly, this solution does not have you check build artifacts into version control. (Yay!!!)
http://www.angularonrails.com/deploy-angular-rails-single-page-application-heroku/
I'm using Testacular which is a Node.js test runner for Angular/Jasmine. I can run it fine from the command line, but every time I try to run it from Jenkins build steps, it bombs out with all sorts of errors regarding environment variables. I tried the Nodejs plugin for Jenkins, but that's just to run node code snippets. Anyone know of a way to have node apps (eg. Testacular) running test under Jenkins?
You will need to:
have "testacular" as a dependency in your package.json file.
install your dependencies with npm install (do this as a build step)
call it as ./node_modules/.bin/testacular start --single-run
Assuming you have configured testacular to use PhantomJs browsers = ['PhantomJS'];, you just need to have the phantomjs binary in your path or tell testacular where it is located with an environment variable set in your shell:
export PHANTOMJS_BIN=$HOME/local/bin/phantomjs
good news!
" I tried the Nodejs plugin for Jenkins, but that's just to run node code snippets. "
nope!
install the nodejs plugin see instructions here -> NodeJS jenkins plugin broken?
then tick "Provide Node/npm bin folder to PATH" and when running a "execute shell" build task, you can use nodejs, here's a example using grui
npm update
grunt
grunt --force reporting