Lists

[SteveEmmerich]

This is more of question than and issue. Why did you choose not to support arrays of objects?

ex.

a: [5,4,3]

From what I can tell that would have to be: properties file:

a.0=5
a.1=4
a.2=3

output:

{
   a: {
      0:5,
      1:4,
      2:3
   }
}

Did I miss something?

[gagle]

I can't remember but I guess that's because you can use a "reviver" and parse the array with JSON.parse(). The values are casted into simple data types: number, boolean, undefined and null.

[gagle]

Now I remember... This syntax is not supported. This module is a .properties parser/stringifier which can be tweaked a bit, but parsing arrays like that is not supported and never will be.

[gagle]

I'm reconsidering this.

[alex-dow]

Given a JS object like this:

{
    foobar: [
        1,
        2,
        {
            key: 'value'
        }
    ]
}

This could easily be represented as:

foobar.0=1
foobar.1=2
foobar.2.key=value

As well, when parsing the file, one could do either:

{
    foobar: [1,2, {key: 'value'}]
}

or

{
    foobar: {
      0: 1,
      1: 2,
      2: { key: 'value' }
    }
}

And leave it up to the end user to decide which format, without having to write their own code to do either format.

https://github.com/alex-dow/icu-converter/blob/develop/src/writers/properties.js

I've written a basic JS object to properties file serializer there, but it is no where near as robust as this project, and I would to see this project handle nested datatypes and would be happy to help.

[derTobsch]

+1

[unrevised6419]

Do one thing and do it good. Why not to stick to default *.properties file format?
https://docs.oracle.com/cd/E23095_01/Platform.93/ATGProgGuide/html/s0204propertiesfileformat01.html