Webpack error after upgrading Node: "Module parse failed: Unexpected token"

I'm troubleshooting a webpack error.

Command: bin/webpack --colors --progress

Produces this error:

ERROR in ./node_modules/@flatfile/sdk/dist/index.js 351:361
Module parse failed: Unexpected token (351:361)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
|           class v extends i {
|             constructor(e, t) {
>               super(e), r(this, "code", "FF-UA-00"), r(this, "name", "UnauthorizedError"), r(this, "debug", "The JWT was not signed with a recognized private key or you did not provide the necessary information to identify the end user"), r(this, "userMessage", "There was an issue establishing a secure import session."), e && (this.debug = e), this.code = t ?? "FF-UA-00";
|             }
|           }
 @ ./app/javascript/src/app/pages/content_assets/Index.vue?vue&type=script&lang=ts& (./node_modules/babel-loader/lib??ref--8-0!./node_modules/vue-loader/lib??vue-loader-options!./app/javascript/src/app/pages/content_assets/Index.vue?vue&type=script&lang=ts&) 22:0-41 125:6-14
 @ ./app/javascript/src/app/pages/content_assets/Index.vue?vue&type=script&lang=ts&
 @ ./app/javascript/src/app/pages/content_assets/Index.vue
 @ ./app/javascript/packs/app.js

NOTES

I found what appears to be an identical issue reported in the Flatfile project: https://github.com/FlatFilers/sdk/issues/83

Looks like ES2020 was emitted to the /dist folder so my cra babel loader is not able to parse it, in order to fix it I need to include the path on my webpack config.

Node v16.13.1
We're using webpack with a Rails project via the webpacker package (@rails/webpacker": "5.4.3") which is depending on webpack@4.46.0.
When I change to Node v14x and rebuild node_modules (yarn install) webpack compiles successfully.
The line referenced in the error (351:361) does not exist when I go check the file in node_modules/
We have a yarn.lock file, which I delete and recreate before running yarn install. I also delete the node_modules directory to ensure a "fresh" download of the correct packages.
We have a babel.config.js file...

module.exports = function(api) {
  var validEnv = ['development', 'test', 'production']
  var currentEnv = api.env()
  var isDevelopmentEnv = api.env('development')
  var isProductionEnv = api.env('production')
  var isTestEnv = api.env('test')

  if (!validEnv.includes(currentEnv)) {
    throw new Error(
      'Please specify a valid `NODE_ENV` or ' +
        '`BABEL_ENV` environment variables. Valid values are "development", ' +
        '"test", and "production". Instead, received: ' +
        JSON.stringify(currentEnv) +
        '.'
    )
  }

  return {
    presets: [
      isTestEnv && [
        '@babel/preset-env',
        {
          targets: {
            node: 'current'
          }
        }
      ],
      (isProductionEnv || isDevelopmentEnv) && [
        '@babel/preset-env',
        {
          forceAllTransforms: true,
          useBuiltIns: 'entry',
          corejs: 3,
          modules: false,
          exclude: ['transform-typeof-symbol']
        }
      ],
      ["babel-preset-typescript-vue", { "allExtensions": true, "isTSX": true }]
    ].filter(Boolean),
    plugins: [
      'babel-plugin-macros',
      '@babel/plugin-syntax-dynamic-import',
      isTestEnv && 'babel-plugin-dynamic-import-node',
      '@babel/plugin-transform-destructuring',
      [
        '@babel/plugin-proposal-class-properties',
        {
          loose: true
        }
      ],
      [
        '@babel/plugin-proposal-object-rest-spread',
        {
          useBuiltIns: true
        }
      ],
      [
        '@babel/plugin-transform-runtime',
        {
          helpers: false,
          regenerator: true,
          corejs: false
        }
      ],
      [
        '@babel/plugin-transform-regenerator',
        {
          async: false
        }
      ]
    ].filter(Boolean)
  }
}

Ultimately I want to get webpack to compile. If you had advice about any of the following questions, it would help a lot.

Why would changing the Node version (only) cause different webpack behavior? We aren't changing the the webpack version or the version of the @flatfile package that's causing the error.
Why is the error pointing to a line that doesn't exist in the package? Is this evidence of some kind of caching problem?
Does the workaround mentioned in the linked GitHub issue shed light on my problem?

Solution

I'll take a stab at this.

I believe your issue is that webpack 4 does not support the nullish coalescing operator due to it's dependency on acorn 6. See this webpack issue and this PR comment.

You haven't specified the exact minor version of Node.js 14x that worked for you. I will assume it was a version that did not fully support the nullish coalescing operator, or at least a version that @babel/preset-env's target option understood to not support ??, so it was transpiled by babel and thus webpack didn't complain. You can see what versions of node support nullish coalescing on node.green.
I don't fully understand the point you are making here, so not focusing on this in the proposed solution.
I'm not sure what the proposed workaround is in the linked issue, maybe the comment about "include the path on my webpack config", but yes the issue does seem relevant as it is pointing out the nullish coalescing operator as the source of the issue.

You can try to solve this by

adding @babel/plugin-proposal-nullish-coalescing-operator to your babel config's plugins

updating your webpack config to run @flatfile/sdk through babel-loader to transpile the nullish coalescing operator:

{
  test: /\.jsx?$/,
  exclude: filename => {
    return /node_modules/.test(filename) && !/@flatfile\/sdk\/dist/.test(filename)
  },
  use: ['babel-loader']
}

Another possibility is to upgrade webpacker to a version that depends upon webpack v5.

One final remark, when you say

We have a yarn.lock file, which I delete and recreate before running yarn install.

you probably should not be deleting the lock file before each install, as it negates the purpose of a lock file altogether.