Skip to content

[RUN-AS-IF-FOSS] Remove most no-op default exports

Mark Florian requested to merge remove-babel-plugin-rewire-workarounds into master

What does this MR do?

Remove no-op default exports

These no-op default exports have served one or both of these purposes:

  1. Preventing babel-plugin-rewire from generating an invalid default during karma tests;
  2. Working around the import/prefer-default-export ESLint rule for files which only have one named export.

As we recently finished migrating all relevant specs from Karma to Jest, the first purpose is no longer necessary (with two exceptions, see below).

The second purpose will become unnecessary once the RFC to prefer named exports to default exports is implemented.

As such, this commit removes almost all no-op default exports, and adds explicit eslint-disable-next-line directives (which can be removed once the RFC is implemented).

This work was achieved in a few steps. First, the default exports explicitly marked as babel-plugin-rewire workarounds were removed.

This was achieved via this command:

rg --color=never -l0 "// prevent babel-plugin-rewire" \
    | xargs -0 \
    perl -0pi -e \
    's/\n+\/\/ prevent babel-plugin-rewire[^\n]*tests'\
'(?:\nexport default \(\) => {};)?//mgs'

The documentation describing this workaround was then removed by hand.

Unfortunately, two files still participate in Karma tests, and still need this workaround, so these were reverted manually. Those files (at the time of writing) are:

app/assets/javascripts/monitoring/stores/actions.js
app/assets/javascripts/monitoring/stores/getters.js

Then, all additional no-op default exports were removed with this command:

rg --color=never -l0 -F "export default () => {};" \
    | xargs -0 perl -0pi -e 's/\n+export default \(\) => {};//mgs'

Since the import/prefer-default-export ESLint rule is still in place, the files violating it have to disable it explicitly.

With the RFC to prefer named exports to default exports receiving wide approval, it makes sense to mark these current violations explicitly with eslint-disable-next-line directives, rather than implicitly via the no-op default export hack.

The benefit of this approach is that when we disable the import/prefer-default-export rule globally for the RFC, ESLint will warn about all of these now-unnecessary directives. This will make it much easier to address all of them (perhaps even automatically, via --fix!).

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Edited by Jose Ivan Vargas

Merge request reports