Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IE 11 Syntax Error starting in version 1.20.0 #124

Closed
davidprovan opened this issue May 13, 2020 · 17 comments · Fixed by #139
Closed

IE 11 Syntax Error starting in version 1.20.0 #124

davidprovan opened this issue May 13, 2020 · 17 comments · Fixed by #139
Labels

Comments

@davidprovan
Copy link

Hey,

I have been debugging an issue with our project for the last day or two where we had issue's rendering on IE 11 (I know I know but Windows still supports it).

When we downgrade to explicitly use 1.19.1 we work great on IE 11 and when we upgrade to 1.20.0 or higher we get a syntax error in our vendors.js generated by webpack. Is there anything particular in that changeset which would have adversely affected IE 11?

I looked through the changeset comparing 1.20.0 with 1.91.1 and wondered if the acorn multiline addition could have thrown IE11 for a whirl?

Thanks for any advice or thoughts.

David

@TroyAlford
Copy link
Owner

Hmm. :\ I wouldn't think that should make a difference, but I'm not sure. What exactly is the syntax error you're getting? Can you share/copy it, or screenshot it or something?

It's possible that the upgrade from [email protected] to [email protected] & [email protected] introduced something that doesn't work well - and maybe we're missing a polyfill or something?

I don't see anything in the changeset between those two versions that seems like a smoking gun, on the surface, as far as this lib's actual source code, but I'm happy to try to help support, if I can, if you can provide the add'l info?

@TroyAlford TroyAlford added the bug label May 14, 2020
@davidprovan
Copy link
Author

davidprovan commented May 14, 2020

Thanks for the reply.

We get a helpful SCRIPT1002: Syntax Error. I realize this isn't greatly helpful.

When I force npm back to 1.19.1 the syntax error stops being an issue.

Our JSX looks like this:

const ParserTest = props => {
	return (
		<>
            <p>Parser test</p>
            <JsxParser
                components={{ ComponentA, ComponentB, }}
                jsx={`<span>
                        Here is our JSX
                        <ComponentA />
                        <ComponentB />
                    </span>
                `}
            />
        </>
	);
};

@TroyAlford
Copy link
Owner

TroyAlford commented May 14, 2020

@davidprovan - not sure if this is just an error with your example, or if it's actually reflective of your code - but what you pasted isn't valid JSX. Valid JSX would be something like:

const ParserTest = props => { 
  return <>
    <p>Parser test</p>
    <JsxParser
      components={{ ComponentA, ComponentB }}
      jsx="<span>Here is our JSX</span> <ComponentA /> <ComponentB />"
    />
  </>;
};

Note the "" around the jsx value, rather than {}, and also the injected <span /> around the bare text. If you just put the bare words inside the JSX binding, you should get a syntax error; something like "Here is undefined" or similar. And this should happen at design/build time, not at run time.

Can you confirm?

My suspicion is that if you've got the string part right, in your real code, the issue is that you're passing in bare text at the start of the string. AFAIK JSX won't handle this without some kind of wrapper.

That's equivalent to the following:

ReactDOM.render(
  Here is our JSX
  <ComponentA />
  <ComponentB />
)

Which won't compile.

Instead, you need at least a Fragment inside.

jsx="<>Here is our JSX <ComponentA /> <ComponentB /></>"

@davidprovan
Copy link
Author

Yeah that's an error on my part when I pasted into the git hub comments we are using the String literals, apologies. Fixing original comment now.

@davidprovan
Copy link
Author

Commented edited @TroyAlford , please accept my apologies, I was used to GitLab markdown. This JsxParser code works great in Chrome, Firefox etc... Just IE11 throws that syntax error.

@davidprovan
Copy link
Author

IESyntaxError
This is the helpful error IE throws.

@TroyAlford
Copy link
Owner

Ouch. :\ @davidprovan - can you create a minimal reproduction of this, and upload it as a zip or a repo that I can run locally, to see if I can figure out what's up?

@TroyAlford
Copy link
Owner

Given the lack of response, here, I'm going to close this ticket. Please feel free to comment again and re-open if there is still something here to look at.

@kate-hall
Copy link

Commenting because this is an issue I have as well. IE11 and newer versions of acorn-jsx don't play nice, and I get a WSOD in IE11 just from importing this component as a result.

See: acornjs/acorn-jsx#98

@koszatnik12
Copy link

koszatnik12 commented Jun 2, 2020

Hi :)
I've got the same error on IE:
for: "react-jsx-parser": "1.24.1",

Part of chunk.js where IE found the syntax error:

class extends e{static get acornJsx(){return p}jsx_readToken()
{let t="",e=this.pos;for(;;)
{this.pos>=this.input.length&&this.raise(this.start,"Unterminated JSX contents");
let i=this.input.charCodeAt(this.pos);
switch(i){case 60:case 123:return this.pos===this.start?60===i&&this.exprAllowed?(++this.pos,this.finishToken(u.jsxTagStart)):this.getTokenFromCode(i):(t+=this.input.slice(e,this.pos),this.finishToken(u.jsxText,t));
case 38:t+=this.input.slice(e,this.pos),t+=this.jsx_readEntity()

I have also tried to transpile ancornJsx with babel, but unfortunately it didn't work

{
        test: /\.([jt])sx?$/,
        include: [
            .....
            path.resolve(__dirname, 'node_modules/acorn-jsx'),
            path.resolve(__dirname, 'node_modules/acorn'),
        ],
        use: [
            {
                loader: 'babel-loader',
                options: {
                    cacheDirectory: true,
                    cacheCompression: false
                }
            }
        ],
    },

@TroyAlford TroyAlford reopened this Jun 2, 2020
@TroyAlford
Copy link
Owner

Hm. I reopened the issue, since there are new reports of this. Is this IE11, I assume? Or are you also seeing this in Edge and higher?

It seems reasonable to transpile acorn-jsx. Not exactly sure how to pull that off, though. I guess I need to convince webpack to pick it up and transpile it along with the rest of the code?

@koszatnik12
Copy link

On Edge everything is perfectly fine :)

I'm not sure but maybe react-responsive-carousel has similar issue: leandrowd/react-responsive-carousel#439
and the just change the babl config
https://github.com/leandrowd/react-responsive-carousel/pull/442/files

TroyAlford pushed a commit that referenced this issue Jun 7, 2020
@TroyAlford TroyAlford mentioned this issue Jun 7, 2020
TroyAlford added a commit that referenced this issue Jun 7, 2020
* Fixes #124: add es5 build
* Bump all dependencies
@TroyAlford
Copy link
Owner

I think the latest will resolve this. I am going to look at the other recent issues before publishing - but the new version will contain a /lib/es5/react-jsx-parser.min.js file, which additionally transpiles acorn-jsx with the @babel/env set to target ie: 11.

I work on a mac, so I haven't tested this in any real use cases - but I'll be happy to re-open and do some more with it if folks continue to see issues.

@TroyAlford
Copy link
Owner

TroyAlford commented Jun 7, 2020

This is now released as 1.25.1.

As updated in the README, please import from react-jsx-parser/lib/es5/react-jsx-parser.min.js if you need IE11 support, and let me know if you see any trouble!

@koszatnik12
Copy link

Now it is perfectly working on IE 11 !! :)
Great job, thanks so much ! ;)

@TroyAlford
Copy link
Owner

My pleasure :) Glad it helped out.

@kate-hall
Copy link

Updating to say it solved my issue, too. Thank you!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants