SyntaxError: Cannot use import statement outside a module in 1.6.1 upgrade

[ssyberg]

Bug Report

When upgrading a non-typescript payload project to 1.6.1 yarn dev fails with SyntaxError: Cannot use import statement outside a module.

Though this is alluded to in the "Breaking Changes" in the CHANGELOG it is unclear what the path is for javascript based projects that do not want to use typescript (and are not interested in a path to typescript integration in the future). The only recommendation is to spin up a TS project and implement workarounds to continue using JS (I've successfully used a TS install this but this requires significant use of @ts-ignore).

Relatedly, npx create-payload-app results in a non-functional project when choosing javascript.

Steps to Reproduce

1. Starting from a working 1.5.9 javascript project, upgrade with yarn upgrade [email protected]
2. Run yarn dev

Proposed Fix

The fix for this was simply to (1) rename payload.config.ts to payload.config.js and update internal references and (2) switch from ts-node to node in the yarn serve definition. This process should be documented (and someone who knows the codebase better than I do should confirm this is sufficient). Further, create-payload-app should be updated to reflect these changes as well.

[jmikrut]

Hey @ssyberg — thanks for the issue!

Our create-payload-app is actually already updated to remove all base JavaScript templates, but you may have a cached version that still presents the old options to you.

But your proposed fix is actually similar to what we have documented in our changelog for that version - maybe there is some further clarity I can add there though. Theoretically, you just need some type of transpiler for your Payload config. There are many ways to do this, but using ts-node in development and then node in production, pointing at your post-compiled /dist folder, would be the way that we suggest. Just because that allows you to incrementally adopt TS over time if you would like to.

However, if you don't want to use ts-node, you could always just use a package like @swc/register by creating a stub file for your config, that then requires and exports your actual Payload config, like this:

payload.config.js

const swcRegister = require('@swc/register');

swcRegister({
  sourceMaps: 'inline',
  jsc: {
    parser: {
      syntax: 'typescript',
      tsx: true,
    },
  },
  module: {
    type: 'commonjs',
  },
});

const payloadConfig = require('./path-to-your-real-config.js');

module.exports = payloadConfig;

Basically, a package like @swc/register hooks into the Node require function, and runs any file required after that point through a transpiler automatically for you. This is what Payload used to do, and could be a simpler solution for you if you'd like to keep a JS-only project with no ts-node. However, for the reasons I mentioned prior, this is actually not our recommended approach just because we believe in the power of TS.

But, this would allow you to use full JS without any TS at all. And I should also note that even this is completely optional for you, and is only required if you want to use JSX or TS directly in your Payload config.

Does this clear things up?

Because there is nothing super actionable that we can do here, I will convert this into a discussion but am happy to keep conversation going there. Are you up and running successfully again?

[ssyberg]

Thanks for the thorough response! Just to clarify, besides not allowing you to incrementally introduce TS (for some client projects this is just not something that will ever be in the cards), can you think of any other downsides to this approach?

The fix for this was simply to (1) rename payload.config.ts to payload.config.js and update internal references and (2) switch from ts-node to node in the yarn serve definition.