fix: codesplit cli code to allow mud.config.ts to be imported in the browser

[alvrs]

We need to be able to import mud.config.ts in browser code to infer types for various client libraries (eg store-cache).
This PR fixes a couple issues that prevented this:

• Importing mudConfig also imported code intended for node environments, which caused vite in consumer projects to error (example:
  )
• global (used for mud plugins extending the config) was not defined in browser contexts:
  

[alvrs]

Unclear why tests are failing, all are passing locally and there were no changes to the store package that would influence the forge tests. Trying foundryup to see if it's caused by a new foundry version.

[holic]

maybe time for #746?

[holic]

Unclear why tests are failing, all are passing locally and there were no changes to the store package that would influence the forge tests. Trying foundryup to see if it's caused by a new foundry version.

Looks like main is failing too. I think it might be this: foundry-rs/foundry#4920

The intended behavior is that it only works for the next immediate call. This new behavior only allows to:

• Call the cheatcode AND fill the expected emit right after calling the cheatcode. Declaring the cheatcode N times and then filling N events will fail.
• match events after the next CALL is triggered. Events not triggered by a call will be ignored. Events nested in the triggered CALL subtree will be matched. If the events defined are not matched, the execution will revert.

It's a little unclear by the above "nested in the CALL subtree" description if this should succeed or fail in our case, but I noticed that StoreCore.pushToField is doing more calls internally before emitting, so maybe it's not matching on the new criteria for expectEmit?

This feels like a bummer constraint if so, and wonder if there are ways around this or alternative vm helpers.

I asked about this in the Foundry Support Telegram group. If there's not a quick/clear way to test for emits in the same way with the latest foundry version, we may need to pin our version for now.

[holic]

Another option is to use Vulcan test utils, which has some nicer ergonomics: https://github.com/nomoixyz/vulcan

mc.doSomethingElse();

// Check event emissions
expect(address(mc).lastCall()).toHaveEmitted(
    "SomeEvent(address,bytes32,uint256)",
    [address(1).topic(), any()], // Event topics
    abi.encode(123) // Event data
);

(I also have an open issue and they have a pending PR for better gas reporting)

[holic]

opened an issue for this since its unrelated to this PR: #814

[holic]

nice catch

[holic]

should this be /node rather than /cli?

[alvrs]

yeah I was torn between the two, but now agree node fits better - changed it for both config and world exports

[holic]

Looks good! Only question is if we should call this export node rather than cli, if node is the intended environment. cli sounds too use case specific and very internally oriented, and if that's what we're aiming for, maybe we name it cli-for-internal-use-only haha

Separately wondering if we should just bite the bullet on #746 (maybe not before the hackathon but quickly following?)

[alvrs]

Separately wondering if we should just bite the bullet on #746 (maybe not before the hackathon but quickly following?)

Unfortunately I think it's too close to the hackathon now to refactor this, but agree with shortly after!

[dk1a]

I like node