Closed
Bug 935108
(nodemodules)
Opened 11 years ago
Closed 7 years ago
[tracking] Node Module Parity
Categories
(Add-on SDK Graveyard :: General, defect, P4)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: jsantell, Unassigned)
References
Details
No description provided.
Priority: -- → P4
Comment 1•11 years ago
|
||
The browserify project [1] has reimplemented a good share of Node APIs over browser (content) APIs [2]. It's mostly MIT-licenced (some code is borrowed from elsewhere and is BSD IIUC). I'm unclear on the level of compatibility
Might help a lot with this bug to just import what has been for browserify and/or contribute to this project for the Jetpack/Node compatibility layer.
[1] https://github.com/substack/node-browserify
[2] https://github.com/substack/browserify-handbook#builtins
Reporter | ||
Comment 2•11 years ago
|
||
This is mainly held up on whether we should land these into the SDK proper, or have a third-party collection of modules fulfilling these node needs, unfortunately
Comment 3•11 years ago
|
||
(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #2)
> This is mainly held up on whether we should land these into the SDK proper,
> or have a third-party collection of modules fulfilling these node needs,
> unfortunately
"unfortunately" refers to the decision not holding the bug up?
Where is this discussed?
Maybe maintain a third-party collection right now and re-evaluate if there is value to land this in SDK proper or whether people can live with npm-hosted shims? As long as the modules remain on npm, addons won't break. The other way around (ship in SDK then remove it later) is pretty much and impossible route.
Updated•10 years ago
|
Summary: Node Module Parity [meta] → [tracking] Node Module Parity
Reporter | ||
Updated•10 years ago
|
Assignee: jsantell → nobody
(In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #2)
> This is mainly held up on whether we should land these into the SDK proper,
> or have a third-party collection of modules fulfilling these node needs,
> unfortunately
This has to be done is sdk proper now, if it is going to get done at all, due to the changes that kev needham has forced on the community https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ (ie removing `require('chrome')`).
Comment 5•7 years ago
|
||
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•