chocolateboy

For me, the expectation is that they'll execute in the order in which they're written i.e. a pipeline: ``` fn.decorate(@foo).decorate(@bar).decorate(@baz) ``` The functional composition interpretation might make more sense if...

**Packages**: - grunt v0.4.5 - grunt-cli v1.2.0 - grunt-contrib-clean v0.6.0 - grunt-legacy-util 0.2.0 - node v6.3.1 - npm 3.10.5 **Error**: ``` TypeError: grunt.util._(...).chain(...).pluck is not a function at Object. (node_modules/grunt/lib/grunt/task.js:260:55)...

Just spotted another example of this where there's a discrepancy between a package in `node_modules` and the tarball for that module on NPM. Specifically, the `package.json` for a nested dependency...

It might have something to do with this: https://github.com/npm/npm/issues/4042

> Always.. regexes not enough. I can't think of any reason why a regex shouldn't work (and correctly handle comments) for ES5 functions, but it [won't work for ES6 functions](https://github.com/regexps/function-regex/issues/2#issuecomment-84482489):...

I was wrong about the "nit". I'd forgotten that JavaScript doesn't provide a way to make `.` match newline. Still, `[\s\S]` matches everything and `[\w\W]` matches everything, so only one...

Something like this should work (though note the parameter list includes comments): ``` ^ function (?: space+ (ident) )? space* \( space* (params)? space* \) space* \{ (body) \} $...

> what about /* 3 */ and /* 6 */ comments? The regex originally included them. Put them back in if you want them :-) ``` javascript var fn =...

> but we should only handle this case 'functionfoo(){}' That's already handled by this regex, as well as other fixes e.g.: ### current regex ``` javascript // invalid identifiers: shouldn't...

> is this going to be used in esprima or acorn? ? Why would it be used in a parser? Parsers are tools for [doing this correctly](https://www.npmjs.com/package/function-to-string#documentation) in _all_ cases....