Add ds-test as NPM modules for Hardhat backwards compatibility

[decafboba]

Describe the feature you would like

Issue described in detail here.

Many of use would like to use Foundry + Hardhat, which still has tons of use cases (integration testing, complex deployment scripts, etc) and should really not be treated as a direct competitor. However, there are some small inconveniences that we have found when trying to do this.

As shown in the issue, it can almost be tidied up into one source of truth for all dependencies by mapping the paths the Forge uses to node_modules. But since ds-test and forge-std do not have NPM modules, you still need to maintain a ./lib directory and remappings.txt.

The simplest fix would probably be to wrap these dependencies in NPM modules. This probably has use-cases outside just the one described above, but would help immensely for all the Hardhat folks that want to give Foundry a go.

forge-std will do this but they need help with ds-test NPM package: foundry-rs/forge-std#39 (comment)

Thanks! 🙏

[d-xo]

I'm hesitant here, Im not involved with the npm ecosystem at all and I'm not sure what kind of extra maintenance burden this would impose.

Can you help me understand:

1. What exactly would be involved here? Adding a package json and publishing to npm? does npm enforce certain versioning schemes or folder layouts?

2. Which issue would actually be fixed here? Is this actually blocking anyone from working, or is it more an aesthetic consideration when working in mixed repos? Could mixed hardhat / foundry repos store all their deps in submodules instead of relying on npm?

[decafboba]

@d-xo For (2), it doesn't necessarily block, but you send up with multiple files acting as a source of truth for dependencies. When doing mixed hardhat / foundry repos, the NPM dependency method will always be required as hardhat (and all the JavaScript / TypeScript dependencies it has) are all in NPM. Currently though, all foundry submodules have an NPM equivalent except ds-test, so this is the last remaining dependencies from making these repositories more clear and easier to work with.

For (1), forge-std just added this to their's and it was pretty seamless. Their example should be able to be followed by going to foundry-rs/forge-std#39 (comment) and https://www.npmjs.com/package/@float-capital/ds-test.

[d-xo]

I don't see an official forge-std package on npm. https://www.npmjs.com/search?q=forge-std.

[d-xo]

I also don't understand why you can't keep solidity dependencies in lib as submodules and have contracts that you want to use with hardhat import from there?

[d-xo]

cc @brockelmore are you planning on uploading / have you uploaded forge-std to npm?

[decafboba]

@d-xo Sorry if the request wasn't clear, it is my understanding that forge-std doesn't have an NPM package, so the request is that one is added. Its a huge improvement in project organization for Foundry + HH structures, since forge-std is the only remaining dependency that cannot use normal NPM installation.

[decafboba]

Closing since @float-capital/ds-test exists in NPM, now just trying to see if we can get one for forge-std: foundry-rs/forge-std#39

[d-xo]

I also don't understand why you can't keep solidity dependencies in lib as submodules and have contracts that you want to use with hardhat import from there?

fwiw this is the approach taken in the official foundry / hardhat template: https://github.com/foundry-rs/hardhat-foundry-template

[decafboba]

I also don't understand why you can't keep solidity dependencies in lib as submodules and have contracts that you want to use with hardhat import from there?

fwiw this is the approach taken in the official foundry / hardhat template: https://github.com/foundry-rs/hardhat-foundry-template

It's about having multiple, (potentially) overlapping sources of truth for dependencies, which can be very tedious in larger projects. It's also about ease-of-use and clarify: every other dependency I've found has an NPM package, so with the 1-2 exceptions, /lib, .gitmodules, remappings.txt don't need to exist at all and don't need to be updated on every new dependency.

And because NPM dependencies can be used is JavaScript / deploy code as well as Solidity code (instead of just Solidity code), it is the better place to consolidate this logic.