Develop Reference

RedBaron analog in javascript?

I need to read a python file from javascript. I used in another project RedBaron which was quite helpful since I can easily access different node types and their value. Since I cannot use this library in Javascript since RedBaron is a python library I wanted to ask you all if you know a library that is similar to RedBaron.
Thanks in advance!
I tried using a line by line reader in Javascript but it is not sufficient for my needs. As I explained earlier I want to access different node types their values or operators.

Remap Java calls in JavaScript Nashorn

I am currently trying to make JavaScript support for the game "Minecraft" using Nashorn. My goal is to give users the ability to create their own commands and features.
For the most part it is working fine so far but the problem is that Minecraft's code is obfuscated when using it with Forge.
For that reason all field and method calls have to be re-mapped with their corresponding srg names.
Example: mc.thePlayer.swingItem(); to mc.field_71439_g.func_71038_i();
I am able to inject code into the Nashorn library using Mixin and I have already made a parser for the srg file. In a nutshell, what I need is the method I can use to replace thePlayer with field_71439_g or swingItem()V with func_71038_i()V before actually executing the code.
I have already tried finding the proper methods for hours.
https://github.com/CCBlueX/LiquidBounce1.8-Issues/issues/2649

You need MCPbot
Or rather, its mappings exports.
Note that MCPbot, as its name implies, is a bot. Specifically one on an IRC channel so that mod developers can go "hey I figured out what func_12345_a does" and tell the bot, giving it a human-readable name, named parameters, and javadoc and the next build of Forge will include these updated mappings for modders to use.
(The "MCP" part stands for "Minecraft Coder Pack.")
You can find exports of the SRG name mappings on the MCPbot website of which you'll need both csv files: Fields and Methods (as they're exported separately).
I will note, however, that including these mappings in your mod will probably violate copyright and you should check with Prof Mobius before using them in this manner.

Solution
Just inject into this methods of "jdk.internal.dynalink.beans.AbstractJavaLinker"
Remap methods:
addMember(Ljava/lang/String;Ljava/lang/reflect/AccessibleObject;Ljava/util/Map;)V
Remap fields:
addMember(Ljava/lang/String;Ljdk/internal/dynalink/beans/SingleDynamicMethod;Ljava/util/Map;)V
setPropertyGetter(Ljava/lang/String;Ljdk/internal/dynalink/beans/SingleDynamicMethod;Ljdk/internal/dynalink/beans/GuardedInvocationComponent$ValidationType;)V

Gulp task to translate JS

