Hi Isaac,
> I'd recommend against using `ynpm` as the bin name, if only because I'm
an ex-yahoo, and `ynpm` sounds like Yahoo!'s fork of npm ;)
Isn't it a good thing that Yahoo won't be able to fork it under this name?
:)
Oh well... could you please suggest another name? I really so bad at naming
things...
Special keys are obviously ugly and generate too much noise. Besides,
originally I wanted to comment dependencies, so it can't be used anyway.
This was discussed over and over in the past. There was just one acceptable
solution (it's javascript instead of json which compiles to json when
publishing), but it's long gone now. :(
On Monday, June 24, 2013 7:37:07 PM UTC+4, Isaac Schlueter wrote:
>
> As with using CoffeeScript or Streamline to write your JavaScript, I
> have no problem with stuff like this for publishing to npm, as long as
> what ends up in the registry is "regular" json and javascript.
>
> I'd recommend against using `ynpm` as the bin name, if only because
> I'm an ex-yahoo, and `ynpm` sounds like Yahoo!'s fork of npm ;)
>
> You know, you CAN put comments in JSON by just using a key that isn't
> used for anything else. You can't put it in places (such as
> `dependencies`) where the key name is relevant information, of course.
> But at the top-level, this is fine:
>
> ```json
> { "name": "silverware-drawer"
> , "description": "BECAUSE ITS FULL OF FORKS GET IT!?"
> , "//":
> [ "This package.json file has a lot of forks on github"
> , "of things that I've forked and added patches to."
> , "I'll use the 'real' one once they're merged." ]
> , "//0": "Use an ID on multiple comments so they don't clobber"
> , "//1": {"this":"may","not":"be","ideal":"but","it":"works"}
> , "dependencies": { "foo":"my/fork" }
> }
> ```
>
>
> On Sun, Jun 23, 2013 at 11:59 AM, Alex Kocharin
> <[email protected]<javascript:>>
> wrote:
> >
> > When ynpm looks in a directory, it sees both files: real yaml file and a
> > "virtual" json file. So it packs both.
> >
> > It's very much intentional to ensure interoperability. We can use
> whatever
> > we want in development enviroment (coffee-script, package.yaml, other
> cool
> > stuff), but other people who will install a package from registry should
> > have as little issues with it as possible, which means compiled to
> > javascript modules and a package.json format.
> >
> >
> >
> > On Sunday, June 23, 2013 10:32:19 PM UTC+4, José F. Romaniello wrote:
> >>
> >> Do you pack/publish with package.yaml inside? How does that works with
> the
> >> npm service?
> >>
> >> El 23/06/2013 13:12, "Alex Kocharin" <[email protected]> escribió:
> >>>
> >>> Hi guys,
> >>>
> >>> TL;DR: I developed a package that monkey-patches npm to work with
> >>> package.yaml files without any json ever written to a disk. Hope it
> will be
> >>> useful.
> >>>
> >>> Published as npm module a month ago: https://npmjs.org/package/ynpm
> >>> (github: https://github.com/rlidwka/ynpm ), and I think it's ready to
> use
> >>> now.
> >>>
> >>> So, 6 months ago I asked in the mailing list about how to place
> comments
> >>> in package.json files (
> >>> https://groups.google.com/forum/?fromgroups#!topic/nodejs/NmL7jdeuw0M)
> >>> and
> >>> found no good answer for that. So for a long time I used package.js
> and a
> >>> Makefile to generate package.json. Rather ugly solution.
> >>>
> >>> We were developing a large and complex project, and I submitted dozens
> >>> pull requests to other packages. But until these PR were merged, I
> needed to
> >>> point these dependencies to my git repositories with these changes in
> place.
> >>> And THAT is why I desperately needed comments.
> >>>
> >>> So anyway... these are fundamental issues with JSON:
> >>>
> >>> 1. JSON have no comments, you can't comment out why did you put some
> >>> dependency, but not the other.
> >>> 2. JSON have no trailing comma. So you can't easily remove an item,
> add
> >>> an item or interchange two arbitrary lines in a list.
> >>> 3. JSON require ugly enquoting both keys and values in object.
> Javascript
> >>> require enquoting values only, and YAML doesn't require quotes in most
> >>> cases.
> >>>
> >>> JSON is designed to be written by computers, not humans. Humans could
> >>> read it easily, but maintaining JSON is a pain.
> >>>
> >>> Why YAML? Well, I would certainly not use XML. :) Anyway, YAML it's
> >>> easier to read and edit than all other widely known serialization
> formats,
> >>> and it solves all issues described above. I would fully support if
> Isaacs
> >>> returns package.js back to work (see 3y old github issue
> >>> https://github.com/isaacs/npm/issues/408 ), it would be good enough,
> but it
> >>> doesn't seem to happen.
> >>>
> >>> So, a lot of other people suggested to use YAML. That's the most
> recent
> >>> github issue https://github.com/isaacs/npm/issues/3336 , but there
> were
> >>> others.
> >>>
> >>> And there are some existing solutions to do that, for example
> npm-yaml:
> >>> https://npmjs.org/package/npm-yaml. But all these solutions just
> pre-compile
> >>> package.yaml before npm is executed. It's not good enough because json
> >>> remains written on the disk, and if npm modifies json, yaml remains
> >>> unmodified.
> >>>
> >>> So, I wrote a wrapper that replaces fs.* calls, so whenever npm reads
> >>> package.json file, and if there is a yaml file, we compile and return
> yaml
> >>> contents. If npm writes package.json, we change yaml instead.
> >>>
> >>> I made sure that all npm functionality is working with this new
> approach.
> >>> For example, in order to make `npm version` working I replaced
> >>> execFile("git", ["add", "package.json"]) with an appropriate
> substitute.
> >>> Other features required to replace readdir and file streams, and so
> on.
> >>>
> >>> If something is wrong with this approach or if something breaks beyond
> >>> fixing with future npm versions, I'll go for a fork. But as for now
> things
> >>> seem to work out nicely.
> >>>
> >>> PS: to guys who write YAML parsers: could you please write a module to
> >>> change one particular node in YAML file without rewriting the entire
> file?
> >>> Because it is the only thing here that ain't very good. I know it
> can't be
> >>> done in a general case, but it doesn't mean we shouldn't try.
> >>>
> >>> Regards,
> >>> alex
> >>>
> >>> --
> >>> --
> >>> 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 [email protected]
> >>>
> >>> To unsubscribe from this group, send email to
> >>> [email protected]
> >>>
> >>> 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 [email protected].
> >>>
> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>>
> >>>
> >
> > --
> > --
> > 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 [email protected]<javascript:>
> > To unsubscribe from this group, send email to
> > [email protected] <javascript:>
> > 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 [email protected] <javascript:>.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
--
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
