606597 - conform to CommonJS Packages and Modules specifications

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Myk Melez [:myk] [@mykmelez]]

The SDK should conform to the requirements, recommendations, and best practices of the CommonJS ratified Packages 1.0 specification, approved Modules 1.1.1 specification, and the parts of the draft Packages 1.1 specification that seem relatively settled.

This bug is a meta-bug to track discrete issues with such conformance.  Current known issues include bug 552841 and bug 591343.  Also note bug 591338, which is not a conformance issue per se but whose solution may impact conformance with Packages 1.1.

Note that conformance doesn't mean that we won't implement functionality unless it is specified by those specifications.  Indeed, our input into the development of future specifications will be greatly aided by experience implementing functionality we wish to provide that is not currently specified.  So we should implement the functionality we intend to provide our developer audience even if such functionality isn't currently addressed by a CommonJS spec.

Conformance also isn't an end in itself.  Rather, it is a means for improving interoperability in order to reduce the learning curve for developers adopting the SDK and enable module-sharing between our implementation and others.  So we should pursue it with great vigor, but not to the absolute exclusion of other goals, like usability and usefulness.

Brian has expressed a willingness to tackle CommonJS compatibility issues for
the SDK 0.10 release, so assigning this bug to him.

Comment 1

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I would recommend to play with [nodejs](http://nodejs.org/) and [npm](http://npmjs.org/). NPM is compliant with CommonJS while it has few extensions on top.

I do think compliance would benefit both of the projects jetpack and node. This also would mean that addon developers would be able to reuse lot's of libraries that already exist in npm registry http://npm.mape.me/ (there are lot's of crazy stuff already for example implementation of git in js :)

Comment 2

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 3

[Brian Warner [:warner :bwarner]]

Ok, I'm seeing four issues to pay attention to:

* "cfx run path/to/foo.js" (mentioned in bug 591343). I think this would be nice to have, but not a high priority.
* using the "id" key in package.json (mentioned in comment 8 and 9 of bug 552841). We use "id" to hold a cryptographic (hash-of-pubkey) addon identifier in the top-level package that defines an addon. I think this is ok, since these top-level packages are unlikely to ever be added to a "package registry", for whom the "id" and "type" keys are reserved.
* adding a "module" name to the module's initial namespace as a sibling of "require" and "exports" (mentioned in bug 591343). So far, the only claimed use of this that I've seen is to either do "require(module.id)" (and get back your own "exports" object), or to pass module.id to somebody else so they can require(it) and get your exports object. In either case, you can just pass your "exports" object directly.
* defining the module search order to allow both require("panel") (meaning addon-kit/panel) and require("foo") (meaning importing the "main" module from package foo). This is covered by bug 591338. I'll add it to the dependency list and add notes with our proposed solution over there.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Prospectively moving this to 1.0.

Brian: is there something here that needs to be done for 1.0?

Comment 5

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

I think with this change https://github.com/mozilla/addon-sdk/commit/658fb89ca4d3dc4a8cfb9616ae873e979a7f3955 inn we can mark it as fixed.