I'm working on a JavaScript app and have so far entered all my strings as plain text.
This is starting to feel really hacky (I'm used to gettext) so I'd prefer to wrap them all in something like {{translatable_string}} and have a gulp task just search/replace them all during the build step.
So, my question is; is there a generic (no framework-specific like angular-gettext or something like that) gettext replacer out there?
Obviously it doesn't even have to be connected to JavaScript in any way, you should be able to run it on any file type and have {{translatable_string}}:s be translated.

You may want to look into using gulp-replace. As they explained in this answer, you should be able to use it to find and replace any string that you want in the stream.

I suggest a database of strings for your translations if dynamic generation of page content is possible for your app. Starting with English or whichever is normal but the need to localize content is a tough issue without a robust system. A simple MongoDB table can be used to store the content, and when the app needs an interface it can be loaded with the right localized strings. As a for instance:
if(err) alert("Please turn off caps lock");
could become:
if(err) alert(Please_turn_off_caps_lock.English);
If you are needing to build static pages with gulp, a database in conjunction with gulp-replace sounds interesting. Using gulp-data to call up and package the strings, you can then feed it to gulp-replace and alter the files. The extensible nature of databases or document stores enable you to expand your localization without hacking on individual files or trees all the time.

Try gulp-gettext-parser.
var gettext = require("gulp-gettext-parser");
var rename = require("gulp-rename");
gulp.task("gettext", function() {
return gulp.src("src/**/*.js")
.pipe(gettext())
.pipe(rename("bundle.po"))
.pipe(gulp.dest("dist/"));
});

Perhaps what you need is mustache.js, take a look: https://github.com/janl/mustache.js/
I'm not used to work with mustache, but I had to do some updates in a project done with it, and I was surprised the capabilities it have.
If you're familiar with jade (now renamed to pug), you'll find is something similar but at the end, you're not forced to generate only html files, you cand generate any kind of text file.
This blog could be helpful to understand the differences between some other templating languages over Nodejs: https://strongloop.com/strongblog/compare-javascript-templates-jade-mustache-dust/

Include javascript file in Node.js without require('..') ing

jade permits you to simply write
include folder/file
to include code from another file.
Is it possible to add simply cut - copy style code from another file in node for javascript files?
Its for development purpose, to isolate some code and work on it seperately.
PS:- I'm aware of require('jsfile.js') and export.x = function(){..

The accepted answer is wrong.
Depending on whether node fs and eval were available at the time this question was written, the accepted answer was probably always wrong.
While not recommended, what you want to do is essentially possible:
Use node's built-in filesystem functions to read the file you want to "copy-paste" into the current file.
Use eval() to "paste" that file into your current file and run it as if it was part of the current file.
https://github.com/dennishall/node-require-without-require

Update 6 Oct 2020: Embarrassingly, the answer I've provided below is false.
I am not certain what were the circumstances for my writings below, as I was familiar with eval at the time (and a very long time before then), however, it is what it is :)
Read the answer that #Dennis wrote for the correct one.
You cannot merge (or include) a script file into another script file during runtime. Utilizing require is your best option to separate your application logic into multiple files.
JavaScript is an object oriented language, and what you are asking for is a solution to a problem that exists in procedural programming languages.
I suggest that you design your application in such a way that would allow you to separate its files into object types that take on different responsibilities instead of treating each file as a script within some global state.
To answer your other question, Jade is actually parsing its source files and therefore can provide its own file merging. If we apply this to our scenario, Jade is to jade source files as V8 is to JavaScript source files. Since the jade language is procedural, it makes sense to allow this kind of feature where in JavaScript (which is object oriented) it doesn't.

Generating code vs file format

So my friend and I had an argument that we couldn't resolve. He is writing a general purpose web game library and a map editor. The map editor saves maps as XML, but the map editor can also load a Lua script that exports the details of the map into a Javascript file that looks something like this(he didn't want to post the code, so this is just a snippet with the names changed):
// This probably isn't valid code, but this is the idea of the code generator
(function() {
Game.Level1 = function (state) {
GameEngine.Group.call(this);
var Object0 = new Game.Lo(new GameEngine.Point(654 , 975.13), 15, state);
var slot123 = new GameEngine.TimeSlot(123); //Start
slot123.addEvent(new GameEngine.Event(Object0, "x", "current", 15, 200));
...
The idea is that the game library would just run this code instead of having to parse a map file and generate objects on the fly. And the Lua script in the map editor that generates the code could be modified by anyone who wanted to output code in a different language for a different library. (not limited to scripting languages).
I've never heard of this idea, usually i'd expect the map data to be in a standard format like JSON or XML and have the game library parse it.
So given that his library is written in javascript and his map can generate javascript to load files, what are the tradeoffs between running the generated code vs parsing JSON/XML and generating objects from that?

In a generic sense loading the metadata from another script, can give added flexibility to the script generator about how the data is sent, displayed etc. For example, you can have complete math expressions, conditionals etc as the part of the loaded script, that will be parsed and loaded seamlessly by the script parser(interpreter). It might be harder to do the same thing by using XML or JSON ( imagine sending an expression to do Miller Cylindrical Projection via XML, on the fly).
I've seen many situations where the app creates its own scripting language (MAXscript, MEL for Maya) to provide flexibility to the user. These are probably not analogous to your friend's usage of Java script to load metadata. But IMHO, it is a continuous spectrum, starting from metadata text files, to XML,JSON, expression parsing, to full fledged script parsing.
On the other hand, sending complicated scripts, will mean exposing part your code base. Also everyone knows what XML does, and you can expect a non-programmer to use/modify XML files. They are comfortable doing it. They may not be comfortable even reading what they think of as 'programs' or 'scripts'. I've seen this first hand in my company, where the artists were uneasy modify a Lua file. They were comfortable modifying the same information, if it was a simple text file. There might some security issues as well, but I'm really not that familiar with it, so I can't comment.