Avoid scope variable collisions with reserved keywords (like 'default')

[spautz]

Is there an existing issue for this?

• [X] I have searched the existing issues

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

Feature Request

I've hit a difficult-to-debug issue which I believe this package could help others diagnose more easily. I'm happy to submit a PR with this change if it's likely to be accepted.

Scenario

I'm using React-Live to create a playground for other developers to use. For convenience, I add everything from React to the LiveProvider scope, so that code using useState doesn't need to be changed to React.useState:

import * as React from 'react';

const myScope = {
   ...React,
   ...otherStuff,
};

<LiveProvider scope={myScope}>

The problem

In production mode only, React provides a default export. This becomes myScope.default above.

Once myScope is passed into React-Live, it makes its way to src/utils/transpile/evalCode.ts, where the list of keys is passed to new Function() to become the function's arguments. It then fails because "default" is a reserved keyword: it's not a valid argument binding.

As a result, <LiveError/> displays "SyntaxError: Unexpected token 'default'".

This took me some time to debug because I didn't have any "default" in my code, and because everything worked fine in development mode. It wasn't clear that "SyntaxError: Unexpected token 'default'" was actually due to a property in the scope, since there was no stacktrace or other information.

Local fix

The user-side fix is easy: delete myScope.default before passing scope={myScope}.

Proposed change

evalCode could examine scopeKeys and return a more tailored error message if it finds default or any other reserved keywords.

I think that just presenting a tailored error message would be enough to help others realize the mistake if they run into this scenario in the future.

[Markeljan]

live(time) saver

[Vijayanand16]

I'm encountering the same issue. It works perfectly in my local environment, but I see the same error on the deployed version.

Is there any known fix or workaround for this? I'd really appreciate any help or guidance—thanks in advance!