Right now users have to manually restart lineman every time they modify any of the routes in config/server.coffee, we can make this smarter so that it reboots the express server automatically on a file change; think of it like a watch process for just the config/server.coffee file.

my config/application.js

module.exports = require(process.env['LINEMAN_MAIN']).config.extend('application', {

  loadNpmTasks: ['grunt-contrib-copy'],
  appTasks: {
    common: ['copy:dev'],
    dist: ['copy:dist']
  },
"copy": {
    "dev": {
      files: [
        {expand: true, flatten: true, src: ['app/templates/*.html'], dest: 'generated/templates/'}
      ]
    },
    "dist": {
      files: [
        {expand: true, flatten: true, src: ['app/templates/*.html'], dest: 'dist/templates/'}
      ]
    }

  }

First entry in dist tasks is uglify (see lineman/config/application.coffee), but based on this output, it is not run for lineman build

... common tasks removed for brevity...

Running "dist" task

Running "copy:dist" (copy) task
Copied 5 files

Running "cssmin:compress" (cssmin) task
File dist/css/app.min.css created.

Running "images:dist" (images) task
Copying images to 'dist/img'

Running "webfonts:dist" (webfonts) task
Copying webfonts to 'dist/webfonts'

Running "homepage:dist" (homepage) task
Homepage HTML written to 'dist/index.html'

Done, without errors.

I can remove my copy tasks and insert another valid task with the same result.

Resolution

The lineman.config.extend which is whet.extend does appear to support this appending of array items. The jQuery feature this is based on behaves the same way, which means the features of using appTasks to add more tasks to the build process needs to be updated to reflect that you need to copy default contents over to use it, or, whet.extends needs to be replaced with someone that can handle this use case as described in the current lineman docs.

Now that lineman envelopes the grunt dependency, I often want to run a grunt task and be certain that I'm loading the same version that my lineman binary sees.

node_modules/lineman/config/application.js defines the root tasks that lineman executes in each of its configurations common, watch, dist.

Other properties of this file are overridable in {project}/config/application.js but not the actual list of tasks due to the way tasks are fetched inside lineman/cli.js ...

    appTasks = require(__dirname + '/config/application.js').appTasks,

We need to modify this so the list of tasks is overridable or exclude them from node_modules/lineman/config/application.js so as not to confuse people. Files in the config folder in the generated project should only point to lineman/config files that contain overridable keys.

As a general note, we should probably be clearer about what we intend to be overridable. (All? None? Some with clearer docs?).

my idea would be to support for

lineman new -t https://github.com/testdouble/lineman/zipball/master myproject

to set up the archetype from there instead of the builtin directory. Of course, the linked zipball would contain only the archetype directory, nothing else.
Beside urls it would be nice to have support for local directory paths too.

My first motivation would be issue #22 and #23. If I would have a configuration setup that's not part of the default lineman setup, then I will have to copy my configuration from other sources every time I start a new project. Instead, I could save my general project strucutre somewhere, and simply make lineman use that instead of the builtin archetype folder.

To motivate the idea further, here is a similar thing to be used with django.

Let's start with a CLI command driven by a task that downloads a known file and places it in the right spot in vendor.

A few initial concerns:

• File extension detection (js, css, png/jpg/gif) to figure out which vendor directory to stick it in
• ZIP file support (e.g. bootstrap's assets are in a ZIP with half a dozen paths beneath it)
• dependencies (e.g. backbone depends on underscore, and not only should both be pulled in, but the config/files.js needs to be updated--if we leave this for users to do manually, that's a pain.

Playing with the backbone example app. Thought it should have used coffeescript, so I was started to convert some stuff to cs.

That wraps everything with '(function() {' when it compiles. Noticed, you can add "--bare" to coffeescript compiles, and it eliminates that.

Is that the right thing to do? There a better way?

I've run into a few of the limitations with Testacular that people complain about, namely no ability to console.log and add debugger statements and use the web debugging tools front-end devs are already familiar with.

My recommendation is to replace Testacular with the much more capable Testem. Which supports debugger and console.log

I'll see what I can do about getting a pull request together to make this happen :)

When I create a new lineman project:

 $ lineman new my_project

Then:

 $ cd my_project

and Run:

 $ lineman run

I get the following:

Running "watch" task
Waiting...Warning: Arguments to path.join must be strings Use --force to continue.
Aborted due to warnings.

Apparently watch isn't firing when new js files get added.

Hi,

any idea why spec-ci is not running on window? I'm using nodejs v0.8.21 and the latest PhantomJs. See bellow the output:

Z:\Proiecte>lineman new hello
 - Assembling your new project directory in 'Z:\Proiecte/hello'...
 - Running `npm install` to install dependencies for your new project...
 - Created a new project in "hello/" with Lineman. Yay!

Getting started:
  1. `cd hello` into your new project directory
  2. Start working on your project!
    * `lineman run` starts a web server at http://localhost:8000
    * `lineman build` bundles a distribution in the "dist" directory
    * `lineman clean` empties the "dist" and "generated" directories
    * `lineman spec` runs specs from the "specs" directory using testem
For more info, check out http://github.com/testdouble/lineman

Z:\Proiecte>cd hello

Z:\Proiecte\hello>lineman spec-ci
Running "configure" task

Running "common" task

Running "coffee:compile" (coffee) task
File generated/js/app.coffee.js created.
File generated/js/spec.coffee.js created.
>> Destination (generated/js/spec-helpers.coffee.js) not written because compile
d files were empty.

Running "less:compile" (less) task
File generated/css/app.less.css created.

Running "jshint:files" (jshint) task
>> 0 files lint free.

Running "handlebars:compile" (handlebars) task
>> Destination not written because compiled files were empty.

Running "jst:compile" (jst) task
File "generated/template/underscore.js" created.

Running "configure" task

Running "concat:js" (concat) task
File "generated/js/app.js" created.

Running "concat:spec" (concat) task
File "generated/js/spec.js" created.

Running "concat:css" (concat) task
File "generated/css/app.css" created.

Running "images:dev" (images) task
Copying images to 'generated/img'

Running "webfonts:dev" (webfonts) task
Copying webfonts to 'generated/webfonts'

Running "homepage:dev" (homepage) task
Homepage HTML written to 'generated/index.html'

Running "spec-ci" task
Warning: Spec execution appears to have failed. Use --force to continue.

Aborted due to warnings.

Z:\Proiecte\hello>

I propose that we add --force by default to lineman run, and then intentionally take it out once we're ready to switch back to grunt-contrib-watch (which suppresses warn/fatal)

When configuring vendor/img to counter ../../ paths in some css libs (ie: bootstrap) we need to handle copying the dir recursively

Running "images:dist" (images) task
<WARN> Unable to read "vendor/img/img/" file (Error code: EISDIR). Used --force, continuing. </WARN>

This is a really bad bug.

Try this in any current lineman project:

$ lineman clean
$ lineman build

Uglify is apparently getting an empty file list. Now, it blows up (which it shouldn't), but more germane to us is that it shouldn't be getting an empty file list at all, as generated/app.js exists.

It seems that grunt-testem is becoming the standard task for testem. Thoughts on pulling in this task in place of the custom spec and spec-ci tasks? (Assuming it can be done while maintaining feature parity.)

Windows 7

When I run Lineman it aborts on the "watch" task:

Running "watch" task
Waiting...Warning: Arguments to path.join must be strings Use --force to continue.

Aborted due to warnings.

I am getting generated files in /generated

Any help would be appreciated.

Source maps.

Where do we stand on this, @davemo? Is this possible now?

Just installed and, even after restarting my terminal, the lineman command can't be found. Is there something I need to add to my PATH manually?

Using OS X 10.8, Node 0.10.8 (via homebrew), and Zsh

I keep forgetting to initially run npm install after creating the project.

NPM's package.json documentation seems to imply that only name and version are required properties of the file. But if you remove the author property, (perhaps to use contributors instead, which allows for more than one person) the dev:homepage task blows up:

Running "homepage:dev" (homepage) task
Warning: An error occurred while processing a template (Cannot read property 'company' of undefined). Use --force to continue.

I like the simplicity of a hello world archetype that really just shows a dead-simple project that contains one of each type of file, and doesn't burden users with any specific dependencies.

But what if Lineman supported multiple blueprints that the user could choose at creation time? I don't mean to suggest much in the way of code generation (because, yuck). But it'd be great if I could, when creating a project, get a choice of:

1. Skeleton project
2. Backbone project (with underscore, backbone, jQuery loaded)
3. Ember project
4. Express API project (with an express server and a hello world API stubbing

grunt-sass recently made a simultaneously reasonable and totally incongruous change and I don't know how to deal with it.

Breaking change.

Basically, prior to [email protected], it worked just like our other file types, we'd provide default file globs and the task would concatenate them all and our lives would be awesome.

Now, at 0.6.0, grunt-sass can only look at a single "main" scss/sass file, and will not accept an array of inputs.

My thoughts.

1. This makes a ton of sense, because of how important @import functionality is for Less & Sass. Include paths would still be "app/css" and "vendor/css", so in theory there should be no functional loss by making the switch.
2. This really makes the Sass story stick out from the others in a totally surprising way. How would a lineman user know that they need a "app/css/main.scss" file? Should we add it to the archetype? Does that mean removing Less from the archetype or having both of them in there? I don't like any of these options.
3. I feel like we need to decide quickly before Sass support is in the wild for too long, because this will definitely be a breaking change to anyone using Sass+Lineman once we upgrade. Halp!

cc @davemo @theotherzach @kbaribeau @jasonkarns

my idea would be to support for

lineman new -t https://github.com/testdouble/lineman/zipball/master myproject

to set up the archetype from there instead of the builtin directory. Of course, the linked zipball would contain only the archetype directory, nothing else.
Beside urls it would be nice to have support for local directory paths too.

My first motivation would be issue #22 and #23. If I would have a configuration setup that's not part of the default lineman setup, then I will have to copy my configuration from other sources every time I start a new project. Instead, I could save my general project strucutre somewhere, and simply make lineman use that instead of the builtin archetype folder.

To motivate the idea further, here is a similar thing to be used with django.

I'm looking to copy some files from an arbitrary project folder into the "generated" and "dist" folders when either "lineman run" or "lineman build" are run, respectively. I'm not super familiar with grunt, so I think I need to include grunt-contrib-copy, configure it and use it, but I'm not sure where to start or what how to best integrate with lineman.

I don't need any "watch" process to handle detecting if files have changed at all in these custom folders, but it would be nice if that was easy to do.

Can someone comment on how to do such a workflow?

Once I cd into my directory as in step 1, I find myself in a place where I have no idea what's next, and the list of instructions is gone. If there were a few clues in the default README, that could be cool. (Where files are located, what I should do first, stuff like that.)

when a file is deleted, watch detects it but never fires any tasks.

I'm wondering if there is any support for putting vendor js files in a certain order when they are concatenated? Or is there support for something require-js-like? I'm wondering how to port over an existing project that depends on require.js

Posting this wtf at Justin's request. (I got the answer.)

Would be nice to not have to type:

    template: JST["app/templates/mytemplate"]

and instead just have lineman infer the app/templates portion

    template: JST["mytemplate"]

Why? This will make debugging the specfiles in Chrome pleasant, and debugging production output snazzy.

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

"Have you ever found yourself wishing you could keep your client-side code readable and more importantly debuggable even after you've combined and minified it, without impacting performance? Well now you can through the magic of source maps"

As of 0.5.0, lineman new doesn't locally re-install lineman locally. This is a great start to making lineman easier to start using.

One side effect is that running npm install at any point in the app's life will have the incidental effect of installing & freezing your lineman install, which may not be intentional. Maybe all the user wants to do is add a new dependency.

Me & @davemo chatted and I think the right way out is to do this:

• Remove the lineman dependency from the archetype's package.json file
• Add a .lineman-version file to the archetype that prints the lineman version used to create the project.
• Add a lineman freeze command that optionally takes a version argument (but defaults to reading that .lineman-version file) and adds lineman as a locked dependency to the package.json and then performs an npm install.

The reason for the extra effort here:

Simply removing the dependency and leaving everything global would be fine at first, but if a global lineman upgrade eventually broke everything, or if new team members weren't able to get up and running, then there'd be no record of what version of lineman for which things did work. Storing that would be a good idea.

Concerns:

This would probably require that we change the heroku buildpack to be a good deal smarter.

It'd be really nice to have recipes like "lineman install backbone" to pull down backbone and put it into the vendor directory

In a newly generated project I'm trying to switch to Mocha/Chai but can't get it working. I know it's some work but could anyone provide some pointers on how to achieve this? Much obliged.

I just ran lineman build on a new project from lineman off master.

It looks like dist/ is only receiving the index.html file. The CSS & JS tasks aren't even running (it should be doing the hello world stuffs)

$ lineman build
Running "configure" task

Running "common" task

Running "coffee:compile" (coffee) task
File generated/js/app.coffee.js created.
File generated/js/spec.coffee.js created.
>> Destination not written because compiled files were empty.

Running "less:compile" (less) task
File generated/css/app.less.css created.

Running "jshint:files" (jshint) task
>> 0 files lint free.

Running "handlebars:compile" (handlebars) task
>> Destination not written because compiled files were empty.

Running "jst:compile" (jst) task
File "generated/template/underscore.js" created.

Running "configure" task

Running "concat:js" (concat) task
File "generated/js/app.js" created.

Running "concat:spec" (concat) task
File "generated/js/spec.js" created.

Running "concat:css" (concat) task
File "generated/css/app.css" created.

Running "images:dev" (images) task
Copying images to 'generated/img'

Running "webfonts:dev" (webfonts) task
Copying webfonts to 'generated/webfonts'

Running "homepage:dev" (homepage) task
Homepage HTML written to 'generated/index.html'

Running "dist" task

Running "uglify:js" (uglify) task

Running "uglify:css" (uglify) task

Running "images:dist" (images) task
Copying images to 'dist/img'

Running "webfonts:dist" (webfonts) task
Copying webfonts to 'dist/webfonts'

Running "homepage:dist" (homepage) task
Homepage HTML written to 'dist/index.html'

Done, without errors.

Windows 7

Running "watch" task
Waiting...>> undefined: [Lundefined:Cundefined] watch EPERM
Error compiling LESS. Use --force to continue.
info: Web server started at http://localhost:9101
info (launcher): Starting browser "PhantomJS"
info (watcher): Watching "C:/Lineman/node_modules/testacular/adapter/jasmine.js"
info (watcher): Watching "C:/Lineman/node_modules/testacular/adapter/lib/jasmine.js"
info (watcher): Watching "C:/Lineman/generated/js/spec.js"
info (watcher): Watching "C:/Lineman/generated/js/app.js"
error (launcher): Error: Command failed: 'undefined' is not recognized as an internal or external command,
operable program or batch file.

I'm trying to have a require.js loaded modules into the system

grunt-contrib-requirejs is installed together w/ grunt-contrib, but it's far from obvious how one should configure stuff for requirejs

We should specifically include the grunt-contrib tasks we are using instead of pulling in the global package:

As per discussion in #grunt on freenode that i witnessed:

robdodson: tkellen: would it be possible to update grunt-contrib to 0.3.0 on NPM? Right now it's stuck at 0.2.0 so I can't get the change to grunt-copy
tkellen: i didn't realize we hadn't pushed .3, so i added it
tkellen: you should really define your deps manually though, just grab the tasks you want directly at whatever version you want
tkellen: grunt-contrib is really just a handy way to show newcomers all the stuff

...

robdodson: tkellen: oh I didn't realize that. I thought you were supposed to grab grunt-contrib 
robdodson: thanks guys!
tkellen: robdodson: no worries man, we didn't have it documented super clearly anywhere.  it'll probably make grunt run even faster too, since you'll only be loading the tasks you care about

It is confusing for users of lineman to have to use grunt run and grunt in order to flip into dev mode and prod build mode.

Let's wrap grunt in 3 commands

• lineman run (dev mode, serves up /generated and watches for changes)
• lineman test (test mode, runs testem and watches for file changes in /generated)
• lineman build (build mode, generates production ready assets)

hi,

I'm relatively new to grunt and especially to lineman, and would like to add the grunt-reload task to my lineman project

I've npm install grunt-reload, and wrote my config/application.js as follows:

module.exports = require('lineman').config.extend('application', {
  //Override application configuration here
  reload: {
        port: 6001,
        proxy: {
            host: 'localhost'
        }
    },
  watch: {
    js: {
      files: ['<config:files.glob.js.vendor>', '<config:files.glob.js.app>'],
      tasks: 'configure concat:js reload'
    },
    coffee: {
      files: '<config:files.glob.coffee.app>',
      tasks: 'configure coffee configure concat:js'
    },

    jsSpecs: {
      files: ['<config:files.glob.js.specHelpers>', '<config:files.glob.js.spec>'],
      tasks: 'configure concat:spec reload'
    },
    coffeeSpecs: {
      files: ['<config:files.glob.coffee.specHelpers>', '<config:files.glob.coffee.spec>'],
      tasks: 'configure coffee configure concat:spec'
    },

    css: {
      files: '<config:files.glob.css.app>',
      tasks: 'configure concat:css reload'
    },
    less: {
      files: '<config:files.glob.less.app>',
      tasks: 'configure less configure concat:css'
    },

    handlebars: {
      files: '<config:files.glob.template.handlebars>',
      tasks: 'configure handlebars configure concat:js reload'
    },
    underscore: {
      files: '<config:files.glob.template.underscore>',
      tasks: 'configure jst configure concat:js reload'
    },

    images: {
      files: ["<config:files.glob.img.app>", "<config:files.glob.img.vendor>"],
      tasks: 'configure images:dev reload'
    },
    homepage: {
      files: '<config:homepage.template>',
      tasks: 'configure homepage:dev reload'
    },

    lint: {
      files: '<config:files.glob.js.app>',
      tasks: 'configure lint'
    }
  }
});

simply to add the reload task to some sections.

Using it fails though. To reproduce, I've started lineman run and modified a js or template file:

Running "watch" task
Waiting...OK
>> File "app/templates/hello.us" changed.

Running "configure" task

Running "jst:compile" (jst) task
File 'generated/template/underscore.js' created.

Running "configure" task

Running "concat:js" (concat) task
File "generated/js/app.js" created.

Running "reload" task
File updated. Reload triggered.

Running "watch" task
Waiting...Got error: connect ECONNREFUSED

when I set the port to 8000 (where the watch server serves), I got no errors, but reload still does not happen.

I would like to run grunt-reload to reload the browser when less and css files change. Of course, I could use guard for this but it would be nice to have just a single tool.

Right now the package.json on newly created projects is just a flat file with a silly name ("my-lineman-project"). The name should match a dasherized version of the user's project name input.

Also, the lineman dependency version should be read from lineman itself instead of being manually maintained in the repo, which is obviously error prone.

We should probably have jasmine. I'm pretty sure I'm under contract to never publish anything JavaScript-related without it.

Getting this when using lineman run with actual JS sources. Not sure how long it's been busted given that my active projects are all CoffeeScript-only:

Running "watch" task
Waiting...OK
>> File "app/js/hello.coffee" deleted.
>> File "app/js/sign-up.js" added.
Fatal error: Task "lint" not found.

The previous solution using Testacular detected spec:once in order to enable a CI mode. Testem supports a CI mode as well, but I think we need to look at an alternative way to implement. My recommendation is something from the outside in, but I'm not sure we need to use Grunt to wrap it inside our cli.js file.

Just did a lineman new and the resulting project didn't get .gitignore. Did something change with the upgrade that affects our copy command?

Right now if you generate a scaffold into a directory lineman doesn't check to see if the directory exists. Had this happen during my demo at a meetup and was confused about wtf happened for 30 seconds 🌴

cc/ @davemo

I struggled to write a stub endpoint that could read POST params. req.body was undefined b/c the bodyParser() middleware had been removed. I had to add this to my lineman project:

var express = require('./../node_modules/lineman/node_modules/express');

module.exports = {
  drawRoutes: function(app) {
    app.use(express.bodyParser());

    app.post('/accounts', function(req, res){
      console.log("Creating a user for", req.body);
      res.send(201);
    });
  }
};

Is there another way to do this? Requiring users know about this middleware in order to get at POST params seems way too difficult.

How is lineman meant to integrate with package managers?

I am currently testing bower, but not sure how I should best include the relevant source files I need. Eg. for backbone support the relevant file I want to include is located say here:

/my-project/components/backbone/backbone-min.js

I tried adding this file to files.js:

module.exports = require('lineman').config.extend('files', {
js: {
backbone: "components/backbone/backbone-min.js"
}
});

Did not really do much.

Adding it to vendor/js will include it, but then I run into problems with the order of my dependencies being loaded.

Any tips?

Pull up anything that gets generated in the archetype that might break in a Lineman upgrade.

Currently looking at:

archetyp/config/spec.json
archetype/grunt.js

Standard action immediately after lineman new is to manually cd into the new project. Perhaps lineman new should do it for us?