Skip to content
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

Add browserify compatibility #643

Merged
merged 2 commits into from
Nov 28, 2018
Merged

Add browserify compatibility #643

merged 2 commits into from
Nov 28, 2018

Conversation

danfinlay
Copy link
Contributor

Fixed dependencies and added documentation for easier inclusion in a browserify or webpack project.

Moves `@trust/crypto` and `text-encoding` into the package.json's
dependencies, since it depends on them. Allows for importing SEA using
browserify or node.

Fixes amark#642
@amark
Copy link
Owner

amark commented Nov 24, 2018

docs are great, will definitely snag that.

For dependency, we'd need to add node-webcrypto-ossl also, but the community had moved these to devDependencies before (see the issue you opened). I'm also fine moving them back to dependencies... would just like to hear your thoughts on what the right balance between install difficulty vs. opt-in install use... either way, docs calling this out exactly addresses it. THANK YOU.

...will be back after Thanksgiving stuff.

@kumavis
Copy link
Contributor

kumavis commented Nov 24, 2018

Fixes #642

@amark
Copy link
Owner

amark commented Nov 28, 2018

@danfinlay @kumavis just got back from SD for Thanksgiving. Sick, but trying to catch up on stuff now.

I'll pull this (and add ossl to the dependency list, since that is also necessary for SEA) in the next 24 or 48 hours if nobody else objects.

I am curious your thoughts about hardcoding these optional dependencies, especially after the NPM debacle that happened the other day - are you still of the same mindset after that?

Having SEA be its own module is very interesting to me - I'd want other projects to already use it (maybe this MetaMask integration will pave the way???) first and then donate it to some independent /foundation to house it. I think it'll be very important for future dApps, integrations, plugins, etc. to standardize around.

@mitra42
Copy link

mitra42 commented Nov 28, 2018

What NPM debacle are you refering to ? None of the problems NPM has from time to time change the need for packages that depend on something else to require that code !

@amark
Copy link
Owner

amark commented Nov 28, 2018

Pulling!

@mitra42 trying to be clear: these are shims, they are not dependencies. Are they needed in certain contexts, yes. Does that make it obvious they should add 10X the overhead to installing GUN? I don't think so.

Also, in a local commit I have added to SEA an option to have it throw errors, per your request (note: It won't be default, as it causes NodeJS to crash unless you try/catch it). Hopefully this'll come out in the next release (haven't had much time to code lately though, not sure when it'll be going out). Hope this will make you happy. :)

@amark amark merged commit 8483ad6 into amark:master Nov 28, 2018
@amark
Copy link
Owner

amark commented Nov 29, 2018

Okay this got bumped up again, should go out in next NPM release ... probably after back from trip.

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.

4 participants