GithubHelp home page GithubHelp logo

Comments (6)

axic avatar axic commented on May 19, 2024

cc @wanderer @kumavis

from ethereumjs-util.

kumavis avatar kumavis commented on May 19, 2024

Here are my assumptions:

  • we're only exporting what we're using internally, nothing extra added on
  • the types exported are guaranteed to behave the way we expect to inject
  • different versions of the modules exported should still work, within reason
  • we're mostly doing this for people who havent figured out how empowering an automated dependency graph is -- its for producing bundles that such users can copy-paste in - and not having to say "oh and also go get a bundle for X and Y so you can use this properly"

Thats my thoughts. Not sure what change you are suggesting. Using the exported modules is optional as it works with your own versions, so I see no problem here. Though, do clarify your concerns.

from ethereumjs-util.

wanderer avatar wanderer commented on May 19, 2024

I understand the motivation behind that would be code size when processed via browserify. Is that really a problem?

No this is not a problem

Shouldn't browserify work out it as long as the modules in the dependency chain use the same version of the imports?

yep!

There are two reason for the current behavior

  1. as @kumavis to help some front-end devs that didn't use npm
  2. it make keeping all of the common ethereumjs-* deps versions in sync, easy.

from ethereumjs-util.

holgerd77 avatar holgerd77 commented on May 19, 2024

Will transfer this to organization (will delete ideas since this never caught off and it is already challenging to maintain one organizational repo).

from ethereumjs-util.

holgerd77 avatar holgerd77 commented on May 19, 2024

This is reduced to the question around the ethereumjs-util re-exports, will move the issue there.

from ethereumjs-util.

holgerd77 avatar holgerd77 commented on May 19, 2024

I think we have found a good balance here with dropping the cryptosecp256k1 reexport with v7 in #249 and keeping the BN.js and rlp reexports. Especially the BN.js reexport turned out to be very useful and somewhat needed after some experiences we made along the BN v4 to v5 switch which caused major incompatibilities when we partly switched some libraries here. The rlp reexport is not so strictly needed eventually and might be up for discussion, not really some urgency here though.

Will close.

from ethereumjs-util.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.