traa edited this page Dec 16, 2012 · 6 revisions
Clone this wiki locally

Project init in details

After typing creng init projectname gem will generate project skeleton

-build (empty now, will be used for build command)

(in manifest.json name of extension will be the same as your project name)

Building project (in project root dir)

creng build

It's really easy. But to use power of creng build, you must know following rules (don't forget, all those actions must be performed in dev folder, build folder will be wiped!! on every build):

Frameworks autoload

If you want to automatically load in your content.js (script, which will be executed in every opened and permissioned tab) some framework, just place it under /js/vendor/content directory

If you have background page, you can include in it frameworks in the same way, placing your frameworks under /js/vendor/background directory

Surely, you didn't need to duplicate frameworks, if you want to use same file for content and background, just place it under /js/vendor directory.

Wrapping in define statements

For easier module management, creng offers you require-like load syntax, but it's has some inconveniences, like ubiquitous define statements. Now you didn't need to write it by yourself, creng will automatically wrap your files in those code blocks, so you can write more cleaner code.

Web Accessible Resources management

Since manifest version 2, in chrome extension manifes was added necessarily section "web_accessible_resources" which must be filled with all used in your extension files. It's really annoying to write all of those filenames everytime, when you add something, so creng will automatically manage this section, scanning file list and adding necessary files to manifest. Forget about this routine!

Background page management

Just remove background*.html file and after build your manifest will be updated. Want to use power of event background pages? Just rename it from background_persistent.html to background.html and in build version your manifest will be properly handled.

Build version tracking

Usually, build version is the fourth digit in version number. So, after every build your build digit will be increased. Sometimes it really helpful.

Options page handling

Simple as background pages. Just create file, named options.html in html folder and you can use it as your extension options page.

Extension type handling

Same technique. Just create html/browser_action.html for browser action type, html/page_action.html for page action type or delete those files (if created) to switch for hidden type extension. Title of popup will be parsed from

tag in those html files. Images for those buttons will be used by default, same as your extension using by default.

Override new tab, bookmarks and history pages

Yes, you guessed it. Create override_tab.html ( override_bookmarks.html or override_history.html) in html folder to enable override pages feature.

Blocks of code, available only in dev version

For example, if you have something like this:

if (argument) {

running creng build in project directory root will cut all text between //devblock_start and //devblock_end including those comments. Surely, you can leave this code in build if you want, just use --withdevblock flag with creng build.

Removing all console.* calls

Usually, in build version we don't need console.log, console.warn and other console calls. So, we can cut them, using flag --noconsole while building. Just like this:

creng build --noconsole

Adding webRequest functionality in a few seconds

creng feature add web request

This command will do the following:

  • file js/requestInspector.js will be created with sample webRequest listener code.
  • manifest.json will be updated with proper permissions ("webRequest" and "webRequestBlocking")
  • sample code will be shown to user in console, user can copy this code and paste it in background scripts in right place


I'm working on next gem features, but feel free to contact me, if you have an idea for this gem.