browser field for package.json #49
Conversation
When packaging this module for client side delivery, the browser field in package.json provides a hint to the package tool about which files to replace with client targeted counterparts.
|
Any comment on this? I submitted a similar patch to the 'ws' module websockets/ws@f7eb821 so it could be used when making client side packages. |
|
If you do decide to merge this, use the following commit instead: |
|
Any update on this issue? |
|
bump. If you don't want to accept this, please let me know and I will just stop checking in on it :) |
|
Are you no longer maintaining this project? There has been no activity for a while or response to the issues. |
|
I haven't worked on it in a while but I don't consider it dead. I'll work On Thu, Feb 28, 2013 at 1:38 PM, Roman Shtylman notifications@github.comwrote:
|
| @@ -24,4 +24,7 @@ | |||
| , "example": "./example" | |||
| } | |||
| , "main": "./lib/XMLHttpRequest.js" | |||
| , "browser": { | |||
| "./lib/XMLHttpRequest.js": "./lib/browser.js" | |||
There was a problem hiding this comment.
You don't need to define a file mapping, if you define the path of the browser-specific file, it will be used as entry point instead of the one for Node.js defined on "main", so this can be just "browser": "./lib/browser.js".
|
Why did you closed the pull request? Is there any other way I can get this to be integrated? |
|
I am no longer interested in this pull request. I needed it for engine.io-client to work with browserify. For that I am working with engine.io-client maintainers directly (since they have forked this repo) and have a simpler patch in my engine.io-client repo to make it browserify compatible. |
|
I see, it makes sense. I was interested on it for my job, maybe I'll need to find a solution in other place then... :-) |
When packaging this module for client side delivery, the browser field
in package.json provides a hint to the package tool about which files to
replace with client targeted counterparts.
This is currently supported by the following bundle tool:
https://github.com/shtylman/node-script
And I hope to get wider adoption of this practice. The goal is to provide a sensible way for module authors to make their packages cross environment. npm modules have the cool property of being able to work in server and client environments and this eases the burden on consumers of your module (like engine.io). Since your module aims to replicate the browser side api on the server, the browser portion simply provides the xml request object.