error using standard watch syntax

[brewster1134]

So based on the example provided through guard init coffeescript, i can get it working... however i prefer the approach of calling multiple watch methods explicitly, however that does not seem to work with this guard plugin.

# this works
coffeescript_options = {
  input: '.',
  output: '.dist',
  patterns: [%r{^(.+\.(?:coffee|coffee\.md|litcoffee))$}]
}

guard :coffeescript, coffeescript_options do
  coffeescript_options[:patterns].each { |pattern| watch(pattern) }
end

# this does NOT work
guard :coffeescript, input: '.', output: '.dist' do
  watch(%r{^(.+\.(?:coffee|coffee\.md|litcoffee))$})
end

also (despite the examples in the README), without providing an input value, throws the error :input option not provided (see current template Guardfile)

having all my guard plugin declarations contained to the guard block makes my larger Guardfile much easier to read, so hopefully i just have some syntax incorrect.

ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin14]
Guard version 2.13.0
guard-coffeescript (2.0.1)

thanks!

[e2]

It's a workaround - notice coffeescript_options are passed to the plugin - the patterns in the options are used by the plugin too, not just in the watch blocks below.

[brewster1134]

So the data in the coffeescript_options object are represented still. the options are passing to the guard method, and watch calls the patterns separately instead of in an each loop. am I missing something?

[e2]

The patterns have to also be passed as an option - the plugin needs to know the pattern internally.

(AFAIR, this is due to API changes in Guard, which prevent the watched patterns being accessible from inside a plugin).

[brewster1134]

Running guard-rspec in tadnem with similar exampls in https://github.com/guard/guard-rspec seem to still be working, so just a bit confused about what changed, and why the pattern being defined IN the block no longer works.

[e2]

The options are shared because of how guard-coffeescript relies on patterns internally, especially for the run_all case.

So it's not enough to just have patterns defined in blocks (which guard-coffeescript itself has no longer access to).

The reason guard-rspec doesn't need this is because of default spec paths supplied by RSpec configuration.

Previously, guard-coffeescript "extracted" the patterns from watches through Guard internal API, which pretty much was a "hack".

This also caused problems, because the user had little control over the patterns, and it caused confusion in some cases.

You can think of the :patterns field in the hash as what previously were patterns in watches.