Smarter pkg

[jasonkarns]

We are presently using grunt.file.readJSON to read in package.json. Since file.readJSON isn't package.json-aware, the pkg object is a direct representation of the package.json file. I propose we use npm's read-package-json module to read the file. This way, the pkg object will be normalized according to how npm sees the package. This will allow npm defaults to shine through, and various short-form properties (like author/contributors) to be parsed and expanded.

[jasonkarns]

read-package-json is async but all of lineman's config loading is sync. Luckily, the normalization routines of read-package-json have been extracted into normalize-package-data, which is sync. So we can use it directly.

[searls]

What does this actually do for us right now? Aren't we just using the JSON file to collect the dependencies? Seems like we have much higher priority fish to fry

On Wed, Feb 19, 2014 at 3:04 PM, Jason Karns notifications@github.comwrote:

read-package-json is async but all of lineman's config loading is sync. Luckily, the normalization routines of read-package-json have been extracted into normalize-package-data, which is sync. So we can use it directly.

Reply to this email directly or view it on GitHubhttps://github.com/linemanjs/lineman/pull/209#issuecomment-35541815 .

[jasonkarns]

This change doesn't do anything for Lineman directly. The use case is for getting a normalized lineman.config.pkg object that's useful within our configs (generally used for interpolation with someKey: "<%= pkg.otherKey %>").

Primary benefit: so that the pkg object will be consistent regardless if the package.json author uses longform properties or the shortcuts. This means that the package.json itself can change forms while the lineman configs referencing pkg don't need to change.

Example: The following two package.json snippets are parsed by npm into the same JSON object.

{
  "author": "John Doe <john@example.com> (http://example.com/john)"
}

{
  "author": {
    "name": "John Doe",
    "email": "john@example.com",
    "url": "http://example.com/john"
  }
}

Presently, since we're just using grunt's readJSON helper, the value of pkg.author would differ based on the form used in package.json. (it would either be a string or an object). After this change, pkg.author would be the same object, regardless which form is used:

author: { name: "John Doe", email: "john@example.com", url: "http://example.com/john" }

[searls]

ah, that is interesting and clever. +meh until it does something for us, but I at least see what it accomplishes now

On Wed, Feb 19, 2014 at 4:18 PM, Jason Karns notifications@github.comwrote:

This change doesn't do anything for Lineman directly. The use case is for getting a normalized lineman.config.pkg object that's useful within our configs (generally used for interpolation with someKey: "<%= pkg.otherKey %>").

Primary benefit: so that the pkg object will be consistent regardless if the package.json author uses longform properties or the shortcuts. This means that the package.json itself can change forms while the lineman configs referencing pkg don't need to change.

Example: The following two package.json snippets are parsed by npm into the same JSON object.

{ "author": "John Doe john@example.com (http://example.com/john)"}

{ "author": { "name": "John Doe", "email": "john@example.com", "url": "http://example.com/john" }}

Presently, since we're just using grunt's readJSON helper, the value of pkg.author would differ based on the form used in package.json. (it would either be a string or an object). After this change, pkg.author would be the same object, regardless which form is used:

author: { name: "John Doe", email: "john@example.com", url: "http://example.com/john" }

Reply to this email directly or view it on GitHubhttps://github.com/linemanjs/lineman/pull/209#issuecomment-35549923 .

[jasonkarns]

The actual use-case that prompted this feature is for lineman-blog.

The lineman-blog configuration currently requires author, title, description, and url properties. Rather than duplicating this metadata in both the package.json and the application config, it would be much cleaner to use "<%= pkg.description %>" expansions. This works already for simple string properties but the naive implementation won't work for author.

With this change, lineman-blog could use <%= pkg.author.name %> as it's default configuration, and not have to worry about what format the package.json file actually uses (string vs expanded object).