introduce a `lib/` directory under `a3p-integration`

[anilhelvaci]

What is the Problem Being Solved?

In a3p-integration, currently every proposal has to have its own library to place helper functions, etc. This ends up a lot of copy and pasting since most of the helpers are generic and a lot of proposal can use them. @Chris-Hibbert expressed this idea to have a higher level directory to host shared methods.

Description of the Design

• Create a3p-integration/lib
• Copy contents a3p-integration/proposals/z:acceptance/test-lib
• Turn a3p-integration/lib into a package
  • specify dependencies needed in the package.json
• In upgrade-test-scripts/install_deps.sh;
  • cd into a3p-integration/lib and invoke yarn install
  • Before installing dependencies for every proposal, add this to install_deps.sh
  • yarn link ../../lib --relative

Curios to hear what you think about this design as well @turadg.

Security Considerations

As long as we don't break CI, I believe we should be good.

Scaling Considerations

None.

Test Plan

Convert existing proposals from locally copied libraries to the linked one.

Upgrade Considerations

None.

[Chris-Hibbert]

Sorry, I didn't communicate that well. I meant symbolic links in the file system (ln -s), not whatever yarn link --symbolic does. There would just be multiple copies of the directory full of library source, but they'd all show the same files, so any updates or enhancements are visible to all proposals. I don't think it needs to be a separate package.

[anilhelvaci]

Honestly, I'm leaning towards using yarn link because a file system symlink enables making changes to the linked lib instance. Having multiple proposals linked to ../../lib might end up unwanted changes to it that breaks other proposals unnecessarily. What do you guys think? @Chris-Hibbert @turadg

[Chris-Hibbert]

Honestly, I'm leaning towards using yarn link because a file system symlink enables making changes to the linked lib instance. Having multiple proposals linked to ../../lib might end up unwanted changes to it that breaks other proposals unnecessarily. What do you guys think?

Having multiple proposals linked to ../../lib is the goal. When changes are made to support one proposal, they should support the other proposals as well. I think of this as a faster route to getting shared code than going through agoric-3-proposals/synthetic-chain. In that case, you'd also have to write the library so that it supports all clients.