jonschlinkert / normalize-pkg Goto Github PK

Steps to reproduce

1. Create a package.json file and set the repository to a shorthand GitHub "owner/repo" syntax:

   {
       "repository": "pdehaan/hapi-examples",
       "name": "normalize-pkg-test",
       "version": "1.0.0"
   }

2. Run $ normalize

Actual results

{
  "repository": {
    "type": "",
    "url": "pdehaan/hapi-examples"
  },
  "name": "normalize-pkg-test",
  "version": "1.0.0",
  /* snip... */
}

Not sure if the shorthand is valid when using the longer object form of repository, or if you want to default the type to "git" and use something like robertkowalski/github-url-from-username-repo to expand the URL to longer form URL.

Since this alters the package.json file quite a bit in some cases, not sure if you want to add some more debug output after rewriting the package.json file.

Relevant: https://github.com/gorillamania/package.json-validator

For example, after rewriting the package.json file, maybe just a brief few lines of output saying:

package.json file valid: false
errors:

• bugs field should have one of: email, url, mail, web
• licenses field should have url
• author field should have name

It would be nice to not have to factor in logic for all of the possible permutations of licenses out there. we can just implement logic for finding the right one in a given list.

Use configstore to populate missing fields with globally stored config values.

The CLI can prompt the user to ask if you want to use any of those fields.

This block is causing the repository value to be overwritten when it's already a string, which becomes an issue when the project name is scoped for use in npm.

Locally, I added a check to see if val is a string like the other if blocks and it seems to work. I'll submit a PR with tests when I have a chance but wanted to open this issue as a reminder.

Steps to reproduce:

1. $ touch index.js (optional)
2. $ npm init (finish wizard, this step probably is a bit inconsistent based on your current npm config setup.)
3. $ normalize

Actual results:

  "author": {
    "name": "Peter deHaan <[email protected]> (http://nodeexamples.com/)",
    "url": ""
  },

Expected results:

"author": {
  "name": "Peter deHaan",
  "url": "http://nodeexamples.com/",
  "email": "[email protected]"
},
...

Steps to reproduce:

1. $ echo "{}" > package.json
2. $ normalize
3. $ cat package.json

Actual results:

{
  "author": {
    "name": "",
    "url": ""
  },
  "repository": {
    "type": "",
    "url": ""
  },
  "bugs": {
    "url": ""
  },
  "licenses": [
    {
      "type": "",
      "url": ""
    }
  ],
  "keywords": []
}

Expected results:

Simmer down, bro!

Running the newly normalized package.json through http://package-json-validator.com gives the following output:

{
  "valid": false,
  "errors": [
    "Missing required field: name",
    "Missing required field: version",
    "bugs field should have one of: email, url, mail, web",
    "licenses field should have type",
    "licenses field should have url",
    "author field should have name",
    "repository field should have type",
    "repository field should have url"
  ],
  "warnings": [
    "Missing recommended field: description",
    "Missing recommended field: contributors"
  ],
  "recommendations": [
    "Missing optional field: homepage",
    "Missing optional field: dependencies",
    "Missing optional field: engines"
  ]
}

Currently I'm seeing some weird behavior in my Terminal where the closing } and my prompt are on the same line and it's weirding me out.

Similar to #7, but I think it'd be neat if normalize could detect that I don't have a homepage defined, then try and set a smart default if it can parse a GitHub URL from the repository (if it exists).

Relevant: https://github.com/visionmedia/node-github-url-from-git

Not sure how/if it should handle non-GitHub repo URIs since those may not always have a public HTTP site to point to.

More of an odd question rather than a bug...

I was looking through the inferLicenseURL() method and wasn't sure if you wanted to:

1. Add "MPL" license (I'm biased here): http://www.mozilla.org/MPL/
2. Search the local repo for a LICENSE file and link to that. This could be a bit mucky since it requires some OS filesystem stuff and then possibly trying to determine a fully qualified URL to said license.

I can split these out into separate GitHub issues if you want.

This will allow users and implementors to get what they want from this lib.

• make the logic in normalize-pkg more granular. e.g instead of adding flags for everything we can just expose an API for, say, normalizing from a string to an object, or vice versa
• move the opinions to the generator and subgenerators
• out of the box, the generator can create a new package.json using yo pkg
• If a package.json already exists, the generator will normalize it using some agreed upon defaults

Subgenerators

Subgenerators will make it easy to generate a package.json that follows whatever standards you want. E.g. to generate a package.json that strictly adheres to npm standards, you would use the strict subgenerator with yo pkg:strict.

... probably only works w/ GitHub URLs, but I think npm does this by default when creating a package.json file via npm init.

Before:

{
  "name": "pkg3",
  "version": "0.1.0-DEV",
  "description": "Foo baz",
  "repository": {
    "type": "git",
    "url": "[email protected]:jonschlinkert/normalize-pkg.git"
  },
  "licenses": [
    {
      "type": "GPL-2.0"
    }
  ]
}

After:

{
  "name": "pkg3",
  "version": "0.1.0-DEV",
  "description": "Foo baz",
  "repository": {
    "type": "git",
    "url": "[email protected]:jonschlinkert/normalize-pkg.git"
  },
  "licenses": [
    {
      "type": "GPL-2.0"
    }
  ],
  "author": {
    "name": "",
    "url": ""
  },
  "bugs": {
    "url": ""
  },
  "keywords": []
}

Expected

  "bugs": {
    "url": "https://github.com/jonschlinkert/normalize-pkg/issues/"
  },

This may help: https://github.com/visionmedia/node-github-url-from-git