Closed darsain closed 9 years ago
I've made the report above more concise, removed anything gulp related (as it was not related), and added a minimal code snippet required to replicate this issue.
This really hinders my development workflow as I can't use Duo from gulp, so I run everything manually. Really irritating, so could someone please look at it? I've tried but got spaghetti poisoning :)
Ok, looks like we have an issue with the "compiled" script on npm. (looks like it may not have been compiled from ES6 generators into ES5)
Adding the --harmony
flag fixes this issue for me, does that work for you @darsain ? (I'll work on a proper fix asap)
Yes, --harmony
fixes the issue. Thx, gonna switch it on until this gets fixed :)
Thanks! Sorry about the delay, but I'll see about merging a fix for this tonight.
Awesome! :)
Blah, the problem is deeper than I thought. Looks like some interaction between code that was compiled by regenerator and ware/wrap-fn is not cooperating. I'm trying to narrow down the exact code-path that causes the problem, but I haven't finished yet.
Thus, I won't be able to fix this tonight as I previously thought. I'll keep working on it though!
Chiming in here because I know I've made this mistake in the past... using fn.name
to call functions does NOT work when the code is minified / compiled and the function names are changed. Not sure if it's relevant though.
I was able to find a workaround for this problem. By exporting a hoisted function instead of a function expression, it looks like the compiled code doesn't lose access to the fn by name.
// works
module.exports = compatibility;
function *compatibility() {}
// breaks
module.exports = function *compatibility() {};
It's lame to use a workaround like this, but it's another necessary evil I guess.
As it turns out, that doesn't work in our case. Other libraries (in particular, co-parallel
) export/return expressions.
As far as I'm concerned, this is a bug in regenerator itself, so I'll submit an issue upstream.
Got similar error during using of grunt-duojs
task. CLI version works normally
What is really curious that if I call task directly with grunt duojs
— all works fine. However, if I call it in stack, with grunt default
for example — I'll receive same error.
What is more interesting, that error happens only if task called after certain other tasks.
For example, this will work:
grunt.registerTask 'default', [
'clean'
'copy:build'
'duojs' # grunt-duojs
'nunjucks' # grunt-nunjucks-2-html
'sprite'
'webfont'
'sass'
'autoprefixer'
'responsive_images:thumbnails'
'browserSync'
'watch'
]
but this will throw same error:
grunt.registerTask 'default', [
'clean'
'copy:build'
'nunjucks' # grunt-nunjucks-2-html
'duojs' # grunt-duojs. Loaded after nunjucks task
'sprite'
'webfont'
'sass'
'autoprefixer'
'responsive_images:thumbnails'
'browserSync'
'watch'
]
Why other tasks can cause that error — completely unclear for me, since they all quite isolated.
@ArmorDarks your problem should be submitted upstream to the grunt-duojs package.
I'm going to close this issue now. If you're getting these errors when requiring duo
, chances are you've not included the appropriate --harmony-generators
flag. For anyone who still encounters errors after this point, please create new issue with all relevant details so we can resolve it.
Seeing as CLI works fine, it's weird that using Duo as a module:
throws this error:
Running: