Writing git API for javascript node module - javascript

Hi recently I have to implement a git API for a node module, so we can have version control through programmatic interface. I came upon this post to find some good modules that I can use.
However, after playing around with some of them, I realized that none of them provide the feature of querying the commit history of a single file (like calling 'git log --follow '). I would like to extend that feature into my module but since I have no experience before, does anyone know where I should start?

The libraries you mentioned should be a good starting point. Take node-git's lib/git.js file for example. There you can find the following lines:
// Call the native git binary
Git.prototype.call_git = function(prefix, command, postfix, options, args, callback) {
// ...
This is a good starting point to understand how the author maps Node functions on system calls and and allows the callback to work with the output.
I would start a fork of the project. Look for the log function in the same file, which starts like
Git.prototype.log = function(commit, path, options, callback) {
Copy the function, give it a proper name and try to adopt it to meet your needs.
If you succeed and like to help, you could start a pull request on GitHub to help the author and add the functionallity to the official project.
I would do it this way. I hope this helps.

Related

ESLint: Environment-specific rules [duplicate]

I am collaborating on a git-sourced, maven-managed Java project with differing code styling preferences with users using multiple IDE's (note 1).
Is there a tool or IDE configuration that will allow code to be viewed and edited using style-1, but committed to SCM using style-2?
My research points me to 'no', but a solution combining git hooks and Checkstyle/jrefactory might be possible.
So if 'no' to above, is there a tool/process that will perform the TBD process actions below?
The checkout process flow for User1 would be:
git pull
TBD process formats code to User1 style-1
User1 works in their preferred IDE with style-1 settings
The commit workflow for User1 would be:
User1 is ready to commit/push code
TBD process formats code to standard format style-standard
git push
Note 1: multiple IDE's = Eclipse, IntelliJ, Netbeans.
Note 2: My question differs from this question in that I'd like to focus on an IDE-related solution, since forcing the minority of standards-divergent users is probably a more efficient solution.
Note 3: Acknowledging that this shouldn't be done for best-practices-reasons. However, if you grant that it's time expect more flexibility from our IDEs and SCMs, this question is intended to explore those solutions.
First of all, you really shouldn't do that. Codestyle wars are bad for any project, and it is best to decide upon one codestyle that everybody must use. It is simple to configure IDEs to automatically apply the specified codestyle at every filesave, so the developers don't have to write code in the target codestyle themselves, they can let the IDE do that for them. True, this doesn't solve the fact that they'll have to read code in a codestyle they don't yet like, but it's a lot safer than having invisible automatic code changes; that's a major source of bugs.
Maybe you can use Eclipse's code formatter from the command line to apply a different codestyle. You'd have to set up git hooks, make sure everybody has Eclipse available, and provide the proper configuration files for their preferred codestyle. You'd need hooks both for post-checkout and pre-commit, one to set up the user's codestyle, the other to commit in the central codestyle. To go one step further, you can play with the index to add the formatted code so that it doesn't include style differences in git diff (although they will show up in git diff --staged).
Again, you shouldn't do that.
I agree with Sergiu Dumitriu in this not being a very good idea. But still git provides exactly what you are looking for. Even though this will only work if your central coding style is very well defined and strictly followed. Here’s how it works:
Git provides smudge/clean filters. They allow you to pass all code through a so-called “smudge” filter on checkout and reverse that with a “clean” filter when code is added to the staging area. These filters are set in .gitattributes, and there is a repository-local version of that file available in .git/info/attributes.
So you set your smudge filter to a tool that will change the code to your personal coding style on checkout:
And your clean filter will convert the code back to the central coding style on checkin (more precisely: when file are staged):
It is very important, that smudge -> clean is a no-op / generates the original file again. Otherwise you will still check in format changes every time you change a file.
Using smudge and clean filters will retain all the functionality of git (including git diff etc). You can find the full docu in git help attributes

How to manipulate what `shell.which()` returns?

I have a JS/Node based CLI that was initially developed to run on macOS and Linux. I now want to make it work on Windows, but because of complicated and fixed reasons I have to achieve this without changing the app's source code.
A first step was to lie to the program about its process.platform, which works great by messing with its Module (suggested by #estus) and wrapping the original CLI in another CLI that is then actually used on Windows.
Now I stumbled over some code that runs shelljs.which('ruby') and compares the result to a specific string (/usr/bin/ruby) and outputs an error message or even fails the program when it does not match. I don't know how to overcome that yet.
How can I manipulate what shell.which() returns?
One approach that I could take would be to manipulate require('shelljs') to load my own fork of shelljs that returns whatever I want (via using override-require, which I already used to replace child_process with cross-spawn which works much better on Windows). But I want to avoid maintaining my own fork of shelljs of course - it would be much more practical if I could somehow just manipulate shelljs.which.
I created a super small demo project that is similar to the CLI I am using and can be used to experiment with possible solutions: https://github.com/janpio/nodejs-cli-wrongruby - fake.js would be where I would want to manipulate shelljs.which somehow.
With the help of #Berdi in the comments I figured out that, similar to how I can mess with process.platform, I can also mess with the shelljs.which method:
// Manipulate shelljs.which('ruby')
const shelljs = require('shelljs')
var original_which = shelljs.which
var new_which = function(cmd) {
if(cmd == 'ruby') {
return "/usr/bin/ruby"
}
return original_which.call(this, cmd)
}
shelljs.which = new_which
require("./index.js");
(This assumes the original CLI lives in ./index.js)
Here all calls to shelljs.which with the parameter ruby are answered with /usr/bin/ruby, and all the others requests are sent to the actual shelljs.which implementation.

Gnome Extensions - Run shell command

I am writing a simple extension to open browser by clicking the extension button. I would like to know if there is a function which can execute passed shell command as argument. Also, it'd be really helpful if anyone can suggest a good simple reference for extension development.
From https://github.com/GNOME/gnome-shell/blob/master/js/misc/util.js:
// Runs #command_line in the background, handling any errors that
// occur when trying to parse or start the program.
function spawnCommandLine(command_line) {
try {
let [success, argv] = GLib.shell_parse_argv(command_line);
trySpawn(argv);
} catch (err) {
_handleSpawnError(command_line, err);
}
}
There are a few variations on that method in there. Save yourself mountains of headaches and just bookmark the GitHub repository.
Some quick links:
popupMenu.js: working with popup menus
panel.js: a good read for implementing "tray" icons
modalDialog.js: some UI elements were made to be reused, runDialog.js uses this for example
mpris.js: there are also good examples of using frameworks like DBus in gjs
I can't stress enough how much you'll get out of reading the gnome-shell source. Unfortunately, it's compiled into a resource file now so we don't have local copies to stumble upon.
UPDATE (2021)
If you're reading this, please instead see the documentation available on gjs.guide. Specifically the documentation on Spawning Subprocesses, which covers why this is a bad idea in extensions and how to do it slightly less bad.
If you're not interested in the result - i.e. when you want to open a browser window - you can just use GLib.spawn_command_line_async like so:
const GLib = imports.gi.GLib;
...
(this._menuEntries[i]).connect('activate', () => {
GLib.spawn_command_line_async('firefox http://example.com?p='+ my_params[i]);
});
If you need a synchronous result, read https://gjs.guide/guides/gio/subprocesses.html

How to develop a javascript library from an already existing npm module (codius)

never done this before.
I'm using https://github.com/codius/codius-host. Codiu§ development has been abandoned, but I want to salvage part of it to use for my own project. I really need to be able to run codius commands from browser, so I need to develop a library or what you call it.
var codius = require('codius')
codius.upload({host: http://contract.host}
codius-host comes packed with command-line integration,
$ CODIUS_HOST=https://codius.host codius upload
How do I make a .js script do what the command-line command does ?
also posted on https://stackoverflow.com/questions/31126511/if-i-have-a-npm-tool-that-uses-comman-line-commands-how-can-i-create-a-javascri
hard time asking this questions since don't know where to start. help.
Assuming that you have access to the codius-host source code you should find the piece of code which manages the command line arguments. I am sure that they do handle the command and the command line arguments from an entry module/function and than later delegate the real job to a different module/function. What you need to do is to provide correct parameters to the functions which the function/module that handles command line argument calls with command line parameters.
In addition to that there are some nodejs libraries that might imitate a command line call from the program itself. One of those I know is shelljs:
https://www.npmjs.com/package/shelljs
You might want to check this out as well. With this one without bothering with the source code you might be able to imitate command line behaviour.

How to run jslint on the client?

For testing purposes, obviously not for production. What is the best way to do this?
Googling I found this tutorial, and of course the project on github.
For starters which files do I need to run:
// removed
and is there an API reference. I see there is a large comment block in jslint.js that seems to server this purpose but was wondering if there is something easier to read.
Because the client has no file access, I was planning on ajaxing the code in to get its contents.
Please never the mind, on why I want to do this on the client.
If you include the JSLint script you will have access to a single global variable, JSLINT. You can invoke it with a string and an optional map of options:
var valid = JSLINT(code, options);
The result will be true or false, depending on whether the code passed the check based on the provided options.
After this call you can inspect the JSLINT.errors property for an array of warnings, if any.
This is precisely what I have done to build JSLint integration into the editor in the articles on http://jslinterrors.com.
Have you looked at http://jshint.com/ ? Source is available here: https://github.com/jshint/jshint/
The browser bundle is available here: http://jshint.com/get/jshint-2.1.10.js and the docs describe how to call it (http://jshint.com/docs/)

Categories

Resources