I used generator-angular a few months ago to scaffold a project and the whole ecosystem (karma, Node versions, grunt packages) has moved on quite significantly. I keep running into problems running tests, building things, and so on.
I know I can use nvm to downgrade my Node version and install older packages, but that kind of sucks, especially when there are many developers on the team. I have used the generators for 10+ projects over the past few months so I'm very interested in a solution.
Is there a recommended upgrade path for when new versions of generators are released, apart from just regenerating the project and copying files across?
(Just to note: this isn't a problem with upgrading a Yeoman 0.9 project.)
First make sure you have committed everything or have a backup, then just scaffold out over the project again. yo will ask you for each file if you want to overwrite. For those files you haven't edited, just say yes. For the other ones, type d for diff and see what's changed. Then manually do the changes, and run npm install & bower install to get the latest dependencies.
EDIT
As mentionned in comments by Markus Gattol :
yo <generator-name> now already run bower install & npm install i.e. no need to run them explicitly again – Markus Gattol
Related
Is there a recommended process, script, or reference for upgrading Grails 3.1 apps to the latest maintenance release version?
Currently upgrading from 3.1.3 to 3.1.8 and there are some dependency updates (e.g. asset-pipeline) that are not mentioned in the release notes (https://github.com/grails/grails-core/releases). I only found them by comparing configs from a sample create-app run.
This process has worked for me:
First, download the new grails to your machine. I usually download the tar.gz to /usr/local, gunzip, tar xvf, to /usr/local/grails-3.1.8 or whatever.
Second, add this to your .bash_profile:
GRAILS_HOME=/usr/local/grails-3.1.8
export GRAILS_HOME=$GRAILS_HOME
PATH=$PATH:$GRAILS_HOME/bin
export PATH=$PATH
Third:
source .bash_profile
Fourth, go to your projects directory, and:
grails create-app test-3.1.8
cd test-3.1.8
nano build.gradle
Here, you will see the new dependency version numbers that are required
for your new version, in this case 3.1.8. (As I write, 3.1.9 is out.)
Now, go back to your old project's build.gradle and update the
dependency version numbers to match.
Stumbled across this handy repo to automate the app comparison process https://github.com/erichelgeson/grails-versions
I am getting a bit confused here.
I have an MVC 5 project, I want to use the npm for managing my javascript packages.
I installed npm from nuget and here i am stuck, I cant find the commandline console window or anything like that.
All the info i see online is about node projects.
Can someone direct me to a relevant tutorial.
Using visual studio 2013, MVC 5.
Well regardless of the project, if you want to use npm on Windows, this is what you need:
Download and install Node (you might need a restart).
Make sure that node is installed by opening a command prompt and running node -v (should print a version number).
Run npm -v and see if it's installed (should be).
Now in the context of an ASP.NET MVC project. The newer versions of Visual Studio (I believe 2015) support npm - you can just open the package.json and add dependencies (it will download them behind the scenes). In case you're using an old version, you can simply open a command prompt, navigate to your project and use npm install from there.
Situation I have is described here: How to resolve Bower dependency version conflicts?
The problem is that proposed solution does not work. Adding a resolution section to bower.json does nothing and it still requires to choose package version manually on each installation.
But, surprisingly, when I install bower packages though Grunt (with grunt-bower-task), it just works, even without resolutions.
I have the latest bower version (1.4.1 for now).
Does anybody know what's going on and is it possible to make bower to install without manual resolution?
You can use "--save" or "--save-dev" when you install and resolve these conflicts - in this way, bower will update accordingly the json file. Next time when you run bower install, bower will read the written sections and will not ask you any more.
No need for manual edits - unless you know what you're doing.
I've created a Yeoman generator and want my team to use it.
What happens if I update my generator on Github? They installed the generator locally in an older version. Do they always have to install again to get the latest version?
Team members don't know when updates happen and I don't want them to care too much about it. I just would like for them to use the latest version of the generator.
What is the suggested way of updating generators?
Thanks
Glad you asked!
Starting with Yeoman RC1, which will be announced later today, there's a brand new way to manage your generators: Just enter yo and enjoy the new wizard:
If you select "Update Generators" from the menu, yo yo will take care of bringing them all to the latest version.
If you are a generator author and want to go one step further to make sure your users are always up-to-date, you can use update-notifier from the Yeoman project to greet users with a notification if they run an obsolete version.
If you want to update a specific generator you can run
npm update generator-mygenerator -g
Nice if you have many generators installed.
In linux I had trouble of upgrading using the yoeman cli because of some permission issues
So instead I did the following
In my case it was
sudo npm install -g generator-your-generator-name
This automatically reinstalled the latests version
You could try
npm install -g generator-your-generator-name
I am using Xcode 4.2.1 and I have this problem running an existing application on the iOS simulator:
svn: The path '.' appears to be part of a Subversion 1.7 or greater
working copy. Please upgrade your Subversion client to use this
working copy.
/Users/me/Library/Developer/Xcode/DerivedData/myproject-dxfzldckuqdmlrghowwkdrbgoigy/Build /Intermediates/myproject.build/Debug-iphonesimulator/MyProject.build/Script-9567AEA113C59633000AA291.sh: No Subversion revision found at /Users/me/Library/Developer/Xcode/DerivedData/myproject-dxfzldckuqdmlrghowwkdrbgoigy/Build/Intermediates/myproject.build/Debug-iphonesimulator/MyProject.build/Script-9567AEA113C59633000AA291.sh line 32.
Building revision
Command /bin/sh failed with exit code 1
I have a Subversion server 1.7.1 installed and also on the client side I upgraded to 1.7.1.
I did a svn upgrade and then I get this error in Xcode.
If I repeat the svn upgrade on the terminal I get the message Can't upgrade '...' as it is not a pre-1.7 working copy directory.
So what is wrong? How an I solve the problem?
Xcode doesn't yet support SVN 1.7. Only 1.6 is supported. In order to fix your problem, you'll need to switch to using an SVN 1.6 compatible working copy.
Since SVN 1.7 client is unable to work with 1.6 working copies at all, you'll need to remove SVN 1.7.x from your client and revert to 1.6. (Or perhaps just adjust your PATH so the SVN 1.6 tools are first.) Once 1.6 is back, delete or move aside your existing working copy and check out a fresh copy with SVN 1.6. Now Xcode should be able to work with your working copy.
Note that you can freely use SVN 1.6 client with an SVN 1.7 server. Some of the newer features won't be available, but it will work. There's no need to downgrade the server or your server-side repositories.
Keep an eye on the Xcode release notes in updates as I'm sure Apple will note when Xcode is capable of using SVN 1.7. When a 1.7 compatible release of Xcode becomes available, it should then be safe to upgrade your client to 1.7 and migrate your working copy again.
There is a post that appears to imply that you can fool XCode into using svn 1.7 client by changing your PATH and setting up a couple of soft links in strategic places. Unfortunately, the post is in Chinese. Fortunately, Google translate and the presence of UNIX commands make it possible to decrypt what the post is saying. I will try it in the next few days, and update the answer if anything useful comes out of this exercise.
EDIT: I tried the steps from the post, and it worked. Here is what I did:
Downloaded and installed svn client 1.7.2 into /opt/subversion
Added /opt/subversion/bin to my PATH in .bash_profile
Created a backup directory /Developer/usr/bin/orig.svn
Moved /Developer/usr/bin/svn* to /Developer/usr/bin/orig.svn
Ran ln -s /opt/subversion/bin/svn* /Developer/usr/bin/
After that I re-started XCode, went to Organizer, and was able to attach a working copy of a checkout created with svn 1.7.2 client. Organizer showed a green dot next to the repository, displayed a list of revisions, etc., so at this point I believe that the trick has worked.
You can download and install a binary package from http://www.wandisco.com/subversion/download#osx
The package will install to /opt/subversion while the xcode version of SVN is installed in /usr/bin. If you prepend /opt/subversion/bin to your path variable, it will be chosen instead of the xcode version.
If you don't want to mess with your path, you can just alias one version or the other. man alias for details.