You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Mar 5, 2025. It is now read-only.
There are transforms necessary as part of the build process. This is not a problem, but external browserify processes are not aware of them. Here is a simple fix.
original description below:
The way the tree trimming is being done with envify is preventing the module from being included and browserified externally. This means even modular projects using browserify must expose ethereum.js as a global.
here is xhr as an example of one of the environment specific code that is causing problems. And here is Bignum, both are problems for subtle reasons. E.g. in the case of BigNum even if you don't enter that if statement, the var BigNum now blocks the globally exposed BigNum.
There are a couple solutions:
Add the necessary transforms to the package.json, so that browserify knows to use those when processing your module.
Another way is to rethink why those things are there in the first place. Its a weird mismatch of expectations, where you expect globals to be present in one environment and not another. Why not always expect BigNum to be present? or never expect it to be present and provide your own.
This problem can be resolved without any breaking changes, it just requires a little communication so we can figure out a solution we're both comfortable with.
So to proceed, can you explain the rational for expecting globals like BigNum?
The text was updated successfully, but these errors were encountered:
EDIT:
There are transforms necessary as part of the build process. This is not a problem, but external browserify processes are not aware of them. Here is a simple fix.
original description below:
The way the tree trimming is being done with envify is preventing the module from being included and browserified externally. This means even modular projects using browserify must expose
ethereum.js
as a global.here is xhr as an example of one of the environment specific code that is causing problems. And here is Bignum, both are problems for subtle reasons. E.g. in the case of
BigNum
even if you don't enter that if statement, the var BigNum now blocks the globally exposed BigNum.There are a couple solutions:
Add the necessary transforms to the package.json, so that browserify knows to use those when processing your module.
Although specifying options is a little trickyhttps://github.com/substack/module-deps#transforms
Another way is to rethink why those things are there in the first place. Its a weird mismatch of expectations, where you expect globals to be present in one environment and not another. Why not always expect
BigNum
to be present? or never expect it to be present and provide your own.This problem can be resolved without any breaking changes, it just requires a little communication so we can figure out a solution we're both comfortable with.
So to proceed, can you explain the rational for expecting globals like BigNum?
The text was updated successfully, but these errors were encountered: