Command Line Helper for YUI
Home Page: http://yui.github.com/yogi/
License: Other
yogi (yōgē) is a commandline interface to aid in the development of YUI and Gallery modules.
npm -g install yogi
yogi help
Documentation can be found here
selleck --server --project conf/docs/ ./docs/
yogi supports dynamic and customizable sub commands so that you can add features without forking
or modifying yogi internally.
Here is an example to use as a reference.
When updating an existing project, if the original description is long and contains line-breaks, those
line breaks will be included into the "description" property of component-json:
{
"name" : "gallery-button-plugin",
"displayName": "Gallery: button-plugin",
"description": "A plugin for Y.Node that converts regular buttons marked with a given className into toggle buttons.
It will also make groups of toggle buttons within a container mutually exclusive of one another.",
"author" : [ "satyam" ],
"tags": [ "gallery" ],
"examples": []
}
yogi serve then fails when trying to read this invalid JSON
Yogi currently assumes that the git origin for a gallery module will always be relative to the configured GitHub user. For example, my GitHub username is "rgrove", so yogi assumes all my projects will live in repos under github.com/rgrove.
Unfortunately, this means yogi can't support GitHub organizations like github.com/smugmug, so organizations can't own gallery modules.
While updating one of my old gallery modules, I added {{>getting-started}} to index.mustache. I was surprised to see it render a link to http://yui.yahooapis.com/3.5.1/build/yui/yui-min.js instead of the most recent version.
3.5.1 is the version associated with the gallery module on yuilibrary.com so I assume that is where this value comes from.
Could Yogi provide a way to get/set this value?
When using yogi serve --instanbul I find I cannot run the examples because the wrapper it puts around the generated page loads the YUI seed file from ../../build/ which is correct for YUI core modules but not for gallery ones.
There seems to be a yuiSeedUrlplaceholder to change this but setting this in a project.json file or component.json file in the module being served by yogi made no difference.
I wouldn't like to have this path fixed to any version, as it normally happens with yui seed files, it would be good if the gallery developer would be able to run the examples and tests against whatever the latest version of YUI without having to edit anything. Perhaps, an option to run the examples with pre-releases, but that should be an option.
On the other hand, it would be great to have an equivalent feature for our own modules, that is, load the gallery modules from the ../../build directory since that would allow me to do changes and test them at the same time. Normally it loads them from the CDN if I don't explicitly use a YUI({ ... cfg ...}).use() but that would not work when up in the CDN nor would it look good in the docs because it would lend the reader to think it is something the developer must write.
Perhaps the best solution is to have the template load a file with the YUI_config variable with the module definitions (generated by yogi loader? perhaps it does this, but I couldn't make it work, but that is another issue) so that I can set up such a file in my local environment while, once in the CDN, that would be ignored.
This is absolutely low priority, but it would be nice.
If you run the tests with coverage and you click on the back button of the browser, you don't go to the root of the yogi server but to the test, which sends you back to the coverage report.
Also, I'm looking at the detailed coverage report of one file, the one that shows the source and which branches were taken, which statements executed and so on. When I add a test, it is kind of boring to refresh that result.
It would also be great if the report went straight to the first warning and provided means to jump from one warning to the next.
Updated src to latest dev-master from upstream public repo.
Updated yogi via npm install yogi.
Node is version v.0.8.16
I cd to yui3/src
run "yogi serve"
I get:
yogi [info] using [email protected] on [email protected]
yogi [info] adding tests route
yogi [info] this is yui, using global path for all docs
yogi [info] launching yuidoc --server 5001 --config /Users/awooldri/MyHome/Projects/yui/yuiwork/yui3/src/common/api/yuidoc.json
yogi [info] this is yui, using global path for all docs
yogi [info] launching selleck --server 5002 --project /Users/awooldri/MyHome/Projects/yui/yuiwork/yui3/src/common/docs/
yogi [info] launching xdr server on port 5003
yogi [info] listening on: http://127.0.0.1:5000
yogi [ERROR] selleck: execvp(): No such file or directory
I visit : http://127.0.0.1:5000/
and under Docs and Stuff I click on
"Examples and Landing page"
node server crashes with this error:
stream.js:81
throw er; // Unhandled stream error in pipe.
^
Error: connect ECONNREFUSED
at errnoException (net.js:770:11)
at Object.afterConnect as oncomplete
It would be great if I could have tests auto run on build so I could do something like
yogi build --watch --test
See the input/output below.
build.json:
{
"node-ie": {
"condition": {
"trigger": "node",
"ua": "ie"
},
"requires": [
]
}
}Generated code:
Y.mix(YUI.Env[Y.version].modules, {
"node-ie": {
"condition": {
"name": "node-ie",
"trigger": "node-ie",
"ua": "ie"
},
"requires": [
]
}
});It should outputs:
Y.mix(YUI.Env[Y.version].modules, {
"node-ie": {
"condition": {
"trigger": "node",
"ua": "ie"
},
"requires": [
]
}
});So far my workflow with Yogi has fallen into primarily two stages, first is the command line stage where I frequently build, lint, and occasionally test code. The second stage is the browser stage with yogi serve where I write api docs, user guide, and occasionally test code. Sometimes during the second stage I discover something and make a code change and want to re lint and re build. I have to go back to the command line and kill the server.
It would be super awesome if the yogi serve page had a link to run and display lint output and also have a build button. Then all of the most common tasks during development could be managed in the browser instead of switching back and forth between the browser and the command line.
Of course there could be a GUI for all of Yogi's functionality, but I think just Lint and Build would be sufficient to streamline the majority of the workflow.
Have you tried to run JSLint on the tests? There are lot of errors that come out of copying and pasting the same line over and over. I haven't seen any really serious errors, but there were so many screen fulls of errors that I just sampled them, but then, what good is your testing if your calliper is failed. Lots of undefined variables which, if the "use strict" statement that JSLint complains about was there, they would all fail.
From the selleck guide it says the assets directory is for static resources. In my case, I wanted to use an icon, like this:
<style>
.www-go {
width: 16px;
height: 16px;
background-image: url(assets/world_go.png);
}
</style>
The url is correct relative to the page of the .mustache page containing that style declaration, the image is there and it has the right permissions. However, yogi translates those addresses and I don't know how to tell it to handle this one. The network tab shows it in red with a 404 message.
I tried several combinations to try to beat the routing, but couldn't find the way and, anyway, I'm not sure any tricks I could do locally would work once up in the CDN.
Thanks for the help
I'm getting the following connection refused error when using yogi serve and trying to navigate to either the user guide or API docs for a module (the tests work fine):
Glare:app eferraiuolo$ yogi serve
yogi [info] using [email protected] on [email protected]
yogi [warn] THIS IS EXPERIMENTAL, USE AT YOUR OWN RISK!!
yogi [info] using module: app
yogi [info] this is yui, using global path for all docs
yogi [info] this is yui, using global path for all docs
yogi [info] launching yuidoc --server 5001 --config /Users/eferraiuolo/Code/yui/yui3/src/common/api/yuidoc.json .
yogi [info] this is yui, using global path for all docs
yogi [info] launching selleck --server 5002 --project /Users/eferraiuolo/Code/yui/yui3/src/common/docs/
yogi [info] adding tests route
yogi [info] listening on: http://127.0.0.1:5000
stream.js:81
throw er; // Unhandled stream error in pipe.
^
Error: connect ECONNREFUSED
at errnoException (net.js:768:11)
at Object.afterConnect [as oncomplete] (net.js:759:19)
Glare:app eferraiuolo$
I did a "yogi update" in a new directory for one of my gallery components, and in the meta/ path the
.json file didn't convert any of the "requires" ... so my gallery is dead for this week.
For example: https://github.com/stlsmiths/new-gallery/tree/master/src/gallery-datatable-paginator
Probably happened because I don't know what the hell I am doing yet with yogi.
But as a test, I copied Dav's bitly project from his link: https://github.com/davglass/gallery/tree/master/src/bitly
Then I deleted the build.json, css, docs, meta and tests folders ... leaving just the assets, js and build.properties and build.xml files.
I then did "yogi update", it proceeded to do the conversion. But when I checked the meta/bitly.json file it contained just "{ "bitly":{} }" and didn't copy the "base,get" requires.
yogi version 0.0.46.
I'll go ahead and manually edit the meta .json file, but wanted to pass this on FWIW.
yogi create gallery-module creates gallery-gallery-module in the file structure, but reports it is creating gallery-module in the y/n confirms
I created a new module https://github.com/stlsmiths/new-gallery/tree/master/src/gallery-datatable-contextmenu.
I've gotten a clean build (but tests fail, because a dependency is not on the CDN or over the wire anywhere yet ...), and when I do a yogi cdn request --force I get a NodeJS stack dump.
https://gist.github.com/4536300
Any ideas?
It would be handy to allow yogi init to just create the directory structure for putting together simple tests or examples which will probably never live long (and should they ever do, they can later be moved under a git repository and their name registered).
For several applications combo loading isn't ideal. For such cases it would be great if yogi could generate a rollup of yui and the app files. At the moment its a pretty one off task for each project to setup the loader to generate a dep set and then minify/aggregate the result.
If I cd into the Core repository and launch yogi serve, it works, but if I do the same on my group of gallery modules, all in the same repository, it asks for the module. It doesn't do that with the core. What should I have in my gallery repository to make that work?
I can see the API docs for the whole core (and I would like to see that for a couple of my modules, since one of them inherits from another one) and full examples and landing pages.
I guess I need some sort of index. There are a couple of files there that seem to provide that, but I'm not sure what they really are.
Thanks
Break out the 'init' functionality into a separate npm tool, so that if you only care about generating project skeletons, you can do that and ignore the rest.
Make it very easy to augment this tool with new templates. Ideally as simple as, make an npm package that provides a project directory structure + some files with handlebars markup. If you add that npm package, our fancy init tool discovers it and registers it as yet another option.
Grunt kind of has this ability to add more project skeletons, but it's clunky and more tightly coupled than I'd like.
I've just watched Apipkin's talk and learned of a couple of predefined partials, properties or whatever. From you I learned about the {{componentAssets}}. Is there a list somewhere with all of them?
BTW, I tried the {{>getting-started}} and it produces this:
<script>
// Create a new YUI instance and populate it with the required modules.
YUI().use(, function (Y) {
// Gallery: gallery-flyweight-tree is available and ready for use. Add implementation
// code here.
});
</script>
with the module name missing in the YUI().use(). Am I missing something? The name property is there in all the .json files where it can possibly be.
CDN requests fail if there are any uncommitted changes in the repository. This is a good check, but it's annoying when a repository contains multiple modules and unfinished development work for one module blocks a CDN request for another module.
Is there a way to ignore uncommitted changes and just pick a specific commit for the CDN request?
satyam@ubuntu:~/git$ yogi login
yogi [info] using [email protected] on [email protected]
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
TypeError: Object #<Object> has no method 'resume'
at new Interface (readline.js:58:9)
at Object.createInterface (readline.js:38:10)
at Object.prompt (/usr/lib/node_modules/yogi/lib/util.js:184:27)
at Object.process (/usr/lib/node_modules/yogi/lib/cmds/login.js:34:22)
at Object.init (/usr/lib/node_modules/yogi/lib/cmds/login.js:17:14)
at Object.<anonymous> (/usr/lib/node_modules/yogi/bin/yogi.js:31:9)
at Module._compile (module.js:441:26)
at Object..js (module.js:459:10)
at Module.load (module.js:348:31)
at Function._load (module.js:308:12)
Did: sudo npm -g update, just in case, but it didn't change anything. Also tried sudo yogi login and it also fails.
The init functionality is awesome, but -- it seems odd to have to log in to the Gallery or to GitHub just to generate a project skeleton. I might not care about the Gallery, this might be an entirely internal project where I might be using bzr or something crazy, etc.
I haven't checked out other yogi commands extensively, but perhaps do a sweep through all the commands in order to figure out which ones really do need to be coupled with GitHub and the Gallery.
yogi loaded crashed when run without the folder already created, once the yui' andloaderfolders were created and a furtherjs` folder underneath each, it all run fine.
Unfortunately, I don't remember which version I upgraded from. The issue was that I had to manually delete three directories before the install would complete successfully. Here are the error logs that told me about the directories:
npm ERR! EEXIST, mkdir '/usr/local/lib/node_modules/yogi/node_modules/combohandler/node_modules/express/node_modules/mkdirp/test'
File exists: /usr/local/lib/node_modules/yogi/node_modules/combohandler/node_modules/express/node_modules/mkdirp/test
Move it away, and try again.
npm ERR! System Darwin 11.4.2
npm ERR! command "node" "/usr/local/bin/npm" "install" "-g" "yogi"
npm ERR! cwd /Users/jolindal
npm ERR! node -v v0.8.8
npm ERR! npm -v 1.1.59
npm ERR! path /usr/local/lib/node_modules/yogi/node_modules/combohandler/node_modules/express/node_modules/mkdirp/test
npm ERR! fstream_path /usr/local/lib/node_modules/yogi/node_modules/combohandler/node_modules/express/node_modules/mkdirp/test/umask_sync.js
npm ERR! fstream_type File
npm ERR! fstream_class FileWriter
npm ERR! code EEXIST
npm ERR! errno 47
npm ERR! fstream_stack /usr/local/lib/node_modules/npm/node_modules/fstream/lib/writer.js:171:23
npm ERR! fstream_stack /usr/local/lib/node_modules/npm/node_modules/mkdirp/index.js:37:53
npm ERR! fstream_stack Object.oncomplete (fs.js:297:15)
npm ERR! Error: ENOENT, lstat '/usr/local/lib/node_modules/yogi/node_modules/yuidocjs/tests/out/files/input_charts_CartesianSeries.js.html'
npm ERR! If you need help, you may report this log at:
npm ERR! http://github.com/isaacs/npm/issues
npm ERR! or email it to:
npm ERR! [email protected]
npm ERR! EEXIST, mkdir '/usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/uglify-js/test/unit/compress/expected'
File exists: /usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/uglify-js/test/unit/compress/expected
Move it away, and try again.
npm ERR! System Darwin 11.4.2
npm ERR! command "node" "/usr/local/bin/npm" "install" "-g" "yogi"
npm ERR! cwd /Users/jolindal
npm ERR! node -v v0.8.8
npm ERR! npm -v 1.1.59
npm ERR! path /usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/uglify-js/test/unit/compress/expected
npm ERR! fstream_path /usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/uglify-js/test/unit/compress/expected/var.js
npm ERR! fstream_type File
npm ERR! fstream_class FileWriter
npm ERR! code EEXIST
npm ERR! errno 47
npm ERR! fstream_stack /usr/local/lib/node_modules/npm/node_modules/fstream/lib/writer.js:171:23
npm ERR! fstream_stack /usr/local/lib/node_modules/npm/node_modules/mkdirp/index.js:37:53
npm ERR! fstream_stack Object.oncomplete (fs.js:297:15)
npm ERR! error rolling back Error: ENOTEMPTY, rmdir '/usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules'
npm ERR! error rolling back [email protected] { [Error: ENOTEMPTY, rmdir '/usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules']
npm ERR! error rolling back errno: 53,
npm ERR! error rolling back code: 'ENOTEMPTY',
npm ERR! error rolling back path: '/usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules' }
npm ERR! [email protected] postinstall: node scripts/postinstall.js
npm ERR! sh "-c" "node scripts/postinstall.js" failed with 1
npm ERR!
npm ERR! Failed at the [email protected] postinstall script.
npm ERR! This is most likely a problem with the yeti package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node scripts/postinstall.js
npm ERR! You can get their info via:
npm ERR! npm owner ls yeti
npm ERR! There is likely additional logging output above.
npm ERR! error rolling back Error: ENOTEMPTY, rmdir '/usr/local/lib/node_modules/yogi/node_modules/yuidocjs'
npm ERR! error rolling back [email protected] { [Error: ENOTEMPTY, rmdir '/usr/local/lib/node_modules/yogi/node_modules/yuidocjs']
npm ERR! error rolling back errno: 53,
npm ERR! error rolling back code: 'ENOTEMPTY',
npm ERR! error rolling back path: '/usr/local/lib/node_modules/yogi/node_modules/yuidocjs' }
npm ERR! [email protected] postinstall: node scripts/postinstall.js
npm ERR! sh "-c" "node scripts/postinstall.js" failed with 1
npm ERR!
npm ERR! Failed at the [email protected] postinstall script.
npm ERR! This is most likely a problem with the yeti package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node scripts/postinstall.js
npm ERR! You can get their info via:
npm ERR! npm owner ls yeti
npm ERR! There is likely additional logging output above.
npm ERR! System Darwin 11.4.2
npm ERR! command "node" "/usr/local/bin/npm" "install" "-g" "yogi"
npm ERR! cwd /Users/jolindal
npm ERR! node -v v0.8.8
npm ERR! npm -v 1.1.59
npm ERR! code ELIFECYCLE
npm ERR! EEXIST, mkdir '/usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/glob/node_modules/inherits'
File exists: /usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/glob/node_modules/inherits
Move it away, and try again.
npm ERR! System Darwin 11.4.2
npm ERR! command "node" "/usr/local/bin/npm" "install" "-g" "yogi"
npm ERR! cwd /Users/jolindal
npm ERR! node -v v0.8.8
npm ERR! npm -v 1.1.59
npm ERR! path /usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/glob/node_modules/inherits
npm ERR! fstream_path /usr/local/lib/node_modules/yogi/node_modules/shifter/node_modules/gear-lib/node_modules/glob/node_modules/inherits/README.md
npm ERR! fstream_type File
npm ERR! fstream_class FileWriter
npm ERR! code EEXIST
npm ERR! errno 47
npm ERR! fstream_stack /usr/local/lib/node_modules/npm/node_modules/fstream/lib/writer.js:171:23
npm ERR! fstream_stack /usr/local/lib/node_modules/npm/node_modules/mkdirp/index.js:37:53
npm ERR! fstream_stack Object.oncomplete (fs.js:297:15)
npm ERR! Error: ENOENT, lstat '/usr/local/lib/node_modules/yogi/node_modules/combohandler/node_modules/express/node_modules/connect/node_modules/formidable/node-gently/Readme.md'
npm ERR! If you need help, you may report this log at:
npm ERR! http://github.com/isaacs/npm/issues
npm ERR! or email it to:
npm ERR! [email protected]
Yogi creates a file /assets/gallery-/ gallery--base.css but Shifter looks for /assets/gallery-/gallery--core.css
CORE instead of BASE
On version 0.0.49 the last line saying which port it is listening at is missing. It does listen at that port, it simply doesn't say so.
I noticed when I run unit tests from yogi serve, Firebug throws errors because there is no character set defined in either a response header or a meta tag. I just ignored that error until I wrote some tests and they were failing and I couldn't figure out why. The solution was to add <meta charset="utf-8" /> in the <head> of index.html.
Is utf-8 a reasonable default character set? If so, could it be added to Yogi's template?
Yogi is running with filter=coverage with --istanbul, but there is no report when using a module
Echoecho makes it easy to test Y.IO for standard XHRs, but in order to support testing cross domain requests, an echoecho server must be setup on a different origin.
Can we expose another echoecho server on a different port than the one yogi serves unit tests from, and expose where it's mounted? This way the Y.IO tests could properly test XDR transports.
When creating the documentation for my gallery module I create an example page using the standard way to pull in a module:
YUI().use('gallery-module-name', function(Y)But that leads to an error because YUI tries to pull the gallery module from:
Which is an 404, because the gallery module isn't pushed/live yet. Apparently I need to tell Yogi where my local gallery module is located.
To fix the example page, I set the Y config to pull any gallery modules locally:
gallery: {
combine: false,
base: "/build/",
root: "/build/",
patterns: {
"gallery-": {},
"gallerycss-": { type: "css" }
}
}But then I get another 404 (YOGI Not Found):
http://127.0.0.1:5000/build/gallery-module-name/gallery-module-name-min.js
Given Yogi is used to create module files, I believe it shouldn't need extra code to load the 'local' version in the docs files, which is only confusing for an example page.
Shifter builds the files fine.
(yogi version 0.0.67)
Update: I was able to get the local build not 404 by removing and installing yogi, not sure what caused it. The request to not need custom yui gallery code to pull the javascript from the local build still holds.
I think this is related to the fix for issue #21. Yogi tries to auto update yuidoc.json. With a default install of npm, npm -g install yogi requires root access, so updating yuidoc.json also requires root access.
I got this in the terminal
[fedora@solmsted gallery-alea]$ yogi serve
yogi [info] using [email protected] on [email protected]
yogi [info] using module: gallery-alea
yogi [info] adding tests route
fs.js:338
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^
Error: EACCES, permission denied '/usr/local/lib/node_modules/yogi/configs/yuidoc/yuidoc.json'
at Object.fs.openSync (fs.js:338:18)
at Object.fs.openSync (/usr/local/lib/node_modules/yogi/node_modules/istanbul/node_modules/fileset/node_modules/glob/node_modules/graceful-fs/graceful-fs.js:68:26)
at Object.fs.openSync (/usr/local/lib/node_modules/yogi/node_modules/rimraf/node_modules/graceful-fs/graceful-fs.js:68:26)
at Object.fs.openSync (/usr/local/lib/node_modules/yogi/node_modules/cpr/node_modules/graceful-fs/graceful-fs.js:68:26)
at Object.fs.writeFileSync (fs.js:756:15)
at mods.yuidoc (/usr/local/lib/node_modules/yogi/lib/cmds/serve.js:123:24)
at mods.version (/usr/local/lib/node_modules/yogi/lib/cmds/serve.js:143:17)
at Request.mod.callback [as _callback] (/usr/local/lib/node_modules/yogi/lib/api.js:50:17)
at Request.init.self.callback (/usr/local/lib/node_modules/yogi/node_modules/request/main.js:122:22)
at Request.EventEmitter.emit (events.js:99:17)
Is there a way to chmod during install or update to relax the write permissions on that file?
Yogi will fire up selleck docs, but the examples cannot run because YUI is not defined.
No matter what I commit or push to origin:master, yogi cdn request tells me "git root is dirty, please commit first" when in the src/ directory.
There are untracked files in the directory, but these should not be causing this issue.
After successfully login in both to the YUI library and GitHub, a yogi info shows 'undefined' where my username should be, like in:
repo: git://github.com/undefined/yui3-gallery.git
I've been called a lot of things in my life, but this is a first.
My guess is that this is what is preventing me from switching to the repo which returns with a:
yogi [bail] Not Allowed
yogi whoami identifies me correctly.
Thanks
My updated module "gallery-datatable-selection" was updated on the CDN push last week.
I made an update and this week tried to do a "yogi info" in the src/gallery-datatable-selection directory and get
yogi [info] using [email protected] on [email protected]
yogi [info] using module: gallery-datatable-selection
yogi [info] showing info for gallery-datatable-selection
yogi [bail] nothing known about gallery-datatable-selection
So I deleted the build.json file, did a yogi update, and it creates everything fine. When I do another "yogi info" it gives the same "nothing known about gallery-datatable-selection" msg again.
Did I munge something up somehow?
using yogi 0.0.53
... actually, all of my gallery modules from last week, on yogi info come up this way
I have a gallery module, call it "moduleA" that I am developing and conducting unit tests on with "yogi test".
This "moduleA" has a required dependency for another gallery module (say "moduleB") so in a normal use case I would do YUI().use( "moduleA", "moduleB", ....
When I write the unit tests for "moduleA" the tests/unit/index.html looks like
<!doctype html>
<html>
<head>
<title>moduleA tests</title>
<script src="/build/yui/yui.js"></script>
<script src="js/tests-modA.js"></script> <!-- YUI.add( 'module-tests-modA') -->
</head>
<body class="yui3-skin-sam">
<div id="logger"></div>
<script>
YUI({
coverage: ['gallery-moduleA'],
filter: (window.location.search.match(/[?&]filter=([^&]+)/) || [])[1] || 'raw'
}).use('gallery-moduleA', 'test-console', 'test', 'module-tests-modA',
"gallery-moduleB",
...
But it seems like "gallery-moduleB" is not loaded (assuming it is relatively recent and is not in the current GA release build) and if I include a YUI config "gallery" property it doesn't seem to load these.
In this case assume that I don't have "moduleB" in the meta/moduleA.json "requires" but just include the dependency explicitly in the YUI.use command.
Is there a way to load existing gallery modules into a new module's "yogi test" unit tests (i.e. gallery: 'gallery-2012.xx.yy-zz') or am I completely doing this wrong ?
I'm getting an error:
$ yogi build -- load
yogi [info] using [email protected] on [email protected]
yogi [info] using module: gallery-color-palette
yogi [info] running with shifter
yogi [info] build complete
yogi [ERROR] yogi detected an error, exiting code 1
$
I'll try it again with yogi init - the one it's working on was set up manually...
Re: http://yuilibrary.com/forum/viewtopic.php?f=101&t=11704&p=37436
That issue could have been avoided if there was something saying what version of YUI was being used for testing and the location of the repo.
To take this one step further on
yogi build --loud
it could dump all of the pertinent config options
So I converted another old gallery module (gallery-datatable-formatters) per the "New Gallery Integration" writeup ... including yogi update. Everything went fine, apparently.
I upgraded my code, added tests, etc..
I noticed in the tests/unit/index.html (that was created by yogi update) that the following was set;
YUI({
coverage: ['datatable-formatters'],
filter: (window.location.search.match(/[?&]filter=([^&]+)/) || [])[1] || 'raw'
}).use(
when I ran the test coverage report (and also with istanbul) I got the "NaN%" stuff. After awhile, I checked the instrumentation file at /build/../gallery-datatable-formatters-coverage.js and noticed it
used a different "_yuitest_coverage" setup.
So when I went back to my index.html and changed this,
coverage: ['gallery-datatable-formatters'],
It worked fine, gave proper coverage statistics.
So in my case I think yogi update incorrectly setup the tests/unit/index.html with the wrong coverage flag.
Might be a bug possibly in yogi update, not sure if it still fixes my #35, or hatch's #44 or #45
I made some changes to gallery-composite-image. Using Yogi 0.0.54, when I ran yogi lint I got this output:
#1: undefined
me._data = new _ArrayBuffer(me.pixelCount * me._pixelSize);undefined
#2: undefined
return new _Class({undefined
#3: undefined
return this._setValue(_isArray(pixelIndexOrLocation) ? this.getPixelIndex(pixelIndexOrLocation) : pixelIndexOrLocation, channelIndex, value);undefined
#4: undefined
return this._dataView['get' + _Class._getTypeName(this.channels[channelIndex])](pixelIndex * pixelSize + channelOffsets[channelIndex], this.littleEndian);undefined
#5: undefined
me._dataView['set' + _Class._getTypeName(me.channels[channelIndex])](pixelIndex * pixelSize + channelOffsets[channelIndex], value, me.littleEndian);undefined
#6: undefined
return Uint8ClampedArray;undefined
#7: undefined
_Class = function (configuration) {undefined
You cannot create non-YUI core modules without the gallery- prefix.
$ yogi config set shortpath true
$ yogi init test-module
...
yogi [info] module created, here's what yogi did for you:
src/test-module
├── HISTORY.md
├── README.md
├── assets/
├── build.json
├── css/
├── docs/
│ ├── component.json
│ └── index.mustache
├── js/
│ └── gallery-test-module.js
├── meta/
│ └── gallery-test-module.json
└── tests/
└── unit/
├── index.html
└── js/
└── tests.js
This is caused by createDirs in lib/create.js using this check to determine the prefix: options.name.indexOf('gallery') === -1 && !util.isYUI().
Expected behavior: generated files should be named test-module.js, etc. Perhaps that's by design, but it would be great if this were possible.
Workaround: create a package.json file in your source root like this:
{
"name": "yui"
}
Although I'm guessing that would break other things.
I didn't know there was a yui configuration property. I am sure there are plenty more though some of them are sort of private (like the login tokens) that are handled directly by other commands.
Perhaps the plain yogi config might list those that could be modified via the `yogi config set' command itself.
I have a few CDN requests on a couple of my modules. If I do a yogi update, will they be affected? So far I created the new repository, made my local copy and now copied my modules from the old folder to the new. I stopped at doing the yogi update on each. If I change the repo and path via yogi, will it all still work?
Also, once I do this if I make changes on the new version, will there be any conflicts with the current CDN requests that will be pulled from the old repository?
In other words, can I go ahead or I should I wait until Tuesday?
Thanks
Use Case: I want to run the App Framework unit tests, but see how much of Attribute and Base are covered by those tests.
FYI: I'm on Win7 using Git Bash (sorry!)
yogi build does not work for me but shifter does:
jennyhan@GREENOURHEAT-L7 ~/web/git/yui3/src/uploader (uploader-examples)
$ yogi build
yogi [info] using [email protected] on [email protected]
yogi [info] using module: uploader
yogi [info] running with shifter
'c:\Users\jennyhan\AppData\Roaming\npm\node_modules\yogi\node_modules\shifter\bi
n\shifter' is not recognized as an internal or external command, operable program or batch file.
yogi [info] build complete
yogi [ERROR] yogi detected an error, exiting code 1
jennyhan@GREENOURHEAT-L7 ~/web/git/yui3/src/uploader (uploader-examples)
$ shifter
shifter [info] racing to find the closest .shifter.json file
shifter [info] revving up
shifter [info] looking for build.json file
shifter [info] found build.json file, shifting
shifter [info] putting the hammer down, let's build this thing!
shifter [info] munging in loader meta data into build.json
shifter [info] munging in loader meta data into build.json
shifter [info] munging in loader meta data into build.json
shifter [info] munging in loader meta data into build.json
shifter [info] putting the hammer down
shifter [info] shifting into gear for uploader
shifter [info] shifting a copy
shifter [info] shifting into gear for uploader-queue
shifter [info] shifting into gear for uploader-html5
shifter [info] shifting into gear for uploader-flash
shifter [info] copying from c:\Users\jennyhan\web\git\yui3\src\uploader\swf\flashuploader.swf to c:\Users\jennyhan\web\git\yui3\build\uploader\assets\flashuploader.swf
shifter [info] down shifting the copy
shifter [queu] file has changed, continuing build
shifter [queu] writing RAW file
shifter [queu] writing RAW file
shifter [queu] writing RAW file
shifter [queu] writing RAW file
shifter [queu] compressing uploader\uploader.js with UglifyJS
shifter [queu] writing -min file
shifter [queu] compressing uploader-queue\uploader-queue.js with UglifyJS
shifter [queu] compressing uploader-flash\uploader-flash.js with UglifyJS
shifter [queu] compressing uploader-html5\uploader-html5.js with UglifyJS
shifter [queu] writing -min file
shifter [queu] writing -min file
shifter [queu] writing -min file
shifter [info] shifting for coverage
shifter [info] shifting assets for uploader
shifter [info] shifting for coverage
shifter [info] shifting assets for uploader-queue
shifter [info] shifting for coverage
shifter [info] shifting assets for uploader-flash
shifter [info] shifting for coverage
shifter [info] shifting assets for uploader-html5
shifter [queu] coverage file read, starting coverage for: uploader/uploader.js
shifter [info] yuitest providing coverage
shifter [queu] coverage file read, starting coverage for: uploader-queue/uploader-queue.js
shifter [info] yuitest providing coverage
shifter [queu] coverage file read, starting coverage for: uploader-flash/uploader-flash.js
shifter [queu] coverage file read, starting coverage for: uploader-html5/uploader-html5.js
shifter [info] yuitest providing coverage
shifter [info] yuitest providing coverage
shifter [queu] writing coverage file to uploader/uploader-coverage.js
shifter [queu] writing coverage file to uploader-queue/uploader-queue-coverage.js
shifter [queu] writing coverage file to uploader-flash/uploader-flash-coverage.js
shifter [queu] writing coverage file to uploader-html5/uploader-html5-coverage.js
shifter [info] done racing, the gears are toast
shifter [info] finished in 0.749 seconds, pretty fast huh?
Now that component.json has the use entry, it would be cool to show it on the document template.
I've got nothing known about from a non-gallery module that is under a repository cloned from GitHub, This repository is not related to the Gallery, but it is a fork of someone else's. The folders are structured just as they would be in Gallery modules and it compiles fine using yogi and the result is a well-formed YUI module with its YUI.add() wrapper and the dependencies listed fine. In fact, I can use that module fine.
However, when I try to run any tests, it doesn't know where to find the built files for the module being tested. I can include that with a <script> tag and it runs fine, but then I cannot run the coverage tests without changing that <script> to use the -coverage version. Anyway, I don't need to do this for a regular Gallery module, I just tried it because nothing else worked.
I tried a yogi info and this is what it says:
cd /home/satyam/git/jivaprototype/src/zeView/
$ /usr/bin/yogi info
yogi [info] using [email protected] on [email protected]
yogi [info] using module: zeView
yogi [info] showing info for zeView
yogi [bail] nothing known about zeView
yogi exited, code: 1
After that I did a yogi init to add a new empty module and it creates everything fine. Comparing the files for my actual module and the fake one I created just for testing, I have all the equivalent files, build.json, the meta file, unit testing and so on.
In the info yogi init provides prior to doing the creation it shows everything right, the GitHub repository, the local path, everything as yogi info should. But then, if i actually do a yogi info the same thing happens, it knows nothing about that module. If I add the fake, empty module as a dependency of the tests yogi init created for the module, it doesn't find it either.
With yogi init failing, I cannot do --set-repo or --set-path and, anyway, when doing yogi init to create the new empty module, it showed everything fine so I shouldn't have needed to change those since yogi init knew about them.
I must have something missing and I don't know what.
Thanks in advance for your help.
At the bottom of the yogi info screen, it says:
yogi [warn] this module does not provide tests
What is it that it checks to say so, because I have an index.html file in tests/unit and that runs a .js file a further level down, in fact, I got 'green' status in coverage with the tests.
Perhaps it is checking what's up in the new gallery which, at this point is nothing? If so, that will change, hopefully in the next build.
Thanks
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.