EES-4715 suppress jsdom css errors

[amyb-hiveit]

JSDOM doesn't handle CSS well and seems to be particularly objecting to CKEditor, which is causing a ridiculous amount of errors in the log when running the admin tests. As far as I can tell it shouldn't be trying to parse it anyway as all CSS files should be going through the transform we have configured in jest.config.js, but it is so I've just supressed this error.

As suggested by @ntsim below, I've stubbed out CKEditor to prevent errors from its CSS build polluting the test output.

[ntsim]

Looked into the stylesheet a bit more and it seems like there's a few syntax errors which suggests something's potentially wrong with the built CSS. Most of the build config around this is from @ckeditor/ckeditor5-dev-utils, so maybe that's not quite configured correctly, or they may even have errors in their source CSS.

Unfortunately, the browser will just ignore stylesheet errors, so I guess this is slipping under the radar right now (one point for JSDOM). Hopefully they'll fix it in a later version of CKEditor.

Anyway, regardless of this issue, I think we can do a little better than just suppress the error. I figured out two options below:

Option 1 - Swap in VirtualTestEditor

This is a more complicated approach and is based on this issue, using Jest's moduleNameMapper we can stub out CKEditor (which doesn't really work in Node) with a VirtualTestEditor implementation. This can be found in ckeditor5-core, but isn't published as part of the package (check out source file).

Testing this out, I created a test build of explore-education-statistics-ckeditor which exports a copy-paste of the VirtualTestEditor:

// explore-education-statistics-ckeditor/src/ckeditor-test.js

import { DataApiMixin, Editor } from '@ckeditor/ckeditor5-core';

export default class VirtualTestEditor extends DataApiMixin(Editor) {
  constructor(config) {
    super(config);

    // Create the ("main") root element of the model tree.
    this.model.document.createRoot();
  }

  static create(config = {}) {
    return new Promise(resolve => {
      const editor = new this(config);

      resolve(
        editor
          .initPlugins()
          .then(() => editor.data.init(config.initialData || ''))
          .then(() => {
            editor.fire('ready');
            return editor;
          }),
      );
    });
  }
}

This just needs a few tweaks to the Webpack config:

// explore-education-statistics-ckeditor/webpack.config.js

+  entry: {
+    ckeditor: path.resolve(__dirname, 'src', 'ckeditor.js'),
+    'ckeditor-test': path.resolve(__dirname, 'src', 'ckeditor-test.js'),
+  },

   output: {
     // The name under which the editor will be exported.
     library: 'ClassicEditor',
     path: path.resolve(__dirname, 'build'),
+    filename: '[name].js',
     libraryTarget: 'umd',
     libraryExport: 'default',
   },

Once rebuilt, there's a build/ckeditor-test.js we can use to stub out the implementation. We can just swap this in through a moduleNameMapper in admin:

moduleNameMapper: {
  // ...
  '^explore-education-statistics-ckeditor$': '<rootDir>/../explore-education-statistics-ckeditor/build/ckeditor-test.js',
}

Option 2 - Stub out CKEditor

Iterating on option 1, we can actually go further and just do something like this:

// explore-education-statistics-admin/test/EditorStub.js

export default class EditorStub {}

Then just configure the moduleNameMapper appropriately:

moduleNameMapper: {
  // ...
  '^explore-education-statistics-ckeditor$': '<rootDir>/test/EditorStub.js',
}

This is a simpler approach and has some advantages:

• Practically no code needs to be built (option 1 outputs ~300 KB of JS)
• Basically nothing needs to be parsed during test runs

Giving it a light test, I didn't really see much of a difference in test performance on my machine. However, the above advantages might be more noticeable on lower end machines.

The main downside to this approach is that if in the future, we want to use a 'real' implementation of CKEditor in the tests, the stub obviously won't cut it.

The VirtualTestEditor implementation actually runs CKEditor and would allow actual methods to be called on it (etc). The main difference is that it doesn't try and render anything to the DOM (hence works great in Node).

For the timebeing, this isn't really necessary as we just swap out the CKEditor component (in FormEditor) with a textarea.

Personally, I'd go with option 2 and we can swap in option 1 if needed in the future.

[amyb-hiveit]

Thanks @ntsim, I've changed it to use option 2 now.