Stop Hand-Copying Java .properties Into Your JS Stack

Emre YARTAŞI — Sun, 03 May 2026 13:53:57 +0000

Stop Hand-Copying Java `.properties` Into Your JS Stack

If you have ever straddled a Java backend and a JavaScript frontend, you have probably stared at a .properties file and thought: I just need this as JSON—or as a module I can import.

You could transcribe keys by hand. You could write a one-off script that breaks on the first escaped newline. Or you could use a small tool that speaks the real Java properties format and hands you JavaScript, TypeScript, or JSON in a shape you control.

This post introduces @yartasdev/properties-to-js—a CLI and library that does exactly that, with options for nesting, flattening, key casing, and readable formatting.

Try it in the browser: Playground — paste .properties text, toggle flatten / casing, and see JSON, JS, or TS output without installing anything. (If you self-host docs, use your own /playground URL.)

Full docs: Documentation site (GitHub Pages from the same repo).

The problem in one sentence

.properties files are a lingua franca on the JVM; modern Node and browser code usually want structured JS or JSON. Bridging the two should be boring, reliable, and repeatable.

What is a `.properties` file, really?

Java’s classic configuration format looks deceptively simple:

Lines starting with # or ! are comments.
Each entry is typically key=value or key:value.
Values can span lines when you end a line with \.
Escape sequences like \n, \r, \t, and Unicode \uXXXX are part of the spec.

That last part matters. “Almost parsing” properties with a few split('=') lines works until it does not—until someone adds a multiline value, a colon in the right place, or an escape sequence your regex did not anticipate.

properties-to-js is built around treating the input as a real properties document, then emitting output your stack can consume without surprises.

What you get out of the box

Multiple output formats

You choose json, js, or ts via the --type / -t flag. The output file extension must match that type (for example -t js with output.js, -t ts with output.ts). The default type is json, so a plain output.json works without extra flags; for JavaScript or TypeScript modules, pass -t js or -t ts explicitly.

Nested structure by default

Keys with dot segments such as app.name or database.host naturally become nested objects:

app.name=MyApp
database.port=5432

becomes a tree:

{
  app: {
    name: 'MyApp',
  },
  database: {
    port: '5432',
  },
}

That mirrors how many teams think about configuration: sections and fields, not a flat bag of strings—unless you explicitly want the flat bag.

Optional flattening with a custom delimiter

Some systems, environment-variable conventions, or legacy integrations prefer a single level of keys. Enable flattening and pick a delimiter (for example _):

properties-to-js -i config.properties -o config.js -t js --flatted -d "_"

You might get app_name, database_port, and so on—predictable and easy to grep or map into other tools.

Case transformation for keys

Need uppercase or lowercase keys for consistency with APIs, env vars, or team style? Flags like --uppercase and --lowercase apply to the key material so you do not have to post-process with another script.

CLI and programmatic API

Use it as a global or npx-invoked CLI (properties-to-js when installed globally), or import { Converter } from '@yartasdev/properties-to-js' and call Converter.convertForFile (read a file, write a file) or Converter.convertForContent (string in, formatted string out) from your own build scripts, tests, or scaffolding tools.

Prettier-formatted output

Generated files are run through Prettier so diffs stay readable and your repository does not fill with accidental formatting noise every time someone regenerates config.

Installation and first run

Global install (gives you the properties-to-js command):

npm install -g @yartasdev/properties-to-js

Project dependency:

npm install @yartasdev/properties-to-js

No install, one-off run (note the scoped package name for npx):

npx @yartasdev/properties-to-js -i input.properties -o output.js -t js

If your shell mangles flags after npx, this pattern is your friend:

npx @yartasdev/properties-to-js -- -i input.properties -o output.js -t js

When the package is installed locally in a project, you can also run:

npx properties-to-js -i input.properties -o output.js -t js

JSON only (default type is json, matches .json):

npx @yartasdev/properties-to-js -i input.properties -o output.json

A concrete walkthrough

Imagine config.properties:

# Application Configuration
app.name=MyApp
app.version=1.0.0
app.debug=true

# Database Settings
database.host=localhost
database.port=5432
database.name=mydb

Default (nested) output is easy to read and maps cleanly to nested types in TypeScript if you emit .ts or wrap the object in your app:

properties-to-js -i config.properties -o config.json
# or
properties-to-js -i config.properties -o config.ts -t ts

Flattened with _:

properties-to-js -i config.properties -o config.js -t js --flatted -d "_"

You get one object with keys like app_name, database_host—useful when you must not assume nesting in downstream code.

Uppercase nested keys:

properties-to-js -i config.properties -o config.js -t js --uppercase

Sections become APP, DATABASE, and so on—handy when your style guide or integration expects shouting keys.

Programmatic usage

File → file

import { Converter } from '@yartasdev/properties-to-js';

await Converter.convertForFile({
  input: 'config.properties',
  output: 'config.js',
  type: 'js',
  flatted: false,
  uppercase: false,
  lowercase: false,
  delimiter: '.',
});

Paths are resolved under process.cwd(). Use type: 'json' | 'js' | 'ts' and an output path whose extension matches.

String → string (no filesystem)

Ideal for HTTP bodies, tests, or generated snippets:

import { Converter } from '@yartasdev/properties-to-js';

const source = 'app.name=Demo\napp.port=3000\n';

const moduleText = await Converter.convertForContent({
  content: source,
  type: 'ts',
  flatted: false,
  delimiter: '.',
  uppercase: false,
  lowercase: false,
});
// moduleText is a Prettier-formatted string (e.g. export default { ... };)

CLI reference (quick)

Option	Short	Description	Default
`--input`	`-i`	Path to the `.properties` file	Required
`--output`	`-o`	Output path (extension must match `--type`)	Required
`--type`	`-t`	`json`, `js`, or `ts`	`json`
`--delimiter`	`-d`	Delimiter used when keys are flattened	`.`
`--flatted`	`-f`	Flatten nested keys to a single level	`false`
`--uppercase`	`-u`	Uppercase keys	`false`
`--lowercase`	`-l`	Lowercase keys	`false`

When this tool shines

Backend and frontend share a source of truth. The JVM side keeps canonical .properties; your Vite, Next, or Node service generates checked-in or CI-built JS/JSON from the same file.
You are documenting or prototyping. Turn a small sample properties file into JSON for an OpenAPI example, a Storybook mock, or a README snippet without manual transcription errors. The Playground is perfect for quick experiments.
You want CI to own regeneration. A single command in GitHub Actions (or any runner) refreshes artifacts before tests or deploys—no “forgot to update the JSON” drift.
You value boring correctness. Comments, escapes, and multiline rules exist for a reason; a dedicated converter is less exciting than a bespoke five-line parser—and that is the point.

Honest scope

This tool solves properties → JS/TS/JSON with sensible structural options. It is not a full configuration platform: it does not merge profiles, resolve Spring placeholders, or replace your secrets manager. If your properties layer does heavy macro expansion, you may still need a JVM-side step—or a documented subset of keys—for the JS output to match production exactly.

Where it fits is the straightforward path: standard files, clear keys, predictable output.

Try it and shape it

Package: @yartasdev/properties-to-js on npm
Source and issues: github.com/yartasdev/properties-to-js
Playground: yartasdev.github.io/properties-to-js/playground
Docs: yartasdev.github.io/properties-to-js

If you hit an edge case—a surprising escape, a Unicode edge, a key pattern you need supported—open an issue with a minimal .properties sample. Real files beat abstract specs every time.

Takeaway

@yartasdev/properties-to-js exists so you spend less time being a human clipboard between JVM config and JS-friendly data. One CLI command (or one await Converter.convertForFile(...) / convertForContent(...)) gives you nested or flat structures, optional casing, and Prettier-clean output—so you can focus on the application, not on re-parsing = for the hundredth time.

If this sounds useful for your stack, install it, run it on a properties file you already have, or open the Playground with a paste from production (sanitized). If the generated module drops straight into your project, that is the whole story—and a good reason to star the repo or leave a note on dev.to about how you wired it in.

Cobertura Coverage Reports for CI/CD Pipelines: @yartasdev/cobertura-collect

Emre YARTAŞI — Thu, 05 Sep 2024 15:01:50 +0000

In CI/CD processes, test coverage is critical for measuring the quality of our software projects. However, in large projects where tests run in parallel across different modules or even on different machines, multiple Cobertura coverage files may be generated. In such cases, correctly collecting and merging these coverage reports into a single report becomes essential. This is where @yartasdev/cobertura-collect comes into play!

In this post, we'll explore how this npm package can be used in your CI/CD processes and how it merges multiple Cobertura reports into one file.

What is Cobertura?

Cobertura is a popular tool used to measure test coverage in software projects. Although it's commonly used for a lot of projects, it can be integrated with various programming languages and platforms. With Cobertura, you can see how much of your code is covered by each test, allowing you to analyze whether your tests sufficiently control your code. After the testing process, the overall test coverage results are stored in a file called cobertura-coverage.xml.

The Challenge of Merging Cobertura Coverage Files

In CI/CD pipelines, especially in microservice architectures or monorepo projects, tests are often run in parallel. This results in each test group generating its own independent coverage file. When you have multiple Cobertura coverage files, merging them manually into a comprehensive report is time-consuming and error-prone.

This is where @yartasdev/cobertura-collect comes in, merging all the Cobertura coverage files into one.

What is @yartasdev/cobertura-collect?

@yartasdev/cobertura-collect is an npm package that collects all Cobertura coverage files generated after running unit tests in a CI/CD pipeline and merges them into a single cobertura-coverage.xml file. This way, you can easily merge coverage reports from multiple modules into one file and present this combined report to CI/CD tools.

The package’s primary goals are:

To locate multiple cobertura-coverage.xml files.
To merge these files into one comprehensive coverage report.
To provide this merged report to CI/CD tools.

How Does the Package Work?
The package scans a specific directory or directories for Cobertura reports and merges them into a single file. For example, after running parallel test processes, you can use this package to merge all the cobertura-coverage.xml files into one.

Install the Package or use without Install

npm install @yartasdev/cobertura-collect -g

and run command

@yartasdev/cobertura-collect --print -o coverage/cobertura.xml -t coverage/**/cobertura-coverage.xml

or without install

npx @yartasdev/cobertura-collect --print -o coverage/cobertura.xml -t coverage/**/cobertura-coverage.xml

Example CI/CD Configuration

Unit-Test:
  stage: test
  image: node:${NODE_LTS}-alpine
  artifacts:
    when: always
    paths:
      - coverage/
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura.xml
  coverage: /Total Line Coverage:\s*(\d+(?:\.\d+)?)/
  before_script:
    - npm ci --cache .npm --prefer-offline --silent
  script:
    - npx nx run-many --target=test --configuration=ci --with-deps=false --projects=${PROJECTS} --parallel=6 --skip-nx-cache=false --verbose
  after_script:
    - npx @yartasdev/cobertura-collect --print -o coverage/cobertura.xml -t coverage/**/cobertura-coverage.xml
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

DEV Community: Emre YARTAŞI

Stop Hand-Copying Java .properties Into Your JS Stack