Skip to content

update package xml as a prep for npm publish #130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 7, 2014
Merged

update package xml as a prep for npm publish #130

merged 2 commits into from
Nov 7, 2014

Conversation

jihoonl
Copy link
Member

@jihoonl jihoonl commented Nov 6, 2014

#127

I was intentionally renaming from roslibjs to roslib because I thought .js extension already implies it is javascript module. Would it be better to publish as roslibjs for consistency?

"name": "roslibjs",
"main": "./src/RosLibNode.js",
"name": "roslib",
"main": "./build/roslib.js",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will break node, main is for usage in nodejs and browersify is for compiling for the browser :)

@jihoonl
Copy link
Member Author

jihoonl commented Nov 6, 2014

Ah Since we are releasing roslib.js in build directory which include everything, I thought we should not release src directory in npm. They are duplicated information.

Also users should be able to use roslib like the following rather than digging through src directory.

var Ros = require('roslib').Ros;

To keep the similar use pattern as browser version introduced in our example

It was the reason main field points to build directory.

But I can see your point that it would break browserify process. Could we find a way to release just a built version(in build directory) without exposing src and not break browserify process?

If there is no alternate way, yeah we should include src in release package.

@megawac
Copy link
Contributor

megawac commented Nov 6, 2014

You only need to include the license and build files (see underscore.js)

We use various shims to mock things like browser compliant xml parsers for node. Not exposing the src directory would require a seperate nodejs build to include support for canvas, websockets, tcp connections, and various other stuff that isn't included in the browserified build.

@megawac
Copy link
Contributor

megawac commented Nov 6, 2014

Also, in regards to browserify usage of the src directory, exposing src allows people to make slimmer builds excluding things like tf client or math if they don't need them

@megawac
Copy link
Contributor

megawac commented Nov 6, 2014

Also users should be able to use roslib like the following rather than digging through src directory.
var Ros = require('roslib').Ros;

They can do that currently, leaving main: "src/roslibnode".

@jihoonl
Copy link
Member Author

jihoonl commented Nov 6, 2014

Ah.. maybe I am misunderstanding something. Could we gchat quickly?

@jihoonl
Copy link
Member Author

jihoonl commented Nov 6, 2014

After chatting with @megawac, it becomes clear to release src rather than build. PR will get updated.

@@ -0,0 +1,8 @@
src
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still has to be removed

@rctoris
Copy link
Contributor

rctoris commented Nov 6, 2014

👍 Thanks for taking lead on this @jihoonl , you know much more of the node side than I!

@jihoonl
Copy link
Member Author

jihoonl commented Nov 7, 2014

ready to go! merging and releasing.

jihoonl added a commit that referenced this pull request Nov 7, 2014
update package xml as a prep for npm publish
@jihoonl jihoonl merged commit c236330 into RobotWebTools:develop Nov 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants