Research
Security News
Malicious npm Package Targets Solana Developers and Hijacks Funds
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
@ronin/compiler
Advanced tools
Compiles RONIN queries to SQL statements.
This package compiles RONIN queries to SQL statements.
You don't need to install this package explicitly, as it is already included in the RONIN client.
However, we would be excited to welcome your feature suggestions or bug fixes for the RONIN compiler. Read on to learn more about how to suggest changes.
To start contributing code, first make sure you have Bun installed, which is a JavaScript runtime.
Next, clone the repo and install its dependencies:
bun install
Once that's done, link the package to make it available to all of your local projects:
bun link
Inside your project, you can then run the following command, which is similar to bun add @ronin/compiler
or npm install @ronin/compiler
, except that it doesn't install @ronin/compiler
from npm, but instead uses your local clone of the package:
bun link @ronin/compiler
If your project is not yet compatible with Bun, feel free to replace all of the occurrences of the word bun
in the commands above with npm
instead.
You will just need to make sure that, once you create a pull request on the current repo, it will not contain a package-lock.json
file, which is usually generated by npm. Instead, we're using the bun.lockb
file for this purpose (locking sub dependencies to a certain version).
The programmatic API of the RONIN compiler looks like this:
import { Transaction } from '@ronin/compiler';
const transaction = new Transaction([
{
create: { model: { slug: 'account' } }
},
{
get: { accounts: null }
}
]);
transaction.statements;
// [{
// statement: 'SELECT * FROM "accounts"',
// params: [],
// returning: true,
// }]
transaction.models;
// [{
// name: 'Account',
// slug: 'account'
// ...
// }]
In total, the following types are being exported:
import type {
Query,
Model,
ModelField,
ModelIndex,
ModelTrigger,
ModelPreset,
Statement,
Result
} from '@ronin/compiler';
To fine-tune the behavior of the compiler, you can pass the following options:
new Transaction(queries, {
// A list of models that already existing inside the database.
models: [
{ slug: 'account' }
],
// Instead of returning an array of parameters for every statement (which allows for
// preventing SQL injections), all parameters are inlined directly into the SQL strings.
// This option should only be used if the generated SQL will be manually verified.
inlineParams: true
});
In order to be compatible with a wide range of projects, the source code of the compiler
repo needs to be compiled (transpiled) whenever you make changes to it. To automate this, you can keep this command running in your terminal:
bun run dev
Whenever you make a change to the source code, it will then automatically be transpiled again.
The interface of creating new Transaction
instances (thereby creating new transactions) was chosen in order to define the smallest workload unit that the compiler can operate on.
Just like for the database, a transaction for the compiler defines an atomic operation in which a list of queries can be executed serially, and where each query can rely on the changes made by a previous one. In order to facilitate this, a programmatic interface that clarifies the accumulation of in-memory state is required (class instances).
For example, if one query creates a new model, every query after it within the same transaction must be able to interact with the records of that model, or update the model itself, without roundtrips to the database, thereby requiring the accumulation of state while the transaction is being compiled.
Furthermore, since every database transaction causes a lock, the database is inherently not locked between the execution of multiple transactions, which could cause the compilation inputs (e.g. models) of a Transaction
to no longer be up-to-date. If the inputs have changed, a new Transaction
should therefore be created.
The RONIN compiler has 100% test coverage, which means that every single line of code is tested automatically, to ensure that any change to the source code doesn't cause a regression.
Before you create a pull request on the compiler
repo, it is therefore advised to run those tests in order to ensure everything works as expected:
# Run all tests
bun test
# Alternatively, run a single test
bun test -t 'your test name'
FAQs
Compiles RONIN queries to SQL statements.
The npm package @ronin/compiler receives a total of 1,580 weekly downloads. As such, @ronin/compiler popularity was classified as popular.
We found that @ronin/compiler demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
A malicious npm package targets Solana developers, rerouting funds in 2% of transactions to a hardcoded address.
Security News
Research
Socket researchers have discovered malicious npm packages targeting crypto developers, stealing credentials and wallet data using spyware delivered through typosquats of popular cryptographic libraries.
Security News
Socket's package search now displays weekly downloads for npm packages, helping developers quickly assess popularity and make more informed decisions.