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.
Related
Potential similar question here.
I'd like to build a simple in-browser app that can run without an internet connection.
To develop a Python project, this isn't even a question. You just pip install whatever in your favorite virtual env and run offline all day. Your dependency list is also managed for you locally.
While building a toy project with npm, I can't figure out how to do the above. Parcel seems like a good tool to build, bundle, minify, etc. But in the end, all dependencies still point to a CDN. I understand this is default behavior, but there seems no way to easily pull all dependencies local and run offline.
Not a web dev so if I'm asking the wrong question, that sort of insight is appreciated also.
Edit: I've already built all the functionality I need. I can run successfully from file:// or a simple http server. What I'm trying to do in consolidate all the dependencies locally so as to not depend on a CDN at runtime. It'd be better to not go to each CDN/GitHub repo, manually download JS/CSS dependencies, and then manually link to them from my code. That's the point of using a bundler or similar. Is Electron or another framework really the best way to do this? For my use that feels like a lot of overhead.
You can use npm to install and maintain your dependencies. Lets say you are create your project from start. You will need to do the following steps. Assuming you have npm installed.
mkdir my-project //create project directory
cd my-project // cd into project direcotry
npm init // init npm project inside the directory.
After this you can install javascript packages using npm i package-name
I'm working on node.js app that is written in Typescript, which means it needs to be compiled to JS before running. As I'm coming from java/jvm background where you ship prebuilt package to server and it gets run there I'm a bit afraid of the way of deployment where you push code to git and it's being built/compiled on server first and then run.
I don't like it for two main reasons:
dev dependencies need to be installed on server
deployment depends on external resources availability (npm etc).
I found NAR https://github.com/h2non/nar which is more or less what I wanted but it has some drawbacks (doesn't work with some deps that have native extensions).
My question is: is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server? Or should I let that sink in and do it that way?
To be honest I don't believe there are no more sane/reliable options for that.
What you can do (but there are probably other perfectly valid approaches) is building your project locally (or on a CI service), and only deploy this built version when you consider it as valid (tests, etc.).
This way, if something bad happens, like npm that fails, or a compilation error, you don't deploy anything, and you have time to resolve the situation.
For example, I used to have a gulp task (but it can be anything else: Grunt, a simple npm script...) that clone a production repository and build the project into this directory.
That way, I can check that my build is valid. If it is, I make a new commit and push it to the production repo, that is served the way you need (on a Heroku instance for example).
Pros
Clear separation of dev and non-dev dependencies
Deployment only when you know that the build is valid
No built files on source control on the development repository
No "live" dependency on external tasks like npm install or tsc build
Cons
You have two separated git repositories (one with the source code, one with the built version of your project)
Production process is a little bit heavier than simply committing to master
(From comment) Doesn't properly handle the case of npm package that relies on native extensions that have to be (re)built
is there any other "sane" way of doing deployment node.js deployment than this risky combination of npm install and tsc on server
package.json + npm install + tsc is the way to do it. Nothing risky about it.
More
Just use an npm script : https://github.com/TypeStrong/ntypescript#npm-scripts
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
If I have a directive, and I wish to package it in its own node package; and then include it from another another node package containing the main angularjs app, how would I do this?
My rough idea about how to go about this is:
put the html, javascript, and css for the directive in the package folder
enable compilation of these assets - preprocessing, minification (how?)
configure as bower package
in the app folder install the bower package
how to do this locally, without publishing?
in the angular.module() statement that creates the main app, add the name of the module containing the directive
Is this correct?
Have I missed out on anything?
Your idea of how to go about this looks good to me. To answer your questions in the list:
Look at Grunt or Gulp for your preprocessing / minification needs. These are both excellent build tools. Grunt is more widely used, but Gulp is newer and gaining a lot of ground. I'd look at both and use the one that suits you.
How to use a local bower dependency w/o publishing:
In your main app's bower.json file, instead of putting a version number for your module, put the folder where it can be found on your local system, like so:
{
"dependencies": {
"my-module": "/home/me/modules/my-module"
}
}
To clarify, you refer to it as a "node package" in your question, but in reality, you are creating a Bower package. Node packages (published to npmjs.org) are for node, and unless processed with something like Browserify, won't run in the browser (and even then, the node package can't do anything the browser doesn't support, like file access.) Bower packages (published on bower.io) are specifically for the browser. You will however find packages that publish to both NPM & Bower, such as jQuery or underscore, but you can't use the npm jquery package in the browser, it's built to run in node, and vice-a-versa.
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.