Project Status

[bwbb]

@alerque, @ralaska, @renehamburger, @benemanuel, @Adventech, @RyanQuey, or any others:
I would like to create a new repository incorporating all of your changes, and providing a place for updates going forward. I have been wanting to make several updates, but it's frustrating not being able to put them in a central location.

Do any of you have any interest in contributing, or at least helping maintain and reviewing PRs?
It would be really nice to add support for ES Modules, and eventually re-write in TypeScript.

Please LMK if any of you are interested in contributing or supporting!

[alerque]

I'd be interested. Do we have any idea what's become of @openbibleinfo?

I've always appreciated this project and still to this day use it in production every week (built into my CaSILE book publishing workflow, and elsewhere), but at the same time I've always found the project very frustrating to contribute to because development isn't done in the open in Git (Git is basically only a release publication mechanism) and contributions are pulled infrequently and then it isn't always clear what got integrated vs. what did not.

Actually I would be far more interested in starting a new project. It fact I'll spear head such a thing especially if anybody else wants to join forces:

• Write a Rust library crate to handle the actual parsing / matching / formatting.
• Make a Rust binary crate with cli wrapper around the library with basic reference manipulation functions for use in the shell
• Wrap the library crate in other language modules to provide native APIs in Lua, Python, JavaScript/Typescript, and possibly PHP or others. This way any major language with WASM or C module loading capabilities could easily access the same functionality.

I've already done some projects that function a bit like this with a Rust core and generating modules for other and am pretty sure it wouldn't be too hard to setup. I've done Lua and Python already, and am pretty confident JS/Node libraries can be setup the same way.

I'd envision either directly being able to ingest the language data from this project as-is, or writing some tool to covert it to some other easy to edit/update representation.

How does that strike you?

[bwbb]

Do we have any idea what's become of @openbibleinfo?

Good question...

Yes exactly, I thought it would be great to capture all the work done so far into a published NPM project, that is maintained.
For the time being, I have some urgent quick fixes needed, so what I will do is create a new repo with my changes, and try to capture as much of the changes done by the above tagged contributors as possible. I wanted to setup a single place for maintenance and visibility in the community going forward.

For the slightly longer term, I think your vision makes a sense, although I wish I knew Rust, and had time to contribute to a re-write. If you have the time to to work on this, I'd be happy to help in any way I can with the TS/JS side, in my spare time.

[alerque]

For the short term work you describe I highly recommend working from a fork of this project so that it is easier to integrate anything else that comes along in PRs here. Also most of my work is integrated here already and I don't see too many other bits hanging out at loose ends. But still working from a fork of this would be the easiest way to manage it until such a time as it decided to take a completely different direction that would be incompatible with any other contributions or changes that @openbibleinfo comes up with there (they do seem to still be periodically active).

[renehamburger]

Thanks for your initiative to restart & extend this library, @bwbb & @alerque! I'm also relying on it in my bible reference tagger https://github.com/renehamburger/blinx.js and have created my own fork to adjust just a few of its shortcomings.

I'd really love to support this, but I'm afraid I barely have any time available for open source projects at the moment.

When it comes to the rewriting the library, I feel that rewriting it in Rust might be a hindrance to its usage in the browser. While it is possible to execute binary (WebAssembly) code in the browser, it reduces browser compatibility somewhat and may add unnecessary obstacles to its adoption. Rust is a fantastic new language for high performance code, but did you encounter performance bottlenecks with the current version of this library, @alerque?

If you decide to stick within the JavaScript-ecosystem, moving away from Coffeescript is definitely the right decision, as it isn't popular anymore. I would also choose TypeScript then, but as this project isn't huge, pure JavaScript would also work.

One aspect of this project I would definitely recommend to change is it's dynamic testing strategy. Generating both the code and the tests dynamically really begs the question of how many of these tests are meaningful. Even the dynamic code generation is something I feel adds unnecessary complication.

[bwbb]

Hi @alerque I'm beginning work to incorporate everyone's changes into a single repository, and I'd like to include your work with the Turkish language. Unfortunately there are a lot of conflicts, and I'm not familiar enough with the work to to do a proper merge. Would you be able to update your repository with the latest changes from here, so I can do a clean merge?

[bwbb]

Update:
Alright, I've included changes from as many of the forks as possible, and also made some additional fixes for the Russian language, and put them in this fork, which is also published to NPM as bible-ref-parse.

The package can be imported for ESM as follows:

import * as parserModule from 'bible-ref-parse/js/en_bcv_parser';
const parser = new parserModule.bcv_parser();

@openbibleinfo I've created a PR back to this main repo incorporating all changes here, if you get a chance to review and merge.

If there is time in the future, I would like to include @alerque's changes, and I might branch off and work on an updated version in TypeScript, and explore abstracting the parser as much as possible (depending on the needs for the PEG.js grammar) so that the languages can be treated as config data to a single parser, rather than entirely separate parsers.

[openbibleinfo]

@renehamburger I personally find the automated test generation very helpful for debugging a language. It consistently identifies problems either in the parser or in the language definition; identifying accidentally duplicated book names is especially helpful.

@alerque I see this repo as more of a series of finished products for developers to use in their projects rather than as a series of works in progress. In other words, I'm optimizing for end usage rather than for contributions. That's not to say that contributions aren't welcome, but they're not my priority from a public-facing standpoint.

@bwbb Version 3 of this parser replaces Coffeescript with Typescript. It's not the best Typescript in the world at this point. The ES Modules version of the code in (/es) abstracts the parser similarly to how you describe, where a language is provided as a configuration option.