-
Notifications
You must be signed in to change notification settings - Fork 214
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
Consider putting releases on npmjs.org #31
Comments
Pull request with Node.js build system is very welcome. Inspiration can be taken from the OL3Cesium project which we co-developed: https://github.com/openlayers/ol3-cesium |
Cool, sure, if you're interested in going that direction I'm interested in PRing. :D |
Go for it ;-) We are keen to test and review your PR. |
What version are we at? How do I tell? |
I believe it's 2.1.0, based on what I see here: https://github.com/webglearth/webglearth2/releases |
I'll start with that. |
What commit is 2.1.0 at? |
Oh, I see, it's at c9e76ef. I've never used the release system on Github before (or on any site for that matter) . I usually just push a commit with a single change to the package.json version number with the commit description matching that number (e.g. "v1.2.3"), along with a tag of the same name. I suppose making release packages for those who use that feature might be nice to. |
Alright, here's the starting point: #34 |
Closing this and continuing there. |
This would be great so that the JavaScript community who doesn't use Java can easily manage the webglearth package as a dependency for their projects. The versions on npmjs would match the releases on GitHub. For practical reasons, you might like to publish the package as
webglearth
and include both the 1.x.x and 2.x.x versions on npmjs. It's easy tonpm install [email protected]
if needed.Since your build system is not JavaScript-based, you'd probably just put the single pre-built file in npmjs.org. But if you're curious, goog is available for Node: https://github.com/gatapia/nclosure, which means you could convert to Node's CommonJS
require()
syntax which would have two big benefits:require()
/module.export
toimport
/export
syntax would be straight forward. Browsers will be able to load entire libraries without needing to compile them into a single file (for development only of course, though with SPDY protocol multiple module files could be transmitted in a single stream equivalent to one large file, jspm does it already).The text was updated successfully, but these errors were encountered: