Meteor Support

[IstoraMandiri]

Seems like Meteor 1.3 ES6 import is having issues with this package, and is affecting other packages depending on keccakjs.

Reproduction:

meteor create keccak-test
cd keccak-test
meteor npm install
meteor npm install --save keccakjs

client/main.js

import keccakjs from 'keccakjs'

(same outcome with require)

---

Errors:
node console

Unable to resolve some modules:

  "build/Release/sha3" in /Users/chris/code/test/keccakjs-meteor-test/node_modules/keccakjs/node_modules/sha3/package.json (web.browser)

If you notice problems related to these missing modules, consider running:
  meteor npm install --save build
// running the above has no effect

browser console

Uncaught Error: Cannot find module 'sha3'
require @ install.js:78
meteorInstall.node_modules.keccakjs.index.js @ index.js:1
fileEvaluate @ install.js:141
require @ install.js:75
meteorInstall.client.main.js @ main.js:1
fileEvaluate @ install.js:141
require @ install.js:75
(anonymous function) @ app.js?hash=269ed68…:47

---

Related:

• Meteor 1.3 Integration Consensys/eth-lightwallet#87
• https://forums.meteor.com/t/meteor-1-3-browserify-potential-issue/20155

---

Attempting to debug...

EDIT: This is probably a Meteor bug. Seems like it's not respecting the browser field in package.json.

module.exports = require('browserify-sha3').SHA3Hash

'Fixes' the issue.

[IstoraMandiri]

Response from Meteor maintainer: meteor/meteor#6890 (comment)

• If the sha3 package specified its own browser-appropriate main module via the "browser" field of its package.json file, then keccakjs wouldn't have to make that decision on behalf of sha3.
• If keccakjs called require("browserify-sha3") in its client code rather than expecting require("sha3") to work as-is on the client, then it wouldn't have to rely on a magical property of package.json to disambiguate the two, and it would be clearer that those modules are actually not the same.

I'm not sure what the best course of action is here.

[axic]

If the sha3 package specified its own browser-appropriate main module via the "browser" field of its package.json file, then keccakjs wouldn't have to make that decision on behalf of sha3.

Well, that is the main point of this package to do that, because js-sha3 + node-sha3 don't seem to have any intention merging. node-sha3 also planned to move on to support the final SHA3 and not Keccak and when that happens I've planned to fork the C code into here. As a long term goal it was planned to include a native C and JS, Keccak-only implementation here. Patches welcome! :)

If keccakjs called require("browserify-sha3") in its client code rather than expecting require("sha3") to work as-is on the client, then it wouldn't have to rely on a magical property of package.json to disambiguate the two, and it would be clearer that those modules are actually not the same.

I don't know how that would work. I think he never checked what keccakjs does. Also this comment contradicts the previous point.

However, he also had this comment:

We do respect the "browser" field, but only when its value is a single string rather than an object containing multiple mappings, since the string case is much more common. See here for the relevant code.

So maybe changing package.json could work. Not sure what he means though to use only a string. Would you be able to play with that on your local installation?

[axic]

Also you probably will face the same issue with https://github.com/cryptocoinjs/secp256k1-node, because it uses the same package.json field. Does that work with meteor?

[benjamn]

If keccakjs called require("browserify-sha3") in its client code rather than expecting require("sha3") to work as-is on the client, then it wouldn't have to rely on a magical property of package.json to disambiguate the two, and it would be clearer that those modules are actually not the same.

I don't know how that would work. I think he never checked what keccakjs does. Also this comment contradicts the previous point.

I just meant that this code could dynamically decide which package to import, perhaps like so:

var sha3 = typeof window === "object"
  // When running in a browser environment, prefer browserify-sha3.
  ? require("browserify-sha3")
  // Split the identifier string to avoid bundling sha3 for the browser.
  : require("sha" + "3");

module.exports = sha3.SHA3Hash;

[axic]

thanks @benjamn - isn't the main purpose of the browser field in package.json to do that?

[axic]

@benjamn is the following approach supported by Meteor: #3?

[axic]

@hitchcott should be fixed with release 0.2.0, please let me know if there are any issues

[IstoraMandiri]

@axic Tested and working! Thank you on behalf of the Meteor community.

[axic]

@hitchcott curious, have you seen any issues with secp256k1 or scrypt.js (well, updated the latter)?

[Nexus7]

@axic actually we are having issues with secp256k1 in our meteor application... the weird thing is if we build our application with the --debug flag on then we don't see any problems after deployment. However if we build in production mode (without --debug) then we have issues/application hangs when we get to the secp256k1 functions... any ideas?

[retotrinkler]

same here