Over the weekend, I was able to update IndexedDB tutorials and the jquery-indexeddb plugin. The IndexedDB site at http://axemclion.github.com/IndexedDB was changed from custom styling to default but much better bootstrap theme. I made the links easier to access, and hopefully also organized the content better.
It has been almost 2 years since I first started working on the IndexedDB examples. The implementations in Firefox, IE and Chrome were different in may ways and it was simpler to have a version for each browser. With the specification becoming more stable, the browser implementations have also become more uniform. I was able to combine the examples into one set (available here) that can run on Chrome, Firefox and IE. The older versions are now archived.
I also have to change Trialtool to accommodate the fact that accessing some properties of IndexedDB requests during certain operations now throws exceptions in Firefox and IE. For example, accessing the request.error when an operation actually succeeds throws an error. Since I was printing the entire request object so that it can be inspected, all examples were throwing exceptions.
Chrome has finally removed the setVersion method and now supports the onupgradeneeded method. This change is now reflected in the jquery-indexeddb plugin. The transaction modes and the cursor directions are also strings now.
Note that window.indexedDB is now immutable in Chrome and hence Chrome cannot force the IndexedDB polyfill to run. The polyfill can only run on Opera and Safari and I hope it is rendered obsolete when the browsers implement IndexedDB.
Automatic NPM publish via Travis
In my last post, I had written about updating the grunt plugins that I use to the latest version of Grunt. As this issue suggests, I try to keep updating my code, but almost always forget to update the version on the npm registry.
Since npm itself it a package that can be used programmatically, I decided to automate the process such that a new version is published to the npm registry every time a new package version is built successfully in the continuous integration system. Technically, it just had to be a npm publish from Travis. Note that since Travis does not preserve states between runs, there would be no ~/.npmrc and I would have to add user every time. Since travis supports adding secure environment variables, I could use that to pass the values passed to adduser using this.
I started looking at the node-publish package as it was the easiest way to push code from a CI system. Everything seemed to work well on my local system, but publishing from Travis failed. After digging through the code of npm, npm-commands and npm-registry, I noticed that npm.registry.addUser only authenticates the user and sets the user name and password in the config. It does not set the email, which is required by the publish method. I have submitted a pull request to node-publish that adds the email to the npm.config, and this fixed publish to run on Travis too.
Till the pull request gets accepted, I am using the raw npm methods to authenticate and publish to the registry. It does not have the version checking logic in npm-publish, but I can live with that as versions are not overwritten and all versions that do not exist in the npm registry (new or old) do get updated. Here is the simple code to update npm packages from travis, without the hassels of ~/.npmrc.
Note that the credentials are supplied by the environment, and as mentioned earlier, should be encrypted.
Since npm itself it a package that can be used programmatically, I decided to automate the process such that a new version is published to the npm registry every time a new package version is built successfully in the continuous integration system. Technically, it just had to be a npm publish from Travis. Note that since Travis does not preserve states between runs, there would be no ~/.npmrc and I would have to add user every time. Since travis supports adding secure environment variables, I could use that to pass the values passed to adduser using this.
I started looking at the node-publish package as it was the easiest way to push code from a CI system. Everything seemed to work well on my local system, but publishing from Travis failed. After digging through the code of npm, npm-commands and npm-registry, I noticed that npm.registry.addUser only authenticates the user and sets the user name and password in the config. It does not set the email, which is required by the publish method. I have submitted a pull request to node-publish that adds the email to the npm.config, and this fixed publish to run on Travis too.
Till the pull request gets accepted, I am using the raw npm methods to authenticate and publish to the registry. It does not have the version checking logic in npm-publish, but I can live with that as versions are not overwritten and all versions that do not exist in the npm registry (new or old) do get updated. Here is the simple code to update npm packages from travis, without the hassels of ~/.npmrc.
Note that the credentials are supplied by the environment, and as mentioned earlier, should be encrypted.
Grunt-ification 0.4
Grunt just released a new 0.4 version and there were many changes from its previous versions.The two plugins I maintain also needed to be migrated, and I just finished porting them to the newer version. This also enabled me to port my other projects that depend on this, to the latest version of Grunt.
Porting the plugins
Moving the plugins to the newer versions of Grunt was the easy task - the only API that affected them was changing grunt.utils to grunt.util. I was able to upgrade grunt-node-qunit and grunt-saucelabs. One of my projects depends on grunt-jsmin-sourcemap, and looks like there are more things to update (references to this.file, etc) and that may take a little longer.
Porting the projects
Updating the projects themselves was more work. With all default plugins now moving to grunt-contrib, I had to manually change package.json to reference individual grunt-contrib-* plugins. Including grunt-contrib is an option, but grunt-contrib on the whole is pretty large and takes a long time to install. Once in package.json, each plugin now has to be loaded using the grunt.loadNPMTasks.
Thoughts about Grunt 0.4
In general, I think Grunt 0.4 is a great step forward. The breaking changes in the API are bad, but in my opinion, necessary. Grunt is now being increasingly used in many major products and hence should move to a 1.0 soon.
Separating grunt into grunt, grunt-cli and grunt-init was the biggest change. Grunt-init will soon be replaced by Yeoman, and that is consistent with what most developers start for scaffolding projects. However, I am still trying to understand the logic behind separating grunt-cli and grunt. I do realize that grunt-cli has command completion too, but in almost all cases, users would install both of them together anyway. The grunt-cli is good for developer machines where grunt in run from the shell, but for CI, I would prefer running something like npm test instead of having to install grunt-cli and then running the tests.
Changing the name of the Gruntfile was a great idea - it tells us that the file is just a grunt runner file, and not the grunt plugin itself. Its even better for Windows users like me who do not have to explicitly invoke grunt.cmd or alias it to run grunt.
All plugins have been moved to grunt-contrib and that keeps grunt extensible. However, the annoyance resulting out of this is to include the plugin in package.json, and then loading them in the Gruntfile.js using grunt.loadNpmTask. I am sure someone will write a script to read package.json and simply load all plugins that are prefixed with grunt. Loading whole grunt-contrib just takes a lot of time and installs a lot of plugins.
Removing directives was another great idea - I have always found it to be confusing. Replacing it with the accepted template system makes things a lot easier to understand.
Overall, this is a Grunt 0.4 is a great upgrade and hope it gets to a stable 1.0 version soon.
Porting the plugins
Moving the plugins to the newer versions of Grunt was the easy task - the only API that affected them was changing grunt.utils to grunt.util. I was able to upgrade grunt-node-qunit and grunt-saucelabs. One of my projects depends on grunt-jsmin-sourcemap, and looks like there are more things to update (references to this.file, etc) and that may take a little longer.
Porting the projects
Updating the projects themselves was more work. With all default plugins now moving to grunt-contrib, I had to manually change package.json to reference individual grunt-contrib-* plugins. Including grunt-contrib is an option, but grunt-contrib on the whole is pretty large and takes a long time to install. Once in package.json, each plugin now has to be loaded using the grunt.loadNPMTasks.
Thoughts about Grunt 0.4
In general, I think Grunt 0.4 is a great step forward. The breaking changes in the API are bad, but in my opinion, necessary. Grunt is now being increasingly used in many major products and hence should move to a 1.0 soon.
Separating grunt into grunt, grunt-cli and grunt-init was the biggest change. Grunt-init will soon be replaced by Yeoman, and that is consistent with what most developers start for scaffolding projects. However, I am still trying to understand the logic behind separating grunt-cli and grunt. I do realize that grunt-cli has command completion too, but in almost all cases, users would install both of them together anyway. The grunt-cli is good for developer machines where grunt in run from the shell, but for CI, I would prefer running something like npm test instead of having to install grunt-cli and then running the tests.
Changing the name of the Gruntfile was a great idea - it tells us that the file is just a grunt runner file, and not the grunt plugin itself. Its even better for Windows users like me who do not have to explicitly invoke grunt.cmd or alias it to run grunt.
All plugins have been moved to grunt-contrib and that keeps grunt extensible. However, the annoyance resulting out of this is to include the plugin in package.json, and then loading them in the Gruntfile.js using grunt.loadNpmTask. I am sure someone will write a script to read package.json and simply load all plugins that are prefixed with grunt. Loading whole grunt-contrib just takes a lot of time and installs a lot of plugins.
Removing directives was another great idea - I have always found it to be confusing. Replacing it with the accepted template system makes things a lot easier to understand.
Overall, this is a Grunt 0.4 is a great upgrade and hope it gets to a stable 1.0 version soon.
Subscribe to:
Posts (Atom)