Milestone

39 participants

At present there's no one championing Windows support, but this is something we're going to look at in the next version. @reybango had some interest in looking at this recently though. Perhaps he'd like to try seeing if it's possible?

@JamesMGreene I really don't have any specific ideas on how to make this work yet. I've only recently been given access. If you have some ideas, please let me know and maybe we can work together on it. Hit me up reybango at gmail.

You can use COM and Windows Shell to extract zips, but I've found out the hard way that it's not supported on Server Core, which can make it painful if you have a Server Core build server (like us! ;0)

7zip will also be needed to extract the .tar.gz files for Yeoman itself, so...

Will hack out install.ps1 now, and will basically mirror the functionality of install.sh as a first step for Windows install.

I'll raise one issue though with installing tooling dependencies like OptiPNG through Chocolatey. I generally try to avoid 'global' packages for small tooling packages like OptiPNG.

I can speak with some experience here, having spent a lot of time automating (for EC2 and for local dev bootstraps), and setting up source repos for my team so that code can be pulled and built with ease by both new devs AND the build server.

I generally draw the line, so that full language frameworks / runtimes are installed on the build server / dev box, and additional tooling should live in the repo (and should be pulled during first build by a package manager when we're talking about binaries). So for instance, I would expect Ruby or the .NET Fx SDK to be on the build server, but OptiPNG or libjpeg-turbo to be a dependency of the project.

Tool versions should generally be fixed for a given build IMHO. With global deps (especially on Windows), this can be especially painful - as installing a global version of something may break other projects depending on a different versions

Maintaining extra dependencies on a build server is generally a pain; some people may not even have shell access to their build server. It's best to have all tooling setup isolated. Fortunately, I've scripted out creation of our Jenkins server for EC2 -- but any time a global dep is introduced, I have to make sure to script out it's install as well.

Managing global paths can be a pain, relative paths are generally simpler to use IMHO

You can see these same issues were recently raised with Grunt, and the 0.4.0 dev branch allows running locally from within node_modules.

I would rather see at least PhantomJS, OptiPNG and libjpeg-turbo installed locally as NPM packages when a project is yeoman init'd / npm install'd

However, I don't know if there are technical or philosophical reasons that these tools are not already packages in NPM? Maybe the authors have no interest in building from source with node-gyp, etc?

We would really love for someone to take ownership of helping us get Windows support in place. Since #400, we've decided to no longer support automated install scripts and instead offer an audit script which lets developers know what they're missing and provides links to where to get these dependencies. For the reasons for this please see the issue but it might help simplify the amount of work needed to get this baby installed on Windows if anyone is willing to explore.

@paulirish if you have anyone else you think is worth reaching out to about Windows support it would be baller to get them involved too :)

I can do this as mentioned... but was waiting on @ferventcoder so that I don't have to maintain those packages myself - especially since he's automating package updates on accepted pull reqs. But if necessary, I can host / maintain those bits on my GitHub account and push them up to Chocolatey by hand.

