goggles.mozilla.org VS esprima

Compare goggles.mozilla.org vs esprima and see what are their differences.

goggles.mozilla.org

Update: This project is no longer maintained and has been archived. See https://foundation.mozilla.org/blog/putting-away-our-x-ray-goggles/ for more information. (by mozilla)

esprima

ECMAScript parsing infrastructure for multipurpose analysis (by ariya)
Our great sponsors
  • SurveyJS - Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
goggles.mozilla.org esprima
2 2
85 405
- -
10.0 0.0
over 4 years ago almost 3 years ago
JavaScript TypeScript
- BSD 2-clause "Simplified" License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

goggles.mozilla.org

Posts with mentions or reviews of goggles.mozilla.org. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-10-22.
  • NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised
    13 projects | news.ycombinator.com | 22 Oct 2021
    > check out the Web X-Ray repo <https://github.com/mozilla/goggles.mozilla.org/>.

    Thanks for example. Peeking a bit under the hood, it appears to be due to transitive dependencies referencing github urls (and transient ones at that) instead of semver, which admittedly is neither standard nor good practice...

    FWIW, simply removing `"grunt-contrib-jshint": "~0.4.3",` from package.json and related jshint-related code from Gruntfile was sufficient to get `npm install` to complete successfully. The debugging just took me a few minutes grepping package-lock.json for the 404 URL in question (https://github.com/ariya/esprima/tarball/master) and tracing that back to a top-level dependency via recursively grepping for dependent packages. I imagine that upgrading relevant dependencies might also do the trick, seeing as jshint no longer depends on esprima[0].

    I'm not sure how representative this particular case is to the sort of issues you run into, but I'll tell that reproducibility issues can get a lot worse in ways that committing deps doesn't help (for example, issues like this one[1] are nasty to narrow down).

    But assuming that installation in your link just happens to have a simple fix and that others are not as forgiving, how is committing node_modules supposed to help here if you're saying you can't even get it to a working state in the first place? DO you own the repo in order to be able to make the change? Or are you mostly just saying that hindsight is 20-20?

    [0] https://github.com/jshint/jshint/blob/master/package.json#L4...

    [1] https://github.com/node-ffi-napi/node-ffi-napi/issues/143

esprima

Posts with mentions or reviews of esprima. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-10-22.
  • NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised
    13 projects | news.ycombinator.com | 22 Oct 2021
    > check out the Web X-Ray repo <https://github.com/mozilla/goggles.mozilla.org/>.

    Thanks for example. Peeking a bit under the hood, it appears to be due to transitive dependencies referencing github urls (and transient ones at that) instead of semver, which admittedly is neither standard nor good practice...

    FWIW, simply removing `"grunt-contrib-jshint": "~0.4.3",` from package.json and related jshint-related code from Gruntfile was sufficient to get `npm install` to complete successfully. The debugging just took me a few minutes grepping package-lock.json for the 404 URL in question (https://github.com/ariya/esprima/tarball/master) and tracing that back to a top-level dependency via recursively grepping for dependent packages. I imagine that upgrading relevant dependencies might also do the trick, seeing as jshint no longer depends on esprima[0].

    I'm not sure how representative this particular case is to the sort of issues you run into, but I'll tell that reproducibility issues can get a lot worse in ways that committing deps doesn't help (for example, issues like this one[1] are nasty to narrow down).

    But assuming that installation in your link just happens to have a simple fix and that others are not as forgiving, how is committing node_modules supposed to help here if you're saying you can't even get it to a working state in the first place? DO you own the repo in order to be able to make the change? Or are you mostly just saying that hindsight is 20-20?

    [0] https://github.com/jshint/jshint/blob/master/package.json#L4...

    [1] https://github.com/node-ffi-napi/node-ffi-napi/issues/143

  • Validating JSON Data in typescript and return line number and position
    1 project | /r/typescript | 12 Jun 2021
    okk i found out another one called esprima i think i am going to use it