I am just getting into the GIT / GULP / Bower workflow. I am basically a complete noob. I have a WordPresstheme being developed on my local machine via MAMP.
Say I wanted to package it up and open it on another Machine, either with Mamp or Wamp.
I don't think I can zip the theme folder with all the NPM Nodules, so what would be the best steps to take to avoid any or minimal bugs.
If you're using git you need to commit and push your changes to a remote repo. Then pull the repo down to the second machine and re-run the build process.
In roots sage 8 that will mean:
Installing bower and npm globally (if you haven't already done so)
Installing the bower npm packages for you project
Running the gulp build task
In Sage the npm modules, bower packages and dist folders are ignored by git because they are listed in .gitignore.
In general it's usually considered good practice NOT to commit any dependancies to your projects repo.
Related
My node app will deploy in a bank that can't access the internet. Can I download all the node modules in a local directory, and install them from it, or just copy the node_modules to the bank machines? Any safe and practical advise will be highly appreciated, thank you.
OR
How to add node_modules dependencies without using internet .
Add offline-npm to your project to serve a npm compatible tgz file wich contains all dependencies for offline installation with npm install.
Additionally you can use offline-npm -n to install packages from your local npm cache directory
For installation
npm install -g offline-npm
Usage
1) Open terminal and go to your project you want to prepare for offline use. This folder needs to contain a package.json file.
2) Prepare your project for offline use
offline-npm --add
3) This changes the package.json file and adds a offline folder which will contain all your dependencies.
Pack your project
npm pack
For more details , visit the Link
Hope this answer gets useful to you .
Typically you will want to bundle your node_modules into your deployable artifact.
There are some gotchas here around any native dependencies as you need to match the nodejs version of the build environment with the target system.
The easiest way to achieve this in my experience is by using docker to build and package your deployment. Though it is possible to do when running directly on host machines, you may find it safest to just avoid the usage of native dependencies to remove any risk of things breaking from a nodejs or os update.
I've also successfully achieved this packaging the nodejs binary into my deployment artifact that was deployed directly on centos hosts, however we had a mixture of centos 6 and centos 7 hosts at the time, which brought additional complexity related to different glibc versions causing nodejs to fail to start with the system provided library.
In short if you can I would use docker to package your application into a completely self contained image.
you can just copy the node_modules into the deployment machine but it is bad practice.
there are other solutions like using local-npm package... your npm installs are fetched from the registry and then modules and their dependencies get stored in a local PouchDB database. This caches them so subsequent npm installs use the local cache rather than calling to the network. local-npm also takes care of keeping modules updated when they change. It does this by listening for changes to the remote registry so you don't have to worry about staleness.
or bundling your packages to use them offline you could visit this link for more details for offline installation of npm packages:
https://addyosmani.com/blog/using-npm-offline/
How to install node modules in local network?
1. Solution: yarn offline and 'Offline Mirro'
One of the main advantages of Yarn is that it can install node_modules from files located in file system. We call it “Offline Mirror” because it mirrors the files downloaded from registry during the first build and stores them locally for future builds.
2. New problem: How to use yarn in local network?
Download yarn.tar.gz into the local repository, and install it in local node_modules directory.
npm install yarn.tar.gz --no-save
3. Usage
# run yarn install, and download the node modules (.tar.gz) into the offline mirror directory '$REPOSITORY/yarn/yarn-offline-mirror'.
npm run online-install
# with yarn.lock file, install node_modules from offline mirror directory '$REPOSITORY/yarn/yarn-offline-mirror'
npm run offline-install
4. Problems
4.1. problem 1
4.1.1. description
error can`t make a request in offline mode("http://....")
4.1.2. reason
the indirect dependencies could not be downloaded into offline mirror directory
4.1.3. resolution
yarn config set yarn-offline-mirror-pruning false
5. Github demo
yarn-offline-deploy-demo
6. Reference
1. Running Yarn offline
I've recently upgraded my netcoreapp1.0 to netcoreapp1.1. This left me wit ha few surprises and error that needed to be fixed. On top of that, I recently got a new PC, which forced me to go through even more things.
First up I had to install NodeJS again, and from the node package manager, install bower. After installing both NodeJS and bower, and several hours after working on my project, I realized, as I had to commit the changes to remote source control, that a node_modules folder had appeared (though hidden) in my project. Git of course wants to commit this folder, but I'd rather not since it contains loads of subfolders and other items.
I was wondering what to do with this folder. I believe it shouldn't be there? And I'm not sure why it is. Shouldn't it be global or something, specific from PC to PC? Or should I just add it to my .gitignore file?
Quick info: It wasn't there prior to the upgraded project, meaning that I couldn't see any node_modules folder in netcoreapp1.0 and there's no folder in my source control?
This node_modules folder wasn't there before because before it was installed globally:
npm install -g bower
the advantages of globally installing bower is that you can use the bower command through the command-line directly.
now apparently bower was installed locally, with the following command:
npm install bower
Now it was locally installed in the node_modules folder, meaning this folder appeared.
You don't need to check this folder into get and you can simple add the following rule in your .gitignore file:
node_modules
But 1 thing to remember! when you build your application with teamcity or some other CI build tool you will now need to install npm packages (just run npm install in the folder) before you publish your application, otherwise these javascript files will be missing.
I'm working in a web application (JavaScript/C#, version controlled by TFS) and our team wants to start using Visual Studio 2015. Microsoft is moving developers to use existing popular tools like Gulp for automated tasks, so I've written a few Gulp tasks that will run on the server.
My problem is that our automated builds generate new project folders on the build server, so I can't run gulp myBuildTask without first running npm install. The npm install adds over 2 minutes to the build process, and it seems very inefficient to download the same dependencies for every build (since they will change rarely).
Is there anyway I can run a Gulp task on a new project folder without first running npm install?
Options I've considered:
Include node_modules in TFS. I couldn't add the node_modules folder to TFS (which would cause it to exist in each new build folder) because bower's nested dependencies have file paths that are too long for Windows. I could go this route without bower, but I'm not certain I want all those files in my solution (much of which is not needed, like readme's and test files).
Run npm install after each automated build.
As already mentioned, I don't want to do this because it adds several minutes to the build process.
Install NPM modules globally.
I'm not sure if this is even possible, but I'm wondering if I can install all project dependencies globally on the build server (avoiding having to install at the project level). My concern with an approach like this is that I don't want to have to manually update the build server's globally installed NPM modules every time we add a gulp plugin.
Ideally, the solution would be something like #3. The modules would install globally, but every build could run an npm install which would verify every module is installed. If a new npm module was added to the package.json, it would be downloaded. This npm install would be pretty fast since in most cases, all modules would already exist (globally installed on the build server).
There are a few things you might do:
Make npm install run faster. For this purpose, use newest npm (if possible) or use npm dedupe. Running dedupe may result in having less dependencies than with plain npm install. Then run npm shrinkwrap which creates npm-shrinkwrap.json file which contain 'freezed' info about what exactly gets installed (and in which version) during npm install.
Remember, node_modules is just a directory, if you can copy / rsync it to your installation, you can skip the npm install phase altogether
Node package resolution approach is to first try local node_modules directory and if not successful, (node_modules not there or dependency missing in node_modules) check out node_modules of the parent directory, then grandparent directory and so on. This means, you don't have to install packages globally, semi-global installation is quite sufficient
:
my_project
node_modules/
dependency1
dependency2
build_001/
build_002/
build_00x/
no node_modules here,
no deps here
Note however, that this, naturally, works only if your dependencies are really not changing. Since in real life you install something new from time to time, slightly enhanced approach might be helpful: organize your directories as follows:
my_project
ver_af729b
node_modules
build_001
build_002
ver_82b5f3
node_modules
build_003
build_004
af729b and 82b5f3 being (prefixes of) sha hashes of your npm-shrinkwrap.json file. If you then add new dependency, shrinkwrap file gets updated, build script creates new ver_something directory and executes npm install in it. Doing all this would naturally require extra work, but it should work great.
------------------ EDIT -------------------
If you are not trying to avoid npm install completely (you just want it to be quick) you can stick to the typical scenario: you checkout the sources always to the same directory, and let npm install re-use the old node_modules as much as possible.
If you want always to create a new directory for your build, you may still create a node_modules symlink to the older version of node_modules - also in this scenario, npm will reuse as much as possible from symlinked folder.
I'm evaluating JHipster; it looks great for rapid development!
Maybe a novice question: I see that the generated .gitignore ignores certain things, e.g.
/node/**
/node_modules/**
So, if I check in the generated project to a repository, and then some other developer in my team checks it out in his environment, the project would not work in his environment. Would it?
Was curious to know how to handle this. Thanks.
Since your git repo won't track node packages, others using your git repo will need install node.js, then run npm install to download all the node packages.
It's similar to them having to have java and maven installed on their environment.
Update: A developer will run 'git clone '. The source (not including node or bower) will be on their workstation. Once they've installed node.js, they'll run 'npm install' and the node directories will be created automatically for your project by downloading them from the Internet. That way you don't need to keep all your node libraries in your own git repository ...just their package name and version in the package.json file (similar to maven dependencies in pom.xml).
No one should commit the node_modules or bower_components to git, what you would do is share the project like you share the maven projects.
Write in the read me what needs to be done to get them ready, for example the installation of yo, bower, grunt or gulp and generator-jhipster.
What is very nice about liquibase, each developer can have his own version of the database, and every commit has its own database version.
What we our team does, if a developer adds something to node js package.json then we mention it in the comment: npm install needed and the same applies for bower.
That way you keep all your environments clean, and if you would like to install continuous integration like "Jenkins or Teamcity" then you make sure Jenkins is building rebuilding the whole project.
I'm working on my application. In parallel, I'm working on updating(and adding to) a couple of the npm installed submodules at the same time.
In my package.json dependencies I have:
"zeke-bootstrap": "git://github.com/twilson63/zeke-bootstrap.git",
When I do npm install, it goes and checks out the repository and puts it under node modules just fine. My question is how to I setup this directory so that I can use git, and do commits, and eventually a push to send my changes in my dependent directory back up to github?
Thanks,
Fred
You can checkout your git repo in the node_modules folder under the same folder name as your module and node will automatically use it. However, I don't think its a very good idea. Modules are modules because they are meant to be developed separately.