Writing a bunch of dep checks in Powershell is not too hard.. but ShellJS has cross-platform tools like which that would be convenient for doing these types of checks and reusing the code. (Note Powershell / Windows doesn't have a which but you can fake it without too much trouble.) My main point being that the checks could be normalized / shared across all OSes instead of allowing them to diverge from one another.

If someone puts together a yeoman package (which I think is happening here?) - then set all of the dependencies to the above in the nuspec.
And in the package perhaps install compass. Or someone could create a compass package to call out to ruby to install it. Then you can just add it as another dependency to the nuspec. This would be cleaner IMHO.

@murilobr Did you close the command line after you installed yeoman and then open another before running yeoman init and build? The other libraries are put on the path, but don't get recognized until after the next time you open a cmd prompt.

Fwiw, my vote would be for us to have a primary Windows installation doc that we can recommend for the average user with links to install instructions in the docs for more specific variations. I'd like to avoid the situation where someone wants to install and they go "Wait..there's 10 different ways to do this. Which one is the simplest?".

@addyosmani I agree. As for the install process, #chocolatey is the pimpliest I've found so far for Windows env. It's so simple it's stupid :) I'd also mention the original steps Praveen described on the blog for reference/documentation purpose.

@addyosmani I agree there should be one standard way. If you have all of the dependencies already installed then cloning the repo and cd into \cli via the command prompt and running npm install -g is extremely quick and easy. It's 2 simple steps, clone and run.

However, if you don't have all the dependencies then the Chocolatey install seems like the way to go. Also 2 simple steps, install Chocolatey and yeoman. It's a little longer install process, but that's expected with the need for it to install ruby, node, compass, etc... This would be my vote for the simplest.

@paulirish, yup - those instructions are accurate... Just so you understand a little about how it works

PowerShell is built on .NET and ships with Windows (.NET 2 by default up to Windows 8, .NET4 for Windows 8 and Server 2012)

Chocolatey is a Powershell based package manager for Windows, that co-opts the Nuget package manager format used to ship around .NET assemblies and tools (its basically a zip with an XML manifest that allows for dependency hierarchies). Remote scripts are not allowed to execute by default in a Windows Powershell session, but the 1-line Chocolatey installer launches Powershell with that disabled for the install session.

The Yeoman pkg simply has the list of various dependencies needed - I had it install Yeoman itself with npm install -g Yeoman rather than a Git clone.

Is the system as sophisticated as something like apt-get, or yum.. no.. but it's the best thing Windows has by a long shot -- give @ferventcoder a ton of credit for taking the initiative to build Chocolatey in the first place. It makes developers lives tons easier.

@paulirish - The original workflow is not changed. Chocolatey is not different from the original version. User still need all the software/tools mentioned in the original method. Chocolatey fetches the tools one by one and prompt the user to install it.

After missing the step to install yeoman-generators package from the npm on windows install, I tried the two-step Chocolatey cinst yeoman method (step 1: Install Chocolatey, step 2: cinst yeoman) - my only comments on it are that Chocolately doesn't seem to have an immediate way to specify install dirs for dependencies (I had Ruby 1.9.3 on my machine already, the yeoman Chocolatey pkg installed 1.8.7; same with node, git, PhantomJS, etc.)

I'll also add to the cheers on Chocolatey, it's fantastic. General Windows users will probably prefer a msi (WiX/NSIS), but I might suggest that such an installer install Chocolatey ;)

Yeah, I think that Chocolatey needs to add some sort of built-in guard functionality that can perform where checks on some given locations. This is non-trivial feature though, since checking PATH for binaries isn't always a safe way to detect something is installed -- sometimes it requires registry sniffing, etc. I'll add it as an issue to the tracker to see if there's a good way this can be solved.

@ghchinoy@Iristyle We are also implementing an Ignore Dependencies feature in the next release. While I understand this is not the same as the ability to see if packages are installed, it can help in areas where you have all of the prerequisites already installed.

Has anyone run into any issues with image compression? I had a problem where the img task couldn't find optipng or jpegtran even if they were in my PATH.

Looking closer on the img task it looks like it searches for optipng and jpegtran in the folder vendor/, inside the yeoman/ folder specifically on Windows. I tested and it worked but it feels kinda fishy to manually move them there. Would be better if it used PATH on Windows too or if you were to include the vendor/ folder by default.

@kevva Sorry, as stated in the readme, Yeoman does not officially support Windows. We used to embed the Windows binaries, but don't anymore, the code hasn't been updated to reflect that, but will be after the 1.0 release.

after some heavy frickinaround with the PATH vars (i had to clean up alot; whoever invented the UI for windows shall rot in hell!) i could finally get yeoman via console (systemwide \o/ ).but:
yeoman keeps asking me if i want to send usage statistics. every fucking time? :-)

I am trying to install Yeoman on Windows via various option available, and all seem to work fine, but whenever I am executing yeoman init, it doesn't seem to work. It is always opening up Dreamweaver in the frontend, or when I delete the association of JS file type of Dreamweaver, I get the error "Windows cannot open this file: yeoman.js. The path defined in the system is as follows:

Sounds eerily similar to the Grunt.js situation. With Grunt 0.4, Grunt.js has been renamed to Gruntfile.js, so that there was no conflict b/w launching Grunt the tool and having something in PATH try to edit / run Grunt.js.

