-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Conversation
Your Render PR Server URL is https://web3js-docs-pr-5393.onrender.com. Follow its progress at https://dashboard.render.com/static/srv-cc6n52pgp3jv8lhb6gb0. |
…e/web3.js into wyatt/4.x/5091-chainlink-plugin
This pull request introduces 1 alert when merging d0d388b into aeceed2 - view on LGTM.com new alerts:
|
This pull request introduces 1 alert when merging db296ff into aeceed2 - view on LGTM.com new alerts:
|
"ts-jest": "^28.0.7", | ||
"typescript": "^4.7.4" | ||
}, | ||
"dependencies": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should those be peerDependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure they can be since the plugin is actually importing the packages?
import { ContractAbi } from 'web3-eth-abi';
import Contract from 'web3-eth-contract';
import { Web3PluginBase } from 'web3-core';
import { Address, Web3APISpec } from 'web3-types';
// @ts-expect-error 'Web3' is declared but its value is never read.
import { Web3 } from 'web3/dist/web3';
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't really matter. The only difference here is if you put peer dependencies and set a broad range like ">=4.0.0 < 5" it will warn the user if he is supplying an invalid version, otherwise it would use his version. On the other hand, if you leave it as regular dep, it will install the plugin version of web3 along with a user-supplied version of web3.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages/web3/src/index.ts
Outdated
@@ -321,6 +321,6 @@ along with web3.js. If not, see <http://www.gnu.org/licenses/>. | |||
/** | |||
* This comment _supports3_ [Markdown](https://marked.js.org/) | |||
*/ | |||
import Web3 from './web3'; | |||
import { Web3 } from './web3'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not do both module export and named export instead of just module export?
Named export generally works better with IDE (auto-import and type hinting)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this commit I've updated Web3
to be exported via default
and named
@@ -276,3 +285,7 @@ export type TransactionBuilder< | |||
web3Context: Web3Context<API>; | |||
privateKey?: HexString | Buffer; | |||
}) => Promise<ReturnType>; | |||
|
|||
export abstract class Web3PluginBase<API extends Web3APISpec> extends Web3Context<API> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is how the rest of the modules in web3 are built. The only issue I see with this is once we have plugins that depend on other plugins, types won't work because we are augmenting Web3 class and plugins are using Web3Context.
Alternative of top of my head would be:
export const plugin1 = {
namespace,
init: (web3: Web3) => Plugin1Api
}
declare module web3{
interface Web3 {
plugin1: Plugin1Api;
}
}
and if you require plugin1 in plugin2:
import plugin2 from "plugin2"
export const plugin1 = {
namespace,
needs: [plugin1.namespace]
// because we imported plugin2, Web3 class here will be augmented with plugin1 api
init: (web3: Web3) => Plugin1Api
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5490 tracks this
getPrice: () => Promise<Price>; | ||
} | ||
|
||
declare module 'web3/dist/web3' { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tested if end user imports Web3 from 'web3' (instead of 'web3/dist/web3') will they see augmented API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this commit, Web3
is now exported as a named export which means this is now:
import { Web3 } from 'web3';
declare module 'web3'
@@ -31,7 +31,7 @@ import { initAccountsForContext } from './accounts'; | |||
import { Web3EthInterface } from './types'; | |||
import { Web3PkgInfo } from './version'; | |||
|
|||
export default class Web3 extends Web3Context<EthExecutionAPI> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break minified web3.js build #5345
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This commit updates Web3
to be exported via default
and named. I've created a test example that uses the web3.min.js
and calls various functions to ensure the minified build works
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to keep this as example for others to implement plugins, :
web3-plugin-example
example package should be placed under tools
|
||
public constructor(abi: ContractAbi, address: Address) { | ||
super(); | ||
this._contract = new Contract(abi, address); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should leverage context
coming via inheritance Web3PluginBase
and use that to instantiate contract. Ideally with every usage there should not be need to check :
if (this._contract.currentProvider === undefined) this._contract.link(this);
if context is used while instantiation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5492 tracks this and there seems to be a bug with updating a context that was passed upon instantiation of Contract
This pull request introduces 1 alert when merging a2f43db into e2afb75 - view on LGTM.com new alerts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great beside tiny stuff in addition to the already mentioned points by other reviewers.
…e/web3.js into wyatt/4.x/5091-chainlink-plugin
Co-authored-by: Muhammad Altabba <[email protected]>
…e/web3.js into wyatt/4.x/5091-chainlink-plugin
Co-authored-by: Muhammad Altabba <[email protected]>
Co-authored-by: Muhammad Altabba <[email protected]>
'0xc41b9a4f654c44552e135f770945916f57c069b80326f9a5f843e613491ab6b1'; | ||
|
||
requestManagerSendSpy.mockResolvedValueOnce(expectedGasPrice); | ||
// Not sure what's being mocked here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we, please, have an issue for investigating the matter and enhancing this piece of code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed by this commit
Example implementation for #5091
Unresolved Issues
registerPlugin
#5491Web3Context
should update when.link
is used on plugin #5492Points of Discussion
I believe theWeb3APISpec
on this line should beChainlinkPluginAPI
, but when making the change the following error appears for thisAttempted fixes for this include: Fix typing compatibility when linking a contract to a context #5416 andWeb3Context
Generic Fix #5480In order to get the declare module to work, I needed to update the Web3 package from using theThis commit updatesdefault
export to a named one - I'm not sure if/how this affects anythingWeb3
to be exported usingdefault
and named exportRelated to this change, importingThe above mentioned commit also updates this to useWeb3
like this is the only way I could get the module augmentation to workweb3
to augment module instead ofweb3/dist/web3
The return type for getPrice is inferred from the contract ABI instead ofChainlinkPluginAPI
This doesn't matter so much because the type the end user will see when callingweb3.chainlink.getPrice
is defined byChainlinkPluginAPI
(i.e. user will seegetPrice
returnsPromise<Price>
)