Yeoman custom generator - yeoman

I would like to make a custom generator with the latest version of yeoman, but I'm having some difficulty. I've been digging around various sources of documentation and examples (like the webapp and angular generators), but I still have a few questions.
What is the workflow for testing a generator? If I have one project that is the generator itself, do I keep making new directories to run yo my-generator?
Has the generator framework changed at all with the beta of yo 1.0? Have there been breaking changes?
How does a generator register itself with the global yo binary?
Thanks.

This question is a few months old, but I think it's useful for anyone who finds it now to know that much more has been explained in http://yeoman.io/generators.html
Question 1:
Testing your generators locally can be easily done. For instance if your generator is called "generator-mtv-raps"
$ cd ~/dev/generator-mtv-raps/
$ npm link
Now if you do:
$ cd ~/dev/mytest/
$ yo mtv-raps
It will build.
Additionally, unit testing your generator with mocha is pretty straight forward. There is a set of test helpers built in. The basics of what you need to be testing against can be found in generator-webapp's tests https://github.com/yeoman/generator-webapp/blob/master/test/test.js
Test that the generator can be required without breaking.
Mock your prompts with helpers.mockPrompt
Test that all the files you want created are created via helpers.assertFiles
Test that the prompt values you mocked are inserted into the created files.
Number 4 is kind of tricky, the array of expected files can be passed a regular expression to check against. If you want to know more about the test helpers, the source is the best place. https://github.com/yeoman/generator/blob/master/lib/test/helpers.js
Question 2: already answered by btford
Question 3:
Generators are bound to yo by installing them globally (or linking them as above) and using a naming convention. All generators start with "generator" then "-" then "name".
hence generator-mtv-raps accessed via $ yo mtv-raps

What is the workflow for testing a generator?
I'll be working on this in the next couple of days for generator-angular. You can track my progress on Github. Unfortunately, there aren't too many examples yet because of the transition from one yeoman command to using yo alongside bower and yo. I imagine there will be some level of unit testing on the Generator.prototype.method, as well as E2E testing that involves writing bash scripts to run yo, npm, bower, and grunt.
Has the generator framework changed at all with the beta of yo 1.0? Have there been breaking changes?
In my experience porting over generator-angular, I haven't seen too many changes. There is a new, optional simplified API, which may be useful.
How does a generator register itself with the global yo binary?
The answer right now is that it doesn't. You install/use generators in a project directory. I somehow had it working due to an errant symlink, but that's not the recommended way of doing it.

Related

Using two yeoman generators in one project?

Is it possible to use 2 yeoman generators in a single project? I want to use generator-angular and generator-node-express-mongo in a single project. Is this a good idea or its much easier to go with 2 separate projects?
The simple answer is YES. But some cases need to take in account like the use of two different JS-MV* frameworks like Angularjs and ember or build systems like gulp and grunt
Check this answer too:
Using two yeoman generators?

IntelliJ with Ruby on Rails plugin gives warnings about "not able to find route path" when coding tests using built in mini-test framework

I am new to web dev and Ruby on Rails. I chose IntelliJ(13.1.5) with ruby plugins since I also have worked with Java apps for many years for saving a lot of typing. I am trying out rails built-in mini-test framework these days and I have trouble using auto-completion feature for route paths and urls in test classes. There are many warnings about "Cannot find xxx_path' for my sample code below though the tests do run fine.
get login_path
I understand it could be hard for IDE to work with a framework in dynamic language with built in magic. However, I experimented with RSpec test framework for rails and did not have such problem finding the route definitions in IDE. I like mini-test's simplicity more, but if IDE could not allow me to work efficiently, I have to think about RSpec again. Not sure if I miss something here or IDE's miss. Is there anyone else have the same problem with intelliJ mini-test classes for route definition? Do you get it work properly in Intellij or RubyMine? Thanks.
Posted it in JetBrains community and was told that this is supposed to be supported. Filed an issue https://youtrack.jetbrains.com/issue/RUBY-15920
Like you said, it is hard for Intellij to do the magic for dynamic language, it can't be sure about which one you are referencing. I noticed similar issue while writing ruby with IntelliJ IDEA. I'd suggest switching to RubyMine, which is basically a light-weight IntelliJ IDEA but has everything ruby needs. This solved some of my issues, meaning it can find the correct reference when you find declaration, although auto-completion still doesn't work well with instances outside of the current class.

Dealing with shared helpers in Common Test suites?

I've got an Erlang project comprising a bunch of different applications. I'm using Common Test to do some of the testing.
apps/foo/suites/foo_SUITE.erl
apps/bar/suites/bar_SUITE.erl
I'm starting to see duplication of utility code in those suites.
Where should I put my utility code so that it can be shared between the two suites?
I've considered adding another application:
apps/test_stuff
...but I can't make the CT suites depend on this without making the application under test depend on this (or can I?). I don't want to do that, because test_stuff is only needed when testing.
I have a similar problem with my eunit tests, both between applications (apps/foo/test vs. apps/bar/test), and where I'm using similar functionality between the eunit and CT tests in the same application (apps/bar/suites vs apps/bar/test). Can I use the same solution for this case as well? Or do I need to ask another question about that?
Do you think ct:require/1,2 could help you so that foo and bar SUITE would require test_stuff before it gets executed? For more information http://www.erlang.org/doc/man/ct.html#require-1
It depends on how you are packaging your final releases. For example, I use rebar for relase management. I have Cowboy fetched along with other dependencies for testing purposes, but in my reltool.config, I omit it, so it doesn't get packaged with the final product. I use rebar to run Common Test, and it's able to add Cowboy to the path without having it bundled as a lib with everything else or added as a dependency to the app I'm testing.
However, if you have another process which infers your release configuration from your dependencies, you'll have to find a way to exclude your test code when you generate a release.

Zend Framework 2 CLI

I realise that the stable release of Zend Framework 2 hasn't been been out for long, but having been through the skeleton tutorial it seems that there's a lot of work that needs to be done in order to get a new module working.
I'm just wondering if there are any tools available such as a CLI that make the creation of new modules/models etc easier.
Many thanks.
You can use the new ZFTool module to create new module and application structures for you via the cli
https://github.com/zendframework/ZFTool
Create a new module
zf.php create module <name> [<path>]
Create a new project
zf.php create project <path>
There probably will be tools to automate the creation of modules later on but probably not yet. Recall that the tools for autocreating projects for ZF1 didn't come out for quite a few releases. I'm not sure exactly which release but I think it wasn't until after 1.8 that the tools became available.
Until then, should DEFINITELY think about creating a 'skeleton' module and maybe putting it up on github or even create a pull request on the skeleton application to have your skeleton module, with the extra setup already done, added to the skeleton application or have it replace Zend's altogether.
A skeleton module already exists on github. It's been there for months and updated regularly as zf2 developed.
https://github.com/zendframework/ZendSkeletonModule

Ruby on Rails plugin development process

I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .

Resources