While it is convenient to use a directory reference for a "scripts" entry to indicate that all files within that directory should be included, it doesn't allow for ordering of files (aside from file name ordering).

To force specific files to be included first, I can add specific file references before the directory reference but this will currently cause that specific file to be included twice (once for the file ref, once for the directory reference - assuming the file is within the directory)

ex:
"scripts": [
"js/foo/common.js",
"js/foo"
]

There should be an easy way for a project using lumbar to access the stylus compiler object so that methods such as use can be called on it.

Async tests create additional complexity in the system that is not going to be seen in production use cases.

Currently templates are included even if the javascript they are registered with is excluded due to platform restrictions.

Requiring that exports is used for the sources defined in the application module causes a bit of pain when moving files in and out of the root module.

After working with this for a while it feels like we should change it so the application object is accessible for the entire lifetime of the app module.

To do this we will want to make sure that we document the change in behavior so that users should take care when assigning to the exports object as this will not necessarily be the same thing in later contexts if not properly updated.

In the scripts array, if you have :

[
'views/shelf/'
]

All views except for 'views/shelf.js' will be included. Need to use:

[
'views/shelf/shelf.js',
'views/shelf/'
]

for now. Kevin, I believe this has to do with the directory traversal code that I wrote. I'll investigate.

For both the css and javascript loaders Lumbar should support optional long expires cache busting.

Add support for module-based stylesheets. This should follow the same behavior as javascript modules in terms of combine flags, etc.

Example config:

{
  "modules": {
    "base": {
      "styles": [
        {"src": "iphone.styl", "platform": "iphone"},
        {"src": "android.styl", "platform": "android"},
        "styles/base.styl",
        "styles/header.styl"
      ]
    },
    "home": {
      "styles": [
        "styles/home.styl"
      ]
    }
  },

  "styles": {
    "pixelDensity": {
      "android": [ 1, 1.5 ],
      "iphone": [ 1, 2 ],
      "web": [ 1, 2 ]
    },
    "includes": [
      "nib",
      "styles/global.styl"
    ]
  }
}

Templates for example creates templates registered as templates/foo//bar.handlebars. If a trailing slash is using in the config file.

If the lumbar build is scripted as a smaller part of a larger build, I would expect that the callback would be called once (for both success and error scenarios). Currently it is called multiple times if there are multiple errors.

This is causing intermittent failures in the unit tests as these are run async. This should not impact live use-cases.

Source router files should declare what class they are extending.

After running jake watch, and modifying lumbar.json I sometimes get this error, and then the the process ceases to respond, but does not exit. Like all fun errors this does not happen 100% of the time when modifying lumbar.json

lumbar err:
lumbar err: /Users/ryan/Projects/phoenix/node_modules/lumbar/lib/plugins/template.js:12
lumbar err: data = data.toString();
lumbar err: lumbar err: ^
lumbar err: TypeError: Cannot call method 'toString' of undefined
lumbar err: at /Users/ryan/Projects/phoenix/node_modules/lumbar/lib/plugins/template.js:12:17
lumbar err: at /Users/ryan/Projects/phoenix/node_modules/lumbar/lib/fileUtil.js:36:9
lumbar err: at Array.forEach (native)
lumbar err: at _callback (/Users/ryan/Projects/phoenix/node_modules/lumbar/lib/fileUtil.js:35:21)
lumbar err: at [object Object]. (fs.js:88:5)
lumbar err: at [object Object].emit (events.js:67:17)
lumbar err: at Object.oncomplete (fs.js:1058:12)

watch is not working. updating a file with vim doesn't result in the module being re-built.
tried running echo foo >> fileName on a .handlebar file and saw the result though. watch is working in this case, but it doesn't if I use vim to edit the file.

Stylus ran into similar issues
fs.watch is buggy, their solution was to use watchFile again.

Lumbar should support express middleware that handles recompiling resources on the fly.

The primary goal here is provide an alternative to the watch implementation that doesn't suffer from the concerns that that has (EMFILE, page refresh before resources are regenerated, etc). Supporting this in production environments is not a high priority for the initial implementation.

After completing all of the file operations in non-watch mode sometimes the executable will hang, breaking any build scripts that depend on lumbar completing manually.

I suspect that while in this start there is some pending operation on the node event queue that never fully finalizes but this needs to be researched.

Currently errors if files that are included via directory lookup are removed from the project.

lumbar err:
lumbar err: /Users/kdecker/dev/walmart/lumbar/bin/lumbar:39
lumbar err: throw err;
lumbar err: ^
lumbar err: Error: ENOENT, No such file or directory './js/collections/checkout/cart.js.bak'

Need to protect from failure in this case.

Also looks like we need to tighten up the extension lookup to prevent matches like the above.

There are some instances where it is useful for javascript to be aware of some of the layout variables used in the stylus layer. To keep this DRY there should be some method to define variables that are then accessible to both javascript and stylus implementations.

Regexs are not included in the standard rules right now. They would be a valuable addition.

Need to propagate lumbar exceptions up the callback stack and handle in the same manner as any other exceptions.

Hello,

I want to simply copy html-files without any modifications.

ATM i do it like this:

  "modules": {
    "base": {
      "static": [
        {"src": "app/tpl/user.html", "dest": "tpl/user.html"}
      ]
    }
  }

And the tpl/user.htmllooks like this:

<div><%= name %></div>

The copied result is:

<div></div>

but i need the exact contents of the original file.

Thanx in advance

Something in the checkout module is causing numerous file rebuilds to occur rather than a single one (appears to be about 6 per platform)

Some plugins like the stylus plugin are CPU bound and sync. Should look into parallel execution libs to see if they can improve the performance there.

https://github.com/pgriess/node-webworker
https://github.com/xk/node-threads-a-gogo
Others?

There are a few cases so far where it would be beneficial to allow plugins to declare dependencies on the completion of other modes, primarily the inline-styles and inline-modules implementations.

When a given mode is dependent on others it should be executed only after a given mode. On rebuild for the dependent mode it should be able to rebuild an affected files.

Non-dependent modes should continue to operate in parallel.

For consistency in examples, documentation and application authorship in general the application object (Application, Phoenix, etc) should be available inside of the base module as an alias to exports.

We should display an error message like:

Too many files open, run ulimit -n 9999

when we get an EMFILE exception. Also add a command line option to auto increase the ulimit. I think this should default to true or a high number and be opt out rather than opt in. Having it at all even if it is opt in is still a win.

npm install -g lumbar returns npm ok, however no files seem to be added to my global dir, and lumbar build returns lumbar: command not found.

Would love to use this tool, any suggestions?

Operations that may change a lot of files at once such as git pull or checkout operations can cause lumbar to crash. This seems to occur more frequently when the lumbar config file changes in addition to file changes only.

Hey there,

In order to try out lumbar, I checked out the thorax-example project. After creating a build directory and ran the following, with the following result:

$ lumbar build lumbar.json ./build

/usr/lib/node_modules/lumbar/bin/lumbar:200
      throw err;
            ^
Error: EISDIR, illegal operation on a directory

Unfortunately, the err object doesn't contain a stack trace, so I'm pretty clueless on what I can do about this...

Using watch works a bit better:

$ lumbar watch lumbar.json ./build
Error: EISDIR, illegal operation on a directory
        compiled ./build/web/hello_world.css
        compiled ./build/web/[email protected]
        compiled ./build/web/base.css
        compiled ./build/web/[email protected]
        compiled ./build/android/native-hello-world.css
        compiled ./build/android/[email protected]
        compiled ./build/web/index.html
        compiled ./build/android/index.html
        compiled ./build/iphone/native-hello-world.css
        compiled ./build/iphone/[email protected]
        compiled ./build/ipad/native-hello-world.css
        compiled ./build/iphone/index.html
        compiled ./build/ipad/index.html
        compiled ./build/web/base.js

At least I get some output now, but as you can see, no JavaScript is generated for the various mobile platforms making the builds pretty useless.

Any help would be appreciated.

Regards,
Arend.

Ex for pixelDensity: [1, 2]:

