index.js

/**package
 * { "name": "npm-test-single-file"
 * , "main": "index.js"
 * , "version": "1.2.3"
 * , "description":"No package.json in sight!"
 * , "dependencies": { "minimatch": "*" }
 * }
 **/

module.exports = "I'm just a lonely index, naked as the day I was born."

<3

The comment must start with /**package and end with **/. The leading * characters are removed, because I sort of like the way they look, and it's too much trouble to try to figure out how to make vim not automatically put them there when a comment starts with /**, but they're not required.

Whitespace is irrelevant, but it must be valid JSON, minus the leading * chars.

@isaacs We plan to do something very similar for jetpack. But instead of comments we use trick with a label:

meta: ({
  "name": "npm-test-single-file",
  "main": "index.js",
  "version": "1.2.3",
  "description":"No package.json in sight!"
  "dependencies": { "minimatch": "*" }
})

module.exports = "I'm just a lonely index, naked as the day I was born."

This way editor does the syntax highlighting of metadata & outlines errors if there are some early in the process.

@Gozala have you seen this: https://github.com/labeledmodules/labeled-modules-spec/wiki

P.S It's also easy to parse: /^meta\:\s*\(\{[\s\S]*\}\)\s*;{0,1}\s*\n/

@Gozala There's a reason that it's JSON and not JavaScript.

meta: new WTF()
function WTF () { require("pleasekillmenow") }

@isaacs it looks like @Gozala's is pure JSON too, and can be statically extracted and parsed all the same -- it has the added advantage of being syntax-highlighter, but the possible disadvantage of appearing to be part of the code instead of pure metadata

either way, pretty neat idea

It's JSON in our case as well, we parse JSON from meta: (<JSON>).

Also one might write following as well

/**package
 * new function WTF () { require("pleasekillmenow") }
 **/

but it does not means it should work

@deanlandolt I think https://github.com/labeledmodules/labeled-modules-spec/wiki is interesting, but probably it's to late for the game.

@Gozala Oh, I see, so even though it's defined inline as a JavaScript object, you're still parsing it as JSON?

there's obviously the small perf hit for having to parse it as js before json but that's probably close to nil

i bet the unfamiliar syntax will throw some people off but it's still pretty hot

@issacs

Yeah, that's a contract. We though the fact that it's labeled and not referenced was obvious enough to make people thing of it as JSON typed metadata and not a regular object.

@isaacs BTW I have been planing to implement support for single file modules for npm but in slightly diff way:

meta: ({
  name: 'blabla',
  version: '0.0.1'
})

var streamer = require('!raw.github.com/Gozala/streamer/experimental/promise/core');
// more code

where on install of this module npm will go ahead and place

https://raw.github.com/Gozala/streamer/experimental/promise/core.js into

node_modules/!raw.github.com/Gozala/streamer/experimental/promise/core.js

Would you accept pull request with such a change ?

No, I dont' think it's a good idea for npm to be parsing out require() statements. Pulling out metadata is one thing, but what you'er suggesting is much more involved.

You can just list your dependencies in the metadata.

@isaacs

Yeah makes sense. In fact currently I do this via post-install script which works fine but is kind of painful to have to specify both dependency and scripts per each package. Would be nice if npm had a plugin system for cases like this similar to lein plugins