My new project needs me to work with TFS + Git.
Confession: I know nothing about TFS.
I want to setup a build for my JavaScript project. I want to use Grunt.
Is this possible? Has anybody used Grunt with TFS?
On our current project, we're using Grunt and TFS. I've integrated Grunt with TFS by caling it from a bat file which you can hook up in the Pre- or Post-BuildEvents section of your project file.
However, because TFS will execute your builds with specific environment variables, you need to use absolute paths.
A list of the things we've done
Install node.js on your build machine (as well as on your development machine(s) ofcourse)
Add a package.jsonfile on the root of your JavaScript project.
Use npm to install grunt-cli locally (!). Use the --save-dev flag to add this package to the development dependencies section in package.json
For all other packages you need, use npm with the same flag as in step 3
Write a bat file (see example below) in which you'll
make use of absolute paths
use npm to install all the packages listed in the packages.json file
call grunt
In your Pre- or PostBuildEvents, call this bat file
bat file example
rem use call to execute other bat files
echo npm install
call "C:\Program Files\nodejs\npm" install
rem because we have listed grunt-cli as a dev dependency,
rem the executable will be located in the node_modules folder
echo grunt
call "./node_modules/.bin/grunt"
I use grunt with TFS when I have to use TFS. I've tried grunt-tfs-unlock, but ran into this issue. I solved the problem using grunt-shell, which works and leaves you more in charge of the configuration. This gist shows how I use TFS with grunt. It demonstrates the 'tf checkout' command, but you could easily create any tf command with this pattern.
I tried all the answers listed here and wasn't able to get a successful automated build and deploy with TFS until I used NCapsulate. It removes the need for NodeJs to be installed separately on build agents or dev machines. Just a NuGet package.
Just make sure you set up your build targets properly and it works very well.
You can find a full example scenario on how to use grunt on the build server:
http://www.codit.eu/blog/2015/03/18/continuous-integration-with-javascript-nunit-on-tfsbuild-(part-23)/
After installing node etc... on your build server, you could also modify your build template and add a step to call grunt etc.... This would prevent you from having to modify your csproj file and allow you to use the environmental variables created by TFS instead.
Related
If I'm developing a library which work is based a lot around of current working directory and the filesystem generally, a lot of paths resolution, and I want to see how it will behave when will be installed as a node module, I don't want to get unexpected results when I'll upload it to the npm. How do I test my library behavior pretending it's a node module? Is placing its folder in node_modules enough?
Make a local package and install it everywhere:
$ npm pack
it will generate a zipped file, so you can copy somewhere and install it.
// another project
$ npm install /path/to/pack
Resources:
npm pack,
Add local package
Absolutely you can use npm link too. link
I am relatively new to using git and GitHub, and I am working on my personal website. I am using the JS plugin Slick, a responsive carousel feature. I downloaded all of the necessary files and stored them within my local repo. The size and content of the Slick zip folder is much larger than the files for my site at the moment, so when syncing with GitHub this makes my project appear as 75% Javascript, whereas the actual website is not.
Am I doing this correctly, storing the files for my JS plugin directly within my repository folder? Or should I be using some other method to implement Slick on my site? Or is this just something I should not be worried about? Thanks
If you're just using one library, manually storing it in your Git repo is fine. You'd have to manually update the files if a new version is released, but that's not a big deal for one library. (And you might not even care about updates to this library).
However if you're using more than one library, I'd highly recommend using Node Package Manager (NPM) and a build tool like Webpack.
Here's an article that introduces these tools (plus a few others): https://medium.com/front-end-hacking/what-are-npm-yarn-babel-and-webpack-and-how-to-properly-use-them-d835a758f987
For using git, you should store your dependencies in a folder that is in your .gitignore. If you install browserify or another similar tool like webpack, you can use the npm package manager to create a dependency list file with npm init that allows for easy package installation with npm install by anyone. You can install packages slick with npm install --saveslick-carousel and use them with require() in your main js file. Then, take your js file and run browserify jsfile.js -o outputfile.js and it will package your js and your dependencies together to be used by the browser
When uploading to your git repo, add a .gitignore like this one for Node. This prevents your dependencies from being uploaded to the repo and instead when someone wants to run your project, they must run npm install to get all the dependencies.
Browserify gives an output JS file you add to your web server, the name of this file should be put in your .gitignore as well. Your code is stored in the js file you pass to browserify and other people can still access it without the output file, but they need to run the browserify command to package your code.
Right now I got a NodeJS backend for a system I built. The problem is that I need to also maintain another instance of the backend for some client specific requirements, both of the instances share like 70-80% of the code. At the moment I'm using git branches to keep them apart, I know git is not meant to do this, so I would like to know if there is something that allows me to have two separate projects sharing some codebase, similar to flavors in Android.
There are few options to do this:
1. Install your own module as separate dependency with npm via package.json dependency.
create own reusable code as separate project on your git space
specify it as dependency in package.json
use it by installing it with npm install, in same fashion you do with regular npm modules
2. Use docker.
Docker is container virtualisation engine, that allows you to create images of vritual environments with pre-installed infrastructure/file system
You just crete image with some linux os inside, node and your module preinstalled, and all you need is to mount your unique code as "volume" to the container and thats it.
use nodejs offcial image - it have everything basic node.js env would need - to create own image. In the folder where you have /reusable_code folder and package.json create Dockerile file
Dockerfile:
FROM node:6.9.2
RUN mkdir app
COPY ./reusable_code /app/reusable_code
COPY ./package.json /app/package.json
WORKDIR /app
RUN npm install -g <your global modules> && npm install
now run docker build -t base-image-with-reusable-code .
It will create and tag the image as base-image-with-reusable-code
Now once you want to use it with any unique code you should do from the folder where the code is (this assuming all unique code use same package.json dependencies used in previous step - if not this will need extra step)
docker run -ti -v ./app.js:/app/app.js -v ./unique_code:/app/unique_code base-image-with-reusable-code node app.js
Of course names should be corrected, and if you have different project structure then the changes should reflect that.
3. Link the reusable code module folder via OS
Simply put, just ln -s /path/to/reusable/code ./resuable_code from your unique code project root folder, and then use it assuming it residing at root of every unique project you have linked it to.
4. Link the reusable code module folder via npm link
as suggested by #Paul :
node native way to do #3 is via npm link, which both sets up the symlink and makes reference to it in your package.json so that your code can treat it as an external module
Assuming you have reusable code folder in same folder where unique code folders are located:
Modified example of the npm link docs:
cd ~/projects/unique_project1 # go into the dir of your main project
npm link ../reusable_code # link the dir of your dependency
Note : all solutions assume you have separate git project for your reusable code. Generally speaking , it's a good practice.
I'm new to node.js and just went through basic tutorials and now ready to set my project with Express.js installed as well.
I'm just wondering what happens if I change my project name to something else now that I've got the framework in place. Can I simply just rename the project directory or do I need some npm package to refactor it properly?
With Ruby on Rails, there is a gem for this purpose and wonder if it's the same for node.js project.
Can I simply just rename the project directory?
Yes.
Express is just a library.
Express-generator (which proviedes "express" command line) is a tool (not actually a framework) to easily build a basic project layout with express, jade and a few other common packages.
Out of the box you can run it by executing ./bin/www (or node bin/www).
Until now, project name doesn't care so far except for if you put it in some template, database register, etc...
Sure you will use some version control system (vcs) like git or subversion and, if you don't want to publish it as npm module, you doesn't need nothing more.
But, even if you doesn't plan to publish it at npm, it is a wonderful tool to manage your project packaging.
If you did it, (by executing "npm init"), then you can take advantadge of some facilities like:
Launch your project with 'npm start'.
Install modules with 'npm --save module_name'.
DON'T track node_modules directory in your vcs.
Get fresh node_modules directory for your current node version with 'npm install'
etc...
All this magic is thanks to a file named 'package.json'.
This file was generated when you did (if you did it) 'npm init' and contains a package name and a version number.
If you doesn't plan to publish your package it also doesn't care so much. But it is a bit more polite to update it accordingly if you rename your project.
I am trying to get up and running with Meteor and seeing what it can offer, while I like it overall, it seems it's a very very rigid system.
I set up a small testing setup using Velocity, it opens a small overlay window on the side which has a class of "velocityOverlay". The overlay is really small and makes error stack traces wrap. All I wanted to do was to edit the css of the "velocityOverlay" and increase the width.
I somehow (after wasting time) managed to find that Meteor is actually putting all the packages in my user directory by default, once I found that, I found the needed css file...
velocity_html-reporter/.0.5.1.aykpxq++os+web.browser+web.cordova/web.browser/packages/velocity_html-reporter/lib/client-report.less.css
And I did a small edit to the width, next thing you know the meteor app crashes when trying to launch using the "meteor" command throwing a "Error: couldn't read entire resource" error. I can't even edit the bootstrap.css file I installed using "ian_bootstrap-3".
Further more, I can't find any way to install packages locally just for my particular project, what if I wanted to modify a package only for my particular project? this is very easy to do in vanilla Node.js, you simply don't use the "-g" when using "npm install".
To add to that, within my project root, there is another ".meteor/local/build/web.browser" folder with most of the global package files replicated again. When does Meteor use which? This is very confusing.
You can run a package locally very easily.
Download it from Github (for example) and put it in the packages/ directory of your application like this /packages/package_name.
Then add it to your application with the same meteor add package_name command as usual.
Meteor will automatically look in the local folder before anywhere else and compile the package with the rest of your code.
This allows you to do any modification you want on the package and test it locally before publishing it to the registry.
Also, folders located in .meteor/local/* are used for building purpose only and are generated automatically by Meteor. So it is not the best place to edit the files!
This worked for me https://atmospherejs.com/i/publishing. mrt link-package didn't work for me, might just be outdated code.
Steps:
Download (or clone) package from GitHub to local dir
Stop meteor if running
2.1. Make sure you have a packages folder: mkdir packages
Locally link your package:
3.1 If you have mrt installed: Run mrt link-package /path/to/package in a project dir
3.2 If you don't have mrt: ln -s /path/to/package packages/package
Then run meteor add developer:package-name, do not forget to change package name
Run meteor in a project dir
From now any changes in developer:package-name package folder will cause rebuilding of project app
Download the package and place it in new package directory in your project root.
open the package.js inside the downloaded package and remove the author's name in the property "name:"
e.g: - name:'dburles:google-maps' to name:'google-maps'
then run
meteor add google-maps