"base": [{
    "href": "base.css",
    "maxRatio": 1.99
},
{
    "href": "[email protected]",
    "minRatio": 1.01
}]

The data here should take the average of the densities and define that as the middle point, opting for the more dense data. I.e. the example above should be something like:

"base": [{
    "href": "base.css",
    "maxRatio": 1.49
},
{
    "href": "[email protected]",
    "minRatio": 1.5
}]

Should create a plugin that takes module references in HTML files and inlines the results, i.e.

  <script type="text/javascript" src="module:foo"></script>

Would be converted to

  <script type="text/javascript">var Foo = bar;</script>

Currently does not rebuild if a template is loaded through a directory reference.

In the "packages" section, when specifying "combine: true" the output file is the same as the package name. It would be nice if the name were configurable, so the output of multiple package builds result in the same output filename.

"packages": {
    "samsung-webkit": {
        "platforms": [ "samsung-webkit" ],
        "modules": [ "samsung", "base" ],
        "combine": true,
        "name": "base" 
    },

   "chrome": {
       "platforms": [ "chrome" ],
       "modules": [ "chrome", "base" ],
       "combine": true,
       "name": "base"  
   }
}

Little bit of RD here, but should investigate the performance impact of localStorage cache for loading modules.

Should behave in a maner similar to stylus to allow the server to recompile on demand rather than watching and recompiling everything.

Updating the unit tests for each change to the example project is turning out to be a maintenance concern. Should fork the code there.

I.e. when using multiple pixel densities in the stylus plugin changing one stylus file will cause a watch notification for both the 1x and the 2x version of the resource, both of which cause a rebuild.

Need to update the callback mechanism to focus more on the creation of modules or combined files rather than on the creation of individual files.

Create drop in loader scripts that can be used by implementors with little or no modification.

We should update the build and watch APIs to accept an array of modules as inputs rather than just one parameter.

Current re-reads files for each platform built. Should implement a file cache if possible. This should be extremely short-lived.

Currently throws

lumbar err: /Users/kdecker/dev/walmart/lumbar/node_modules/handlebars/lib/handlebars/compiler/parser.js:97
lumbar err: throw new Error(str);
lumbar err: ^
lumbar err: Error: Parse error on line 2:
lumbar err: ...ent"> {{ActualCart} TODO : Should
lumbar err: ----------------------^
lumbar err: Expecting 'CLOSE', 'STRING', 'INTEGER', 'BOOLEAN', 'ID', 'SEP'
lumbar err: at Object.parseError (/Users/kdecker/dev/walmart/lumbar/node_modules/handlebars/lib/handlebars/compiler/parser.js:97:11)
lumbar err: at Object.parse (/Users/kdecker/dev/walmart/lumbar/node_modules/handlebars/lib/handlebars/compiler/parser.js:173:22)
lumbar err: at Object.parse (/Users/kdecker/dev/walmart/lumbar/node_modules/handlebars/lib/handlebars/compiler/base.js:9:28)
lumbar err: at Object.precompile (/Users/kdecker/dev/walmart/lumbar/node_modules/handlebars/lib/handlebars/compiler/compiler.js:741:24)
lumbar err: at /Users/kdecker/dev/walmart/lumbar/lib/plugins/template.js:43:27
lumbar err: at /Users/kdecker/dev/walmart/lumbar/lib/fileUtil.js:32:7
lumbar err: at [object Object]. (fs.js:107:5)
lumbar err: at [object Object].emit (events.js:61:17)
lumbar err: at afterRead (fs.js:878:12)
lumbar err: at wrapper (fs.js:245:17)

Should be able to define a path relative to the core lookup path so referenced images can be located elsewhere.

We need to add build-time support for resource inclusion. To achieve this we need to implement a core plugin that adds a static key to modules. This key should be an array of resources that will be included at build time following the standard resource inclusion rules.

Example:

"modules": {
  "module": {
    "static": [
      {"src": "iphone/index.html", "platform": "iphone"},
      {"src": "android/index.html", "platform": "android"},
      {"src": "web/index.html", "platform": "web"},
      "external/image/path.png"
    ]
  },