search

dfinity / agent-js

A collection of libraries and tools for building software around the Internet Computer, in JavaScript.
https://agent-js.icp.xyz
Apache License 2.0
154 stars 96 forks source link

Remove dependencies from third party libraries #222

Open hansl opened 3 years ago

hansl commented 3 years ago

A naïve webpack configuration will show that packages we use but don't bundle with needs to have a resolver fallback configuration, which is not very intuitive and impose configuration rules to applications. Instead, we should try to either bundle those libraries or (preferably) remove the dependencies if they're small and easy to get rid of.

Example:

image

gobengo commented 3 years ago

Yep, assert isn't truly necessary... It is nice that now the node assert stdlib API also has typescript type guards in it, such that assert.ok(var) actually does a type guard to hint tsc that after that line, var can't be falsy.

All that's a nice to have, though, so I don't insist on it... I do think it'd be cool if we had our own go-to 'assert' to use, similar to a go-to logger (with loglevels so we can leave some 'silly' (is this similar to what you meant by 'trace' hans, or did you mean tracing spans?) logs in there, and opt-into seeing them only when we really need to) we were chatting about.

hansl commented 3 years ago

Whatever solution we choose for this (it doesn't mean we have to get rid of assert) we should make sure the webpack config of the application does not require any fallback.

There are a lot of stuff coming from bip39, for example...

One solution is to clone the vendor or reimplement those in our own codebase. This is surprisingly easy in most cases.

Another is to have a UMD bundle, but that's not a good idea normally (because it cannot be tree shaken easily). The advantage here though would be to have a CDN canister to serve the agent, so people can just import('some-id.ic0.app/dfinity-agent.js') or something.

Another of course is to have peer dependencies for those, so that we at least advertise those dependencies directly to developers. I'm not a big fan, but might be a good transition step.

gobengo commented 3 years ago

Whatever solution we choose for this (it doesn't mean we have to get rid of assert) we should make sure the webpack config of the application does not require any fallback.

Do you mean, e.g. by not using 'overloaded' nodejs standard library module names like assert?

Instead, we should just link against https://npm.im/assert, but either as assert/ or a custom re-alias in the package.json so it's disambiguated: npm-assert?

That what you have in mind?

Everything else you're saying about vendoring or peerdeps +1