I am trying switch from meanjs 0.4 version to meanjs 0.3 version with the following commmand,
npm install meanjs/generator-meanjs#0.3
This command is giving error "npm ERR! git rev-list -n1 0.3: fatal: ambiguous argument '0.3': unknown revision or path not in the working tree."
How to switch back to meanjs 0.3 version from meanjs 0.4 version?
There is no way to have one version and automatically update to another using the generator.
You have to choose one version and adapt it according to your needs.
The best way to get a MEAN.js project and start working on it, is by cloning the official MEAN.js github repository.
To get the latest version (in master branch):
git clone https://github.com/meanjs/mean.git meanjs
To get 0.3.3 version:
git clone https://github.com/meanjs/mean.git --branch v0.3.3 --single-branch meanjs
Related
I want to build 'riscv-gnu-toolchain' for Sodor Project available in :
ucb-bar/riscv-sodor
I failed to clone it as suggested by its readMe using :
'git clone git#github.com:riscv/riscv-gnu-toolchain.git'
I also tried to use the latest version of the repository, and it generates the following warning :
'configure: WARNING: unrecognized options: --disable-float, --with-xlen'
Which suggests that this is not the right version. I tried to use the version in ROCKET CHIP, but I failed also.
Which version of 'riscv-gnu-toolchain' I can use to compile Sodor's tests?
Thank you Chris. I found a version that work with Sodor. Here are the commands that can be used to checkout this version and build it:
git clone https://github.com/riscv/riscv-gnu-toolchain
cd riscv-gnu-toolchain
git submodule update --init --recursive
git checkout 06c957ab
mkdir build
cd build
../configure --prefix=${INSTALL_LOC} --disable-float --disable-atomic --with-xlen=32 --with-arch=RV32I
make
Sodor currently only supports the Privileged Spec v1.7, so you need to use an older version of riscv-gnu-toolchain. Older versions of the toolchain will recognize the options --disable-float and --with-xlen. It appears that there are no tags on riscv-gnu-toolchain, so you'll have to do some detective work to find the correct commit.
Can someone please explain what exactly are the differences between the following two methods of gulp installation:
$ npm install --global gulp-cli
and
$ sudo npm install -g gulp
It looks to me that both do the same thing except that the first method gives me a version 1.2.1, and the later gives me version 3.9.1
Can someone put into simple terms what exactly are the differences? and plus what is "cli" stands for?
The goal of gulp-cli is to let you use gulp like a global program, but without installing gulp globally.
For example if you installed gulp 3.9.1 globally and your project testGulp4 has gulp 4.0 installed locally, what would happen if you run gulp -v into testGulp4?
Without gulp-cli globally installed :
CLI version 3.9.1
In this case the version displayed is the global version of gulp. The local version 4.0 is totally ignored.
With gulp-cli globally installed :
CLI version 1.2.1
Local version 4.0.0-alpha.2
In this case the version displayed is the global version of gulp-cli and the local version of gulp. The global gulp 3.9.1 is totally ignored.
Conclusion :
gulp-cli: is preferred because it allows you to use different versions of gulp.
gulp: needs a local version of gulp installed.
CLI stands for Command Line Interface.
gulp is a JavaScript library. It lets you use gulp from JavaScript code.
gulp-cli is a utility program that lets you access gulp from your shell.
I had previously installed gulp globally using npm install gulp -g. Then I cloned an existing project, and that required me to use its own gulp. Now when I do a gulp -v from outside my project folder, I get a mismatch like this.
C:\Users\userme>
[11:14:05] CLI version 3.8.11
[11:14:05] Local version 1.0.0
And when I do a gulp from my project folder, I get this.
C:\project\new\tools>
[11:14:26] CLI version 3.8.11
[11:14:26] Local version 3.8.11
Now I have not been able to merge my JS files properly using gulp (I'm getting some weird formatting errors in the min file) and I suspect it has something to do with this mismatch.
Is there a way to remove the global gulp version, but keep the project specific gulp?
Or can I update my global version gulp to #3.8.11?
Note - I did try updating the global gulp by using npm update gulp#3.8.11 -g but nothing happened. i still get the mismatch.
Update to describe the issue:
I am using gulp to merge multiple JS files into 1 single main.js file. The formatting that I get in the merged file has a syntactical error in it.
Expected output in merged file -
...
define('utils/knockoutBindings/slider',['require','ko','jquery'],function(require) {
'use strict';
var ko = require('ko');
var $ = require('jquery');
...
Actual output in merged file (this 1 line of code below is wrongly replacing the entire 4 lines above) -
...
var'utils/knockoutBindings/slider',['require','ko','jquery'],function(require) {
...
It might seem that there is an issue in the gulp code, but the same code is used by other users and it works well on their end. The only difference we have found is in the mismatch in my gulp versions.
I am answering my own question, just so it is useful for others.
Is there a way to remove the global gulp version, but keep the project specific gulp?
No. AFAIK, you are required to install gulp globally as well as one specific to your project.
More info on gulp versions here.
Why do we need to install gulp globally and locally?
http://blog.dwaynecrooks.com/post/110903139442/why-do-we-need-to-install-gulp-globally-and
https://github.com/gulpjs/gulp/issues/171
https://github.com/gulpjs/gulp/issues/140
Or can I update my global version gulp to #3.8.11?
Since I was facing a mismatch in my local version, I had to update it from the project folder itself.
npm install gulp#3.8.11 --save
More info on this here.
http://www.eskocruz.com/gulp-version-mismatch
To update your Local version npm install gulp#version_you_need
To update CLI version npm install -g gulp#version_you_need
Removing node_modules folder and running npm install gulp within that dir sorted my issue out.
npm install -g gulp wasn't fixing it for me, from either in or out of the project folder. My gulp version was already correct in my package.json file. All I had to do was run npm install from within the project folder, and the gulp version from in the project folder was corrected.
Updating both the local version same as that of the global version fixed the issue. My initial gulp -v yielded CLI version 3.9.1 and Local version 4.0.0. I updated the local version from within the project folder npm install gulp#3.9.1 --save. This resolved my issue .
Gulp 4 uses an updated CLI which needs to be updated globally. This CLI is backwards compatible with any Gulp 3.X projects you may have locally - Read more.
It seems that the latest version (at the time of this post) of gulp-cli is 2.3.0 which means there will always be a mismatch.
If you run npm install -g gulp, then the latest version of the CLI will be installed. If you have any other version installed then it will update to the latest version.
The local version's latest release (at the time of this post) is 4.0.2.
Run npm install --save-dev gulp to install the latest version of Gulp in your project folder as a dev-dependency. Like with the CLI version it will update if you have an older version.
Mismatched versions work like normal.
SIDE NOTE: Remember to prefix global installs with sudo if you're working on a Mac and you have admin rights e.g. sudo npm install -g gulp.
BUT if you don't have admin rights and you can update the local version, but not the global version, then you can run node ./node_modules/gulp/bin/gulp.js from your project folder and it will execute the gulp file, even if you have the wrong CLI version, but you need to have the default task set up.
I'v made a static single page site using grunt. I'm now trying to deploy it to heroku using the heroku-buildpack-nodejs-grunt for node grunt.
Below is a pic of my root directory:
Here's my Gruntfile package.json:
Procfile:
web: node index.html
When I run $ git push heroku master it gets to the Gruntfile and fails:
-----> Found Gruntfile, running grunt heroku:production task
>> Local Npm module "grunt-contrib-uglify" not found. Is it installed?
The above errors proceed to list all local NPM modules as not found. If I list all loadNpmTasks instead of using "load-grunt-tasks", I get the exact same error.
When I $ heroku logs I get:
Starting process with command `node web.js`
Error: Cannot find module '/app/web.js'
Can anyone see where I've gone wrong?
For anyone passing by here, I wasn't able to solve the problem. This is where I got to:
In my Gruntfile, I moved npm modules from devDependencies to dependencies. Heroku was then able to install these dependencies.
However, when Heroku ran the tasks, it stops at the haml task w/ error "You need to have Ruby and Haml installed and in your PATH for this task to work". Adding ruby & haml to the Gruntfile as engines did not work.
The only thing I can think of is that maybe Heroku installs your devDependencies first, tries to run Grunt, but since it didn't install load-grunt-tasks yet, you don't get the grunt.loadNpmTasks( 'grunt-contrib-uglify' ); line (which load-grunt-tasks does for you), and thus Grunt can't find the package.
Can you try changing your Gruntfile to explicitly list out all npm modules using the grunt.loadNpmTasks() method?
EDIT:
Just remembered another thing I had to do:
heroku labs:enable user-env-compile -a myapp
heroku config:set NODE_ENV=production
(Obviously replacing myapp with your Heroku app name.)
This makes Heroku allow user set environment variables and then sets your server to production. Try that, and set your dependencies and devDependencies as you had them originally (just to see if it works).
I am coming pretty late to the game here but I have used a couple methods and thought I would share.
Option 1: Get Heroku to Build
This is not my favorite method because it can take a long time but here it is anyway.
Heroku runs npm install --production when it receives your pushed changes. This only installs the production dependencies.
You don't have to change your environment variables to install your dev dependencies. npm install has a --dev switch to allow you to do that.
npm install --dev
Heroku provides an article on how you can customize your build. Essentially, you can run the above command as a postinstall script in your package.json.
"scripts": {
"start": "node index.js",
"postinstall": "npm install --dev && grunt build"
}
I think this is cleaner than putting dev dependencies in my production section or changing the environment variables back and forth to get my dependencies to build.
Also, I don't use a Procfile. Heroku can run your application by calling npm start (at least it can now almost two years after the OP). So as long as you provide that script (as seen above) Heroku should be able to start your app.
As far as your ruby dependency, I haven't attempted to install a ruby gem in my node apps on Heroku but this SO answer suggests that you use multi buildpack.
Option 2: Deploy Your Dependencies
Some argue that having Heroku build your application is bad form. They suggest that you should push up all of your dependencies. If you are like me and hate the idea of checking in your node_modules directory then you could create a new branch where you force add the node_modules directory and then deploy that branch. In git this looks like:
git checkout -b deploy
git add -f node_modules/
git commit -m "heroku deploy"
git push heroku --force deploy:master
git checkout master
git branch -D deploy
You could obviously make this into a script so that you don't have to type that every time.
Option 3: Do It All Yourself
This is my new favorite way to deploy. Heroku has added support for slug deploys. The previous link is a good read and I highly recommend it. I do this in my automated build from Travis-CI. I have some custom scripts to tar my app and push the slug to Heroku and its fast.
I faced a similar problem with Heroku not installing all of my dependencies, while I had no issue locally. I fixed it by running
heroku config:set USE_NPM_INSTALL=true
into the path, where I deployed my project from. This instructs Heroku to install your dependencies using npm install instead of npm ci, which is the default! From Heroku dev center:
"Heroku uses the lockfiles, either the package-lock.json or yarn.lock, to install the expected dependency tree, so be sure to check those files into git to ensure the same dependency versions across environments. If you are using npm, Heroku will use npm ci to set up the build environment."
Any hints on how doing this? I tried with the auto-install from a downloaded zip from this here, extracted here: OPENSHIFT_DATA_DIR/hg and executable location here: OPENSHIFT_DATA_DIR/jenkins/data/tools/Mercurial/mercurial-2.2.1/bin/hg
I'm doing something wrong for sure, I'm not Linux saavy. Jenkins says is unable to find mercurial executable.
Any help is more than welcomed.
Here's the answer from here:
Thanks for the email discussion.
Mercurial includes a README which explains a couple of modes of execution:
Basic install:
$ make # see install targets
$ make install # do a system-wide install
$ hg debuginstall # sanity-check setup
$ hg # see help
Running without installing:
$ make local # build for inplace usage
$ ./hg --version # should show the latest version
"make install" will not work as it attempts to do a system-wide install. The user on the gears will not have access to write to system files.
"make install-home" will not work either.
"make local" works and will install it in cwd such that running the following will should work just fine:
./hg --version
Mercurial Distributed SCM (version 2.2.1)
(see http://mercurial.selenic.com for more information)