Can't start node server in production

[jahvi]

Current behavior

When running yarn build and then yarn start the server fails to start because of this error:

/home/user/storefront-api/packages/default-catalog/graphql/elasticsearch/root.resolver.ts:15
export default resolver;
^^^^^^

SyntaxError: Unexpected token 'export'
...

Expected behavior

The server should start normally.

Steps to reproduce the issue

1. Clone fresh version of the repo
2. Run yarn
3. Run yarn build
4. Run yarn start

Repository

https://github.com/DivanteLtd/storefront-api

Can you handle fixing this bug by yourself?

• YES
• NO

Environment details

• Browser: N/A
• OS: Mac OS Catalina 10.15.7
• Node: 14.14.0
• Code Version: master and develop

Additional information

For some reason node is trying to load the .ts files instead of the compiled .js files.

[jahvi]

I managed to get the server to start by removing the .ts files in the packages folder before running yarn start:

find ./packages -name "*.ts" -type f -delete

It's not ideal but hopefully this can help someone else until a proper fix is implemented.

[cewald]

I guess that is the reason why the core packages are recommended to be installed seperatly for production in documentation. This way the .ts fields won't interfere because it's a done build. I don't found out why node is even trying to load .ts files.

Anyway – IMO this isn't very convenient, for example if you'd have core changes you'll need to create your own package and npm repo. I've tried to use the existing monorepo-structure and build the packages right away but couldn't make it work because of the non-relative imports of the external-dependencies like @storefront-lib/logger. They won't be found.

@jahvi Do you made any progress?

[jahvi]

@cewald Not much luck unfortunately, I'm just using the workaround I posted here for the time being.

I tried changing the tsconfig to move the compiled js files into the dist folder but I didn't have much luck. I still don't know why some .ts files are getting loaded, I wonder if they're being hardcoded as a reference somewhere.

Like you said, installing as a separate npm package could fix it but even the "supported" docker installation suffers from this issue so I think it's worth fixing.

[jahvi]

I think the problem is this file:
https://github.com/DivanteLtd/storefront-api/blob/master/packages/lib/helpers/graphql.ts#L5

The ts extension is hardcoded here so it's trying to include these files even in production.

I guess you can change it so it uses .js first if it exists then fallback to .ts but I'm not sure if it's the best way to fix it.

[cewald]

As we need the .ts files for the dev mode and .js for production, you could simply ask for the VS_ENV environment variable to verify if it's in dev or prod mode like:

export function loadModuleResolversArray (graphQlPath: string, extensionsPath?: string): any[] {
  const fileLoaderExt = process.env.VS_ENV && process.env.VS_ENV === 'dev' ? 'ts' : 'js'
  const rootResolvers = fileLoader(path.join(graphQlPath, `*.resolver.${fileLoaderExt}`))
  const coreResolvers = fileLoader(
    path.join(graphQlPath, `/**/resolver.${fileLoaderExt}`)
  );
  const extensionsResolvers = extensionsPath ? fileLoader(
    path.join(extensionsPath, `/**/resolver.${fileLoaderExt}`)
  ) : [];
  return rootResolvers.concat(coreResolvers).concat(extensionsResolvers)
}

[jahvi]

Thanks @cewald that works on my end.