feat: Expose near-lake-primitives to VM

[morgsmccauley]

• Upgrade near-lake-primitives to 0.2.0, which includes borsh
• Expose entire near-lake-primitives library to VM via primitives, e.g. borsh can be accessed via primitives.borsh.fromBorsh()

[morgsmccauley]

The project expects npm install and we should stick to that

[darunrs]

I believe we need to increase the primitives library version in the frontend too. I don't think we need to make any code changes though, since we pull the primitives type file from node nodules and add the whole file. Could be wrong on that though.

[morgsmccauley]

I believe we need to increase the primitives library version in the frontend too. I don't think we need to make any code changes though, since we pull the primitives type file from node nodules and add the whole file. Could be wrong on that though.

Done, looks like it does pull from node_modules so shouldn't require any change

[darunrs]

Sorry another thought just occurred to me. The reason we can freeze Block as "block" is because we import it through import { Block } from "@near-lake/primitives"; and then have users write code in a function which surfaces it as block through async function getBlock(block: Block) { in the frontend. I believe we might need to make a change to the template code on the frontend to import whatever we want from primitives as Primitives. Otherwise, autocomplete might lead users to write code that doesn't reference primitives the way we were expecting.

[morgsmccauley]

Sorry another thought just occurred to me. The reason we can freeze Block as "block" is because we import it through import { Block } from "@near-lake/primitives"; and then have users write code in a function which surfaces it as block through async function getBlock(block: Block) { in the frontend. I believe we might need to make a change to the template code on the frontend to import whatever we want from primitives as Primitives. Otherwise, autocomplete might lead users to write code that doesn't reference primitives the way we were expecting.

Good catch - we do need to update the template, most likely to import * as primitives from "@near-lake/primitives", so they have access to the entire primitives library.

It also looks like type declarations are manually defined/included, so those will need to be updated. Would be more convenient if we could pull from the library/node_modules directly, but I don't think that's possible with the multi-file output near-lake-primitives currently has. I'll see if I can get that working.

[morgsmccauley]

I've updated the primitives (near-lake-primitives) types for Frontend - but this won't include the types for exported dependant packages, i.e. borsher. This exports are still usable, but won't be visible via frontend intellisense. Dependant packages are referenced via imports, which therefore assume that the library exists within node_modules, this is tricky to achieve with Monaco, so for now, all dependant packages will be left as any. We may revisit this again in future.

For reference, borsher is exported under the borsh module within near-lake-primitives. So the entire library is accessible via primitives.borsh.{borsher API}, e.g. primitives.borsh.borshSerialize()

FYI @Tguntenaar