error using standard watch syntax
brewster1134 opened this issue · comments
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!
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.
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?
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).
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.
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.