Goggles.mozilla.org Alternatives
Similar projects and alternatives to goggles.mozilla.org
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
ua-parser-js
UAParser.js - Free & open-source JavaScript library to detect user's Browser, Engine, OS, CPU, and Device type/model. Runs either in browser (client-side) or node.js (server-side).
-
JSHint
JSHint is a tool that helps to detect errors and potential problems in your JavaScript code
-
handlebars-helpers
188 handlebars helpers in ~20 categories. Can be used with Assemble, Ghost, YUI, express.js etc.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
esprima
ECMAScript parsing infrastructure for multipurpose analysis (by ariya)
-
node-ffi-napi
A foreign function interface (FFI) for Node.js, N-API style
goggles.mozilla.org reviews and mentions
-
NPM package ‘ua-parser-JS’ with more than 7M weekly download is compromised
> 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
Stats
The primary programming language of goggles.mozilla.org is JavaScript.