@iristyle , yeah I am trying to run the same directory where yeoman has been installed, or from any other directory, and it seems the the code is getting executed. Now strangely the error has changed to this:

c:\directory where yeoman has been installed\yeomaninsight.py, line 185, Print 'Invalid number of arguments.'
SyntaxError: invalid syntax

I have installed Phyton version 3.3.0 or windows since the previous version i.e 2.7.3 was throwing an error during installation.

I have been trying to install Yeoman using Chocolatey. No errors were reported during installation and the PATH variable shows all of the directories listed in ferventcoder's post. I can initialize a new project and run a server which correctly watches for changes (which is great!). However when I try to build it freezes on copy and reports:

<FATAL> </FATAL>

Not the most helpful error message I know! Just wondering if anyone else has had this issue? I am on Windows 7 64 bit.

@simonwoodhead - I just got the same issue on Window 7 64-bit. I believe my problem was caused by an incorrect (custom) path to my angular.js file I referenced in index.html. I noticed the issue after an exception was thrown after executing "yeoman server" Traced the error to the bad path. Apparently the "copy" step in the build process broke when looking for that (incorrect) file path?

But then I ran build again, and it failed. Ran "yeoman server" one more time, stopped it and rebuilt. Worked as expected and copied compiled files into "dist" directory.

I'm using Yeoman v0.9.6 on Windows 7 (x64) successfully... (the below is
very loosely stated, but should get you where you need to go ;-)

The point of failure you indicate, assuming you do not get the green "OK"
after NETWORK: *, -- and where I would point you -- is when confess.js is
being run via phantomjs -- temporarily setup/startup static web server
(:3501) -- to generate the cache manifest...and writing to
manifest.appcache...

And it sounds like that command is never completing successfully, "hanging"
your system.

That NETWORK: * is simply the last lines echoed to the console of the
manifest NETWORK block. The * is a catch-all (details below from the
confess.js README.md, see the confess project:http://github.com/jamesgpearce/confess ).

Things I might check/do:

Is phantomjs working correctly on your system (I'm using v1.7.0)
independently of yeoman?

Prior to where the build gets to the "manifest" task in the
Gruntfile...do all the steps up to the point where it "freezes" execute
successfully without any indicated errors or warnings?

Examine confess.js source code

from the README.md for confess

appcache.networkFilter - a regex to indicate which files not to include
in the CACHE block of the manifest, and which a browser will request from
the network. If set to null, none will. Note that matching files will not be
explicitly listed in the NETWORK block of the manifest, since there is

I'm getting a strange problem. I've installed Yeoman on Windows 7 x64 by cloning the repo and run npm install -g.
The installation run without a error and if I type "yeoman" in console it shows me the options.

However, when I tipe "yeoman init" the console report:
"init is not yet integrated".

Everything went well when I executed cinst yeoman in the command line. But there were a few warn messages. yeoman build and yeoman server seems to be working fine but the sass files doesn't seem to be compiling on css on the dist directory. All I see is scss files which results to main.css not found error when I access the page in the browser.

Add python to your system path. Add "C:\Python27;" to the PATH env variable. See these instructions.

but Chocolatey can install Python 2.7.3 and add it to the path, too! Maybe update the Yeoman Chocolatey package to include this? (Also, thanks for introducing everyone/myself to Chocolatey; what a useful thing it is.)

Sublime text is coded in python and since yeomen is interacting with it, I believe it's a reason why you need python if it's not installed. Compass is also needed for SASS compilation, which yeomen does for you and gives you live refresh abilities with fast compilation.

imo, the SASS and Compass compilers could be ported, lowering the
dependencies.
python is more easily installable and configurable in windows. but if they
can be reduced as a dependency won't be good for all OSes?
sorry if i'm being inconvenient and changing the focus of the discussion.

Hmm, i'm using yeoman under windows sience few months now, and i don't understand the problem ;-P The only one issue which was pretty small to me, that was phantom support, everything else, works perfectly - the only difference between windows and linux with installing yeoman is a way of installing some dependencies (like ruby) and heh... installing exe file isn't that difficult - really ;-D

I'd like to use Yeoman 1.0 which is seems to not support Windows. I'm guessing that you're using Yeoman 0.9.6 which is working bug is an old produce. Yeoman is something completetly else. See http://yeoman.io/.

I see that this PR need to merged, not sure what it wasn't.yeoman/yo#3

Could some folks that are currently using the 1.0 beta on Windows let me know how well that's going for you? Did our default install instructions work fine or have you been using a specific other set of installation instructions to get things running? Basically...I would like to know where we need to spend time improving Windows support :)

Yeoman npm install works fine on windows. Initially had some issues with imagemin and phantomjs. But default installation works fine now. I'm using 'yo webapps' for a while, but not tried angular. I'm on node v0.8.21.

@sindresorhus I would like to tweet out asking Windows users to try "npm install -g grunt-cli bower yo", "npm uninstall -g yeoman" and "yo webapp" just to verify this works for most people. Sound like a good idea?.

@addyosmani - I tried in another win 7 machine with node vv0.8.16 and got an error - npm ERR! cb() never called! [http://pastebin.com/29MnktRe line no:103]. In this machine compass is not installed. I got similar error like first link when I tried grunt.

@addyosmani I have no issues with beta3 when following the Getting Started instructions to install and run yo webapp. I'm on Win 8 Pro 64-bit, with nodejs 0.10.3, git 1.8.1.msysgit.1, and ruby 1.9.3p392.

In order to track down issues with Windows users, I think it's important to make sure that you get the exact version of Windows, node, git, and ruby they have installed, and -- very important -- the terminal shell they're using. A lot of people don't seem to realize that trying to run commands from, say, Cygwin is not necessarily going to get expected results, since Cygwin installs and runs its own versions of things like Ruby. Frankly, I won't let Cygwin near my system anymore. In my case, I run all CLI stuff through Git Bash (msysgit), not just for Yeoman, but for everything in my development workflow. Git is a boon for us hapless Windows guys, because it helps bridge the gap a little between the cold, hard world of the NT kernel universe and you fancypants POSIX people, while being sensibly flexible.

yo webapp is pain-free, but I ran into problems with yo angular. I've got a list of error reports for that one -- should I post that here, or keep it outside this thread and get it to you separately?

I just made a fresh installation about an hour ago and works fine from my
end using the default installation steps. Tested "yo webapp" and
installation proceeded properly except it throws the following line at the
end of the scaffolding process:

I also tried the installation steps for Angular and everything installed
properly. I just noticed though that when running "grunt test", Karma
throws "Fatal error: spawn ENOENT". I was able to workaround it by
changing browsers = ['Chrome'] to browsers = ['ChromeCanary'] on
karma.conf.js. Not sure why it does that (Chrome is my default browser).

@addyosmanihttps://github.com/addyosmani I have no issues with beta3
when following the Getting Started instructions to install and run yo
webapp. I'm on Win 8 Pro 64-bit, with nodejs 0.10.3, git 1.8.1.msysgit.1,
and ruby 1.9.3p392.

In order to track down issues with Windows users, I think it's important
to make sure that you get the exact version of Windows, node, git, and ruby
they have installed, and -- very important -- the terminal shell they're
using. A lot of people don't seem to realize that trying to run commands
from, say, Cygwin is not necessarily going to get expected results, since
Cygwin installs and runs its own versions of things like Ruby. Frankly, I
won't let Cygwin near my system anymore. In my case, I run all CLI stuff
through Git Bash (msysgit), not just for Yeoman, but for everything in my
development workflow. Git is a boon for us hapless Windows guys, because it
helps bridge the gap a little between the cold, hard world of the NT kernel
universe and you fancypants POSIX people, while being sensibly flexible.

yo webapp is pain-free, but I ran into problems with yo angular. I've got
a list of error reports for that one -- should I post that here, or keep it
outside this thread and get it to you separately?

—
Reply to this email directly or view it on GitHubhttps://github.com/yeoman/yeoman/issues/216#issuecomment-16064685
.

As per our announcement back in April, we now officially support Windows as Sindre mentioned earlier. If you run into any new issues regarding Windows support please feel free to ping us on the #yeoman channel or open up a new issue on the relevant generator repo.