search

kripken / ammo.js

Direct port of the Bullet physics engine to JavaScript using Emscripten
Other
4.13k stars 556 forks source link

npm? #116

Open joshuakfarrar opened 8 years ago

joshuakfarrar commented 8 years ago

Have you considered versioning ammo.js similarly to three.js and publishing it on npm?

kripken commented 8 years ago

I haven't had time to look into that myself, would be nice if someone else could.

red15 commented 8 years ago

This is currently already possible, just use npm install kripken/ammo.js

Look at the npm package.json description here: https://docs.npmjs.com/files/package.json#git-urls-as-dependencies

justingeeslin commented 7 years ago

The npm module doesn't contain a builds folder. Maybe it should? I think it would make it easier for folks using libraries for which ammo is a dependency.

ghost commented 7 years ago

If anyone is looking for the package on npm, it can be found at https://www.npmjs.com/package/ammo.js. However, @red15's comment provides a more recent version.

user28111999 commented 4 years ago

Any updates on this? Which package should I use?

ghost commented 4 years ago

@yunseok If you look at the package.json in this repository, it mentions ammo.js as the package name (without kripken/). Also, kripken/ammo.js does not exist on NPM as far as I can tell, so you should be safe with just npm i ammo.js.

Vaggal commented 4 years ago

@yunseok If you look at the package.json in this repository, it mentions ammo.js as the package name (without kripken/). Also, kripken/ammo.js does not exist on NPM as far as I can tell, so you should be safe with just npm i ammo.js.

It is correct that you get the package with the way that describes but it will be an old version since the releases were based on a fork which has not been updated for 4 years. In order to get the most recent version, using the github url is the way to go.

Couldn't new releases get published either in npm or here? I think this would make it much easier for users of the library to keep track of the version that they use.

moreirayokoyama commented 4 years ago

Hey, folks... for opensource projects such as this, it is possible to set a continuous deployment such as travis-ci or circle-ci for free, which could help to publish updated versions of this package without effort... I can try to help, but I can't do it myself unless based in a fork, and I really think the ideal would be do this based on the official repository.

kripken commented 4 years ago

I believe @ianpurvis was looking into CI?

ianpurvis commented 4 years ago

Automated releases to npm would be very cool! We recently added CI via GitHub workflows... check out the config at .github/workflows/continuous.yml. If you make changes to that file in a pull request, they will be reflected your PR builds. Just make sure to enable GitHub Actions in your own fork and do the heavy dev there to keep the noise out of kripken's repo. And before going full auto, I think it would be good to do an old-skool release.

Btw, if continuous delivery works better than continuous deployment here, you can just put a manual trigger on that part of the workflow and kripken can do the releases via a button in the GitHub UI. 👍

Symbitic commented 4 years ago

If you are interested, one alternative to GitHub UI might be tools like standard-version or semantic-release. By using formatted git commit messages like feat: add calculateInVacuum or fix: issue #12345, those tools can automatically determine the next version number, automatically set the new version in package.json, generate a CHANGELOG, create a git tag with the new release, and then upload the release to GitHub releases and NPM.

standard-version is simpler but requires manually running commands outside CI/CD. semantic-release requires more setup but integrates with CI very well.

ianpurvis commented 4 years ago

Also cool... I have gotten in the habit of using semantic PR names, though I don't always do it at the commit level. This bot is handy. @moreirayokoyama @Symbitic Maybe you guys can collaborate?

What's the best way to maximize stability and control npm jitter with auto releases? Use a release branch that can receive larger PRs from master?

Symbitic commented 3 years ago

@ianpurvis @kripken @moreirayokoyama Sorry for taking so long to get back. If you are still interested in this, then I think I have the solution.

The big question is: are you willing to use the Conventional Commit style? That's the deciding factor. There are tools to help enforce the format, such as commitlint and probot to verify the messages before every git commit.

I think the best tool might be standard-version. The workflow would be something like:

  1. Add commits with messages following the conventional commit format.
  2. When ready for a new release, one of the project maintainers will run npm run release (which will run standard-version) locally.
  3. Standard-version will increment the version number, update a changelog, and (most importantly) create a new tag.
  4. When done, push the changes upstream.
  5. GitHub actions can be configured to only run on tags. So we could have a GitHub action that would run the tests, then publish to NPM.

That's the best workflow I can think of. I can get everything set up except for the publish to NPM part (since that requires an NPM token). Would you be interested?

One added bonus of using NPM: Emscripten can also generate MJS files. By adding "module": "builds/ammo.mjs" to package.json, bundlers like webpack or rollup will automatically prefer that version over the regular web-compatible one. That's probably a far better way of reducing application size than editing the IDL.