Your (sic) are given a function as a string

"a = function(){return 1+53+324-2344*90}"

That's not a function, that's an assignment expression where the right hand side happens to be a function.

The kata is clear as mud in what exactly it wants us to do. The specification is severely lacking; limits, if any, are missing; there's a puzzle tag that means we might encounter anything, and author's rank estimate is 3kyu. Abandon all hope, ye who enter here. Prepare for Armageddon. But then you only have to jump through a reasonably-sized hoop to solve it.

Yeah, looking at the tests, the whole wrapping input and output in a function is unnecessary. Part of the kata is evaluating the expression, but there's some parsing two types of function syntax and wrapping the return value in a function to contend with, both of which are tasks that have nothing to do with arithmetic expression parsing and add relatively little - except for the fact we don't know it's limited to that, so we had better reinvent eval and just let that do the work.

The description doesn't specify what the limits of the expression are, and there's a puzzle tag. So parsing the input is severely discouraged ^*, because it might turn out to be impossible (we don't know what we're going to encounter ), and it becomes a circumventing the artificial, arbitrary, restrictions kata.

If this is to be a parsing kata, specify the expression ( and give me Function, because my own personal parser library needs it ). ( It'll also be a duplicate. )

If you want to disable eval: in JS, you can't; you'll have to create the kata in another language ( e.g. Haskell doesn't have eval ).

^* restricting Function and RegExp doesn't help.

thank you for your feedback

I can, but you won't like it.

The title is "parser," but there's no parsing in sight. Instead, there's circumventing artificial restrictions, which is something I don't like as a kata.

Also, the circumventing is not hardly a 3kyu problem, because (1) enforcing restrictions is hard to do and (2) restricting valid JS is limited to what won't kill the test suite itself, not to mention that (3) it has a tendency to restrict more and more valid JS until the reference solution is the only allowed one.

If your kata has to restrict valid JS to be interesting, I don't think it's a valid kata. Other opinions may be available.

hey, could u please write a short feedback on what should be modified/fixed/removed

hey, could u please write a short feedback on what should be modified/fixed/removed

hey, could u please write a short feedback on what should be modified/fixed/removed

hey, could u please write a short feedback on what should be modified/fixed/removed

if you see any issues, misunderstandigs or you want to clarify something, please feel free to ask

done

done!

add that spread operator to the user solution, you added it to the ref sol, adding it to both is best

oh, yeah, thank you

You give the same data to user and ref sol, user can modify this input to skrew up verification:

 assert.deepEqual(getMinAvgMax(randomDiscarded, shortRandomData),
                     solution(randomDiscarded, shortRandomData))