New module xpkg

[Oleg Slobodskoi]

A you tired from writing separate .json files for every package manager?

Now you can write just one x-package.json file and generate from it files for any package manager. Every existing or upcoming manager is already supported. Also manager specific declarations are supported.

https://github.com/kof/node-xpkg

Best,

Oleg Slobodskoi

@oleg008

[Alex Kocharin]

 

1. Why JSON? This format was created for data serialization, and isn't suited for maintaining by humans.

2. Isn't it better to create a format every package manager would be capable of using natively? And compile out of it only as a temporary measure.

 

 

04.02.2014, 16:31, "Oleg Slobodskoi" <ole...@googlemail.com>:

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Oleg Slobodskoi]

Am 04.02.2014 um 13:46 schrieb Alex Kocharin <al...@kocharin.ru>:

 

1. Why JSON? This format was created for data serialization, and isn't suited for maintaining by humans.

We could support cjson (https://github.com/kof/node-cjson) or yml ... but I am not sure that json is an issue here. I personally had never a need to use something more expressive in this case, but I am open for it.

2. Isn't it better to create a format every package manager would be capable of using natively? And compile out of it only as a temporary measure.

If you are about json vs. yml etc.  ... I don't think package managers want to support all of them ...

[Alex Kocharin]

 

04.02.2014, 17:01, "Oleg Slobodskoi" <ole...@googlemail.com>:

Am 04.02.2014 um 13:46 schrieb Alex Kocharin <al...@kocharin.ru>:

 

1. Why JSON? This format was created for data serialization, and isn't suited for maintaining by humans.

 

We could support cjson (https://github.com/kof/node-cjson) or yml ... but I am not sure that json is an issue here. I personally had never a need to use something more expressive in this case, but I am open for it.

 

YAML of course. It's the most sensible general purpose format used for config files (unless your tool is able to change that config on the fly in which case the issue starts to be complicated).

 

2. Isn't it better to create a format every package manager would be capable of using natively? And compile out of it only as a temporary measure.

 

If you are about json vs. yml etc.  ... I don't think package managers want to support all of them ...

 

 

There were ideas about just one file with common definitions (something very much like Dart's one - http://pub.dartlang.org/doc/pubspec.html ), but it's extended so you can override any setting per package manager. Something like this:

 

---

# all package managers would see that name of a package is foobar ...

name: foobar

npm:

  # ... but npm would see it as node-foobar

  name: node-foobar

---

 

So you can override any setting this way.

 

Basically, it's a similar idea, but it's designed to be consumed by package managers, not intermediate tools.

 

The issue with one file per package manager is that you have multiple autogenerated files in the root of your git repository. And this really needs to be solved.

 

On the other hand the question is how to convince all (at least most of) package managers to switch to unified format... Anyway, I don't have a good solution to this. If I was, I'd be implementing one right now.

[Oleg Slobodskoi]

I have just added support for json5. This makes config more flexible f.e. no need for quotes for keys or comments ...

And you are right, this mess does exists just because http://wiki.commonjs.org/wiki/Packages/1.0 missed to specify how package manager specific declarations can be done.

Commonjs should solve this, all the managers will implement it very quickly, as its not hard.

Best,

Oleg

[Oleg Slobodskoi]

Just figured out that there is actually a place for manager specific stuff, its named "overlay" http://wiki.commonjs.org/wiki/Packages/1.1

Best,
Oleg Slobodskoi

http://www.facebook.com/oleg.slobodskoi
https://www.xing.com/profile/Oleg_Slobodskoi
https://twitter.com/oleg008
https://github.com/kof

[zladuric]

On Tuesday, February 4, 2014 2:43:25 PM UTC+1, Alex Kocharin wrote:

 

04.02.2014, 17:01, "Oleg Slobodskoi" <ole...@googlemail.com>:

Am 04.02.2014 um 13:46 schrieb Alex Kocharin <al...@kocharin.ru>:

 1. Why JSON? This format was created for data serialization, and isn't suited for maintaining by humans. 

We could support cjson (https://github.com/kof/node-cjson) or yml ... but I am not sure that json is an issue here. I personally had never a need to use something more expressive in this case, but I am open for it. 

YAML of course. It's the most sensible general purpose format used for config files (unless your tool is able to change that config on the fly in which case the issue starts to be complicated).

Out of curiosity, where can one get informed on these things?

Personally, I prefer json over yml. That way I never leave JavaScript way of thinking and encapsulating things. But I don't do all that much configuration, it's generally customizing pregenerated config files. I rarely produce packages, I mostly consume them.

[Alex Kocharin]

 

05.02.2014, 15:47, "zladuric" <zlad...@gmail.com>:

If you prefer json over yaml syntax, switch to json5 instead. It solves most of the json issues, keeping common syntax the same. I didn't mention that because it's not yet a standard, but I hope it'll be soon.

 

For config files there are exactly two issues with json:

 

1. doesn't support comments

2. doesn't support trailing commas

 

Here are a few examples I started to collect recently, you can see for yourself:

https://github.com/rlidwka/yapm/blob/master/changes/package-yaml.md#a-few-examples-why-you-should-not-use-packagejson

 

Apart from comments, there are quite a few quirks there. Did you know that JSON is not a subset of javascript? It creates a handful of issues as well. I love it how \t, \b and other escape characters are supported, but \v don't. And as everyone knows already, JSON isn't extendible and doesn't support dates. Remember escaping "\/" and that history of how ASP packed Dates? That was funny indeed.

 

There are good parts in there too. For example, LDJSON is generally a very good idea, and used wisely.

 

YAML has its share of issues of course. It doesn't support tabs for indentation (pretty stupid decision imho), has no block comments, and it's hard to update it from an application without changing it's formatting.

 

There is no ideal data format you know. Each one of them is used for different things. JSON is good for what it does (it's client-server data exchange). But unfortunately it's too easy to use (how do you like that you can do require('./something.json'), but require('./something.yaml') is officially deprecated?), so people misuse it quite widely. :(

 

 

[George Snelling]

Alex, 

We just say 

  config = require('./config.js')

where config.js exports a plain old javascript object.

I think this solves both beefs you have with json:  comments and trailing commas.

Admittedly this approach suffers the keyword problem:  if you name any of your config keys javascript reserved words you may die a puzzling death.  By convention we don't do that.

Perhaps yaml is more elegant and powerful, but exporting plain old javascript objects for config works fine for us.  

Regards, 

-George

[Gagle]

Would you store configuration data in a .java class? This is the same case.

http://stackoverflow.com/questions/18255226/storing-configuration-data-json

Use yaml, properties, ini, xml or your own format, but please, don't use json or javascript files... People like comments. If I remember correctly, someone said that json was choosen to save the metadata file (package.json) because there were no good alternatives.

[Alex Kocharin]

 

I believe reserved words issue was fixed in ES5. :)

 

$ node -e 'console.log(x={var: 1, function: 2, new: 3});console.log(x.var)'
{ var: 1, function: 2, new: 3 }
1

 

Yes, this approach solves all of the beefs I have with json. You can represent dates this way, and you can even include other files.

 

It's just that people want to avoid executable code in config files often. If you're fine with it, "config.js" is a good way to go.

 

 

 

 

06.02.2014, 11:17, "George Snelling" <geor...@gmail.com>:

[Oleg Slobodskoi]

json5 already added.

Best,
Oleg Slobodskoi

http://www.facebook.com/oleg.slobodskoi
https://www.xing.com/profile/Oleg_Slobodskoi
https://twitter.com/oleg008
https://github.com/kof

[Alex Kocharin]

Oleg,

 

Yeah, I saw that, thanks. But I'm still worrying about having to run xpkg every time. :)

 

Can it be changed to this?:

 

-----

{
    name: 'xpkg',
    description: 'Write x-package.json once and generate package.json, bower.json whatever.json.',
    version: '0.1.1',
    author: {
        name: 'Oleg Slobodskoi',
        email: 'ole...@gmail.com'
    },
    repository: {
        type: 'git',
        url: 'g...@github.com:kof/node-xpkg.git'
    },
    keywords: ['package', 'json', 'generator', 'bower', 'component',
        'package.json', 'bower.json', 'component.json', 'jquery.json'],
    licenses: [
        {
           type: 'MIT',
           url: 'http://www.opensource.org/licenses/mit-license.php'
        }
    ],
    overlay: {
        npm: {
            engines: {node: '>=0.8.0'},
            bin: {xpkg: './bin/xpkg.js'},
            dependencies: {
                json5: '0.2.0'
            }
        },
        xpkg: {
            npm: 'package.json'
        },
    },
}
-----

 

This way we have a chance that package managers would eventually support it without having to actually create those files.

 

No idea if it's actually going to happen, but we can dream, right? :)

 

 

07.02.2014, 03:20, "Oleg Slobodskoi" <ole...@googlemail.com>:

[Oleg Slobodskoi]

Started 2 discussions:

https://github.com/component/component/issues/475

https://github.com/bower/bower/issues/1092

doesn't looks like there will be a better solution in the near feature ...

Best,
Oleg Slobodskoi

http://www.facebook.com/oleg.slobodskoi
https://www.xing.com/profile/Oleg_Slobodskoi
https://twitter.com/oleg008
https://github.com/kof

[Oleg Slobodskoi]

done.

[Zlatko Đurić]

Config of Java class goes to XML. One of the most frequent complaints I get from Java devs is that they work with XML half the time, not Java.

I mean, separating this probably has justifications. But for me it's much easier to keep files in a config.js and export the config, like George explained.

Then again, I'm not working in large teams so this might not work for others.

--

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/qnBP3jF7Phg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Zlatko