jsdom: Unexpected token in webidl-conversions

Basic info:

Node.js version: 10
jsdom version: 16.22

Minimal reproduction case

import React from 'react';
import jsdom from 'jsdom';
import { Header, Footer, LinksContainer, Toolbox } from '../components';
import App from '../App';

const { JSDOM } = jsdom;
const { window } = new JSDOM(`...`);
describe('Landing page', () => {
  beforeEach(() => {
    jest.resetModules();
  });

  afterEach(() => {
    jest.clearAllMocks();
    jest.clearAllTimers();
  });

  it('should render without throwing an error', () => {
    window.chrome = {
      runtime: {}
    };

    const wrapper = shallow(<App />);

    expect(wrapper.find('h1').text()).toEqual(i18n('LANDING_PAGE_TITLE'));
    expect(wrapper.find(Header)).toBeDefined();
    expect(wrapper.find(Toolbox)).toBeDefined();
    expect(wrapper.find(LinksContainer).length).toEqual(2);
    expect(wrapper.find(Footer)).toBeDefined();

    window.chrome.webstore = {};
    wrapper.setProps({ test: 'test' });
  });

  it('handleCancel should hide the modal', () => {
    window.chrome = false;
    const wrapper = shallow(<App />);
    const instance = wrapper.instance();

    instance.handleCancel();

    expect(wrapper.state('visible')).toEqual(false);
  });
});

... your code that reproduces the problem here, probably using dom.window ...

How does similar code behave in browsers?

Run a unit test by jest, then you will see

● Test suite failed to run

/node_modules/jsdom/node_modules/webidl-conversions/lib/index.js: Unexpecte d token, expected ( (357:12)

    355 | 
    356 |         return true;
  > 357 |     } catch {
        |             ^
    358 |         return false;
    359 |     }
    360 | }

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 21 (6 by maintainers)

Commits related to this issue

upgrade to node 14.15 for tests Tests fail when using node 8.9 due to this issue: https://github.com/jsdom/jsdom/issues/2963 — committed to Duke-GCB/datadelivery-ui by johnbradley 3 years ago
Upgrade to ember 3.16 and node 14.15 (#83) * upgrade ember 3.16 Fixes requirements. Selecting new delivery recipient is broken. Re-enables jquery * fix tests after 3.16 upgrade Skipping onS... — committed to Duke-GCB/datadelivery-ui by johnbradley 3 years ago

Most upvoted comments

Ok sure, will look into this further re:webpack when I have more time. I understand your position but this is a very odd thing to not just allow the merge – there is no burden created here. It was something like 5 lines of 100% compatible, automatically mergeable code. And it would fix compilation issues for an unknown-many number of this project’s users, and it would lower your burden so that you don’t have to deal with this issue as it will undoubtably continue to arise considering the various stacks users are running that are atop of node. Literally have a project with hundreds of node packages and this is the only one that throws on compilation. Defending this as a “modern” coding standards decision is odd. Not explicitly checking for the version you are compatible with and throwing an appropriate error makes it clear that the “modern” standards excuse is more of an afterthought, rather than a clearly engineered and intentional decision. Not accepting this fix is irrational, but you are maintaining it so that’s your decision. I chose this project thinking it was going to be the best most well maintained dom parser. The more likely route rather than opening issues with webpack which would require changing bundler versions first will be to switch the dom parser to something like https://github.com/fb55/htmlparser2 which has about 2M more users than this project. Unfortunate, though. Really.

erickmiller on Jan 13, 2021

No. I really urge you to file an issue on webpack.

We’re writing standards-compliant code; if other tools can’t deal with that, it’s not our bug, and we don’t intend to take on the maintenance burden of staying compatible with whatever non-standards-compliant tools people are combining our library with.

domenic on Jan 13, 2021

Yes, the syntax is a part of our standard, but I think it’s a good idea to omit to break backward compatibility if it’s possible. There are still a lot of environments in production that can’t be updated to node v10 because of different conditions.

E.g.: in my case, some of the productions are running in closed environments without internet and it’s hard to pass a new node there, but some fixes should be done for them also. To be on the same page, I need to use the same archaic node.js, but build and test tools that are dependent on jsdom downloads it’s a new version and stops working.

Tsenzuk on Jan 13, 2021

Node v8 is not supported, as noted in one of the very first lines of the README.

domenic on Jan 13, 2021

I have this issue just from importing jsdom in new empty project, node 8.17.0 😦

partyka1 on Jun 14, 2020