Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

npm module #29

Closed
mitica opened this issue Apr 14, 2015 · 11 comments
Closed

npm module #29

mitica opened this issue Apr 14, 2015 · 11 comments
Labels
Milestone

Comments

@mitica
Copy link

mitica commented Apr 14, 2015

Will you publish a npm module?

@armandabric
Copy link

👍

1 similar comment
@jpravetz
Copy link

jpravetz commented Dec 1, 2015

+1

@rreusser
Copy link
Contributor

rreusser commented Jul 20, 2016

Here's an abandoned npm module (no valid gh repo): https://www.npmjs.com/package/node-expression-eval
And a somewhat heavily modified fork: https://www.npmjs.com/package/js-expression

It looks like there's still room for a nice clean mainstream module of this. @silentmatt if it works for you, I'd love to make the following changes and publish to npm:

  • fix 10/-1 parity issue (done? see Fix 10/-1 parity error and add tests #42)
  • add a linter (looks like one was used, but not explicitly enforced. no strong preference here—main goal is to catch messy things like unused/duplicate variables. I like semistandard since it's zero-config and good enough, but I'm flexible)
  • add package.json
  • add travis.yml

Bottom line: math.js is like > 400K. jsep isn't without issues and doesn't do super-simple evaluation. Esprima is overkill. So unless there's another candidate for sanitizing and evaluating expressions, seems like there's value in tightening things up and publishing it as a simple, robust expression evaluator.

@silentmatt
Copy link
Owner

@rreusser That sounds good to me. I pretty much have the same thoughts about semistandard, but I'm not sure about changing from tabs to spaces, only because it eliminates any git blame history. Although that might not be a huge deal, because for an old project there's not a huge amount of activity anyway :)

@rreusser
Copy link
Contributor

Ah, git blame -w? Does that blame while ignoring whitespace? If so, that's pretty cool! http://stackoverflow.com/questions/3945382/git-commit-that-doesnt-override-original-authors-in-git-blame

@silentmatt
Copy link
Owner

That works for me then. I'll take a look at your pull request and probably merge it tonight after work.

@rreusser
Copy link
Contributor

rreusser commented Jul 20, 2016

Cool. Really appreciated! Used it to make a pretty straightforward function plotter: http://rickyreusser.com/plotly-expression-transform/ (source WIP. Unfortunately you need to double-click to get the change to have any effect. Still straightening that out.)

@silentmatt
Copy link
Owner

Nice 👍 That was actually my original use case for this.

@jonkemp
Copy link

jonkemp commented Sep 6, 2016

Was this ever published to npm?

@silentmatt
Copy link
Owner

@jonkemp Not yet. I've been working on cleaning up the parser to make it clearer and easier to modify without breaking. I'm about done with that and I'm hoping to get that pushed out this weekend, and then publish it to npm.

@silentmatt
Copy link
Owner

It's actually been available in npm for a while now, but I'm closing this now that version 1.0.0 is out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants