vim.js VS esprima

I've actually just added Vim to my "OS". Hoping to do a video on it shortly. I used https://github.com/coolwanglu/vim.js.

Then, I'd probably start studying a few different things.... First, RiftSketch itself, to try to figure out where changing controls would even happen. You'll likely end up having to rework a bit of it. Then if you're not sure how to actually program the controls, maybe look into how other things have implemented vim-like controls. There have been several browser extensions to do that, and plugins for a lot of popular IDEs, too. Looking through those should be somewhat easier than looking through Vim, since they're specifically about what you're trying to do (adding vim-like controls, albeit onto a different program). There have been various Vim-in-javascript implementations in the past, too, though I don't know how overkill those will be for your purposes. Maybe adapting one of those might work better for you than making vim-like interface from scratch? A few that I just found quickly: https://github.com/coolwanglu/vim.js https://github.com/itsjoesullivan/js-vim https://github.com/akahuku/wasavi https://github.com/thoughtbot/vimulator

> 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

okk i found out another one called esprima i think i am going to use it