Support for importing an existing package.json with arbitrary fields …

[sterpe]

…during gx init.

I'm principally a JS guy, which will probably be obvious :) but this is an attempt at this.

I've modified a few of the PackageBase properties to correspond 1-1 with npm fields where it made sense to overlap -- keywords, bugs, repository.

I added a property PackageBase.NonGxFields which is just a map[string]interface{} of any pre-existing package.json.

The problem I ran into, that I couldn't solve in the way I would want to in Go is, treating the Package struct created in a gx-* tool as {gxutils/pkgfile.go}.Package. I guess there's no way to 'typeassert' in a really generic way in Go? Anway, I hackily solved the problem by having the gx-* tool pass the ref to a map[string]interface{} of the original package.json to gx.SavePackageFile as a third arg.

I made some very minor modification to the gx-js tool here to support that change: sterpe/gx-js#1

There's probably some way better Go-way to do it.

[whyrusleeping]

wow. this is really annoying to do nicely in go... i'm working on a way of making it play nicely... its kinda ugly so far but i'll probably still push it soon so you can mess around with it.

[whyrusleeping]

Try out the code in #59 It allows extra fields to exist in the package.json without them being clobbered. Its a step in the right direction (this is annoying to do in go for some reason :/ )

[sterpe]

Will check it out.

[whyrusleeping]

code from #59 is in master.

[sterpe]

Cool. Ive been slammed last couple of days. Will try it out soon

[sterpe]

@whyrusleeping, Finally had a chance to play with this still having the issue of gx initing on a dir with a previously existing package.json, i.e.,:

21:42:03 [7780\1:master] <sterpe@macbook-pro:~/documents/js/github.com/sterpe/gx-quux.js> $ gx init --lang=js
initializing package gx-quux.js...
ERROR: init error: package file already exists in working dir
21:45:49 [7781\1:master] <sterpe@macbook-pro:~/documents/js/github.com/sterpe/gx-quux.js> $ 

[sterpe]

If I do:

gx init; npm init; 

I get something like this:

{
  "name": "gx-quux.js",
  "author": "sterpe",
  "version": "0.0.0",
  "language": "js",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/sterpe/gx-quux.js/issues"
  },
  "gxVersion": "0.4.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/sterpe/gx-quux.js.git"
  },
  "keywords": [
    "quux",
    "gx-js"
  ],
  "homepage": "https://github.com/sterpe/gx-quux.js#readme"
}

But then doing gx version 0.4.9 from the unit test throws this error:

21:54:32 [7788\0:master] <sterpe@macbook-pro:~/documents/js/github.com/sterpe/gx-quux.js> $ gx version 0.4.9
ERROR: json: cannot unmarshal object into Go value of type string 

This appears to be caused by keywords and the change in #57 to bugs both of which are also npm fields but are {objects} in npm parlance.

[whyrusleeping]

@sterpe okay, so we either need to make gx okay with having init be called if an npm package.json (or maybe any non-gx package.json) already exists. This could be done through a flag, like gx init --extend-pkg (obviously with more thought put into the name of the flag) or we could just have it check for gx specific fields in the existing package.json and if they arent there, add them and call that the init process.

As for the keywords and bugs fields, i'm totally okay changing those to objects so that they mesh well with npm stuff.

[whyrusleeping]

I pushed a commit that fixes the keywords and bugs fields.

[sterpe]

Yeah, the only thing i was thinking was long term we don't want to have to be chasing compatibility with npm (or whoever else) on package.json spec. Does it make sense to just do package-gx.json or similar to avoid the overlap entirely?

Sent from my iPhone

On Apr 6, 2016, at 10:15 PM, Jeromy Johnson notifications@github.com wrote:

@sterpe okay, so we either need to make gx okay with having init be called if an npm package.json (or maybe any non-gx package.json) already exists. This could be done through a flag, like gx init --extend-pkg (obviously with more thought put into the name of the flag) or we could just have it check for gx specific fields in the existing package.json and if they arent there, add them and call that the init process.

As for the keywords and bugs fields, i'm totally okay changing those to objects so that they mesh well with npm stuff.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[sterpe]

Or namespace all gx fields under gx property object

Sent from my iPhone

On Apr 7, 2016, at 8:18 AM, srterpe@gmail.com wrote:

Yeah, the only thing i was thinking was long term we don't want to have to be chasing compatibility with npm (or whoever else) on package.json spec. Does it make sense to just do package-gx.json or similar to avoid the overlap entirely?

Sent from my iPhone

On Apr 6, 2016, at 10:15 PM, Jeromy Johnson notifications@github.com wrote:

@sterpe okay, so we either need to make gx okay with having init be called if an npm package.json (or maybe any non-gx package.json) already exists. This could be done through a flag, like gx init --extend-pkg (obviously with more thought put into the name of the flag) or we could just have it check for gx specific fields in the existing package.json and if they arent there, add them and call that the init process.

As for the keywords and bugs fields, i'm totally okay changing those to objects so that they mesh well with npm stuff.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[sterpe]

@whyrusleeping I was just looking at the npm docs for package.json I guess "bugs" can actually be either:

"bugs": { "url" : "..../issues", "email": "...@foo.com", /* etc */}  

or, and I think you will love this :)

"bugs": "..../issues"