If an add-on has a ./package.json file, then type should be "jetpack". We should wrap this logic in a pref and turn it off by default, at some point when other pieces land we can turn this on.

Dave can you take this one for me?

It will be loadManifestFromJSON that sets the addon type so I'd say that this is just a part of bug 1040238

(In reply to Erik Vold [:erikvold] [:ztatic] from comment #3) > Created attachment 8475268 [details] > Link to Github pull-request: https://github.com/mozilla/gecko-dev/pull/44 https://tbpl.mozilla.org/?tree=Try&rev=02397be0a8b1

Comment on attachment 8475268 [details] Link to Github pull-request: https://github.com/mozilla/gecko-dev/pull/44 This looks more complex than it needs to be and doesn't seem to actually support reading package.json

(In reply to Dave Townsend [:mossop] from comment #5) > Comment on attachment 8475268 [details] > Link to Github pull-request: https://github.com/mozilla/gecko-dev/pull/44 > > This looks more complex than it needs to be and doesn't seem to actually > support reading package.json It sounds like you'd like to have bug 1040238 completed with this work so I'm making this a duplicate.

(In reply to Erik Vold [:erikvold] [:ztatic] from comment #6) > (In reply to Dave Townsend [:mossop] from comment #5) > > Comment on attachment 8475268 [details] > > Link to Github pull-request: https://github.com/mozilla/gecko-dev/pull/44 > > > > This looks more complex than it needs to be and doesn't seem to actually > > support reading package.json > > It sounds like you'd like to have bug 1040238 completed with this work so > I'm making this a duplicate. Mostly I expect patches to not leave the tree in a broken state unless it's explicitly called out that they depend on something else to land at the same time. Apparently gecko-dev isn't for reviewing so please attach patches to bugzilla in the future and we can review them here.

Also in response to your github comment: I agree where we can separating out large chunks of related code is good. In this case though we're talking about a single function that is called just twice. In each place we can replace the function call by maybe three lines of code. Modules have costs in that they can be more expensive to load, take up more space and make the functionality opaque, the benefits aren't worth that cost here. As far as unit tests go, you'll need to be adding tests of native add-ons as it is, that will provide more than enough testing of the functionality that this module provides anyway.