Custom field Typescript bindings causing compilation error

[jyotman]

Describe the bug
Adding typescript bindings for a custom field and using them in the plugin leads to a compilation error when running the server.
Vs-code shows no errors though.

To Reproduce
Steps to reproduce the behavior:

1. Add a custom field
2. Create new plugin
3. Add typescript bindings for the new custom field
4. Use it in code in the plugin
5. Start the server

Expected behavior
Server should start without error

Environment (please complete the following information):

• @vendure/core version: 1.1.3
• Nodejs version 14
• Database (mysql/postgres etc): postgres
  

Slack conversation - https://vendure-ecommerce.slack.com/archives/CKYMF0ZTJ/p1628053404063300

[michaelbromley]

Adding notes from the Slack convo:

Michael Bromley:
Try adding import '@vendure/core'; to the top of your types.ts file and see if that solves it.

Heiko:
I just ran into the very same issue, and this helped 👍
This problem seems to occur when the file only contains module augmentations, like yours. I didn't have this issue in another plugin where, in addition to the module augmentations, I exported a type from types.ts, thereby turning it into a module.

Jyot:
Hi Michael Bromley thanks, I can confirm that adding the import statement stopped the VS code errors and I’m able to resolve my field directly as productVariant.customFields.moq .
But now the typescript is throwing a compilation error when I run the server [screen shot as in issue above]. Any idea how to fix this?
vs-code shows no errors though and is able to resolve the moq property in code with autocomplete.

Michael Bromley:
I also ran into that yesterday I think. I suspect it has to do with the type definition of the Translated generic type and the way it is interacting with the customFields object. Are you able to open an issue on GitHub for this? Then I don;t forget to look into it when I have time. For now I suggest to assert as CustomProductVariantFields to avoid the error.

[HarunKilic]

I am still having this issue. Tried to create customField for Collections in a plugin:

@VendurePlugin({
  imports: [PluginCommonModule, BcModule],
  providers: [SyncCategoryService],
  adminApiExtensions: {
    schema: adminApiExtensions,
    resolvers: [BusinessCentralResolver],
  },
  configuration: (config) => {
    config.customFields.Collection.push({
      name: "bcCode",
      type: "string",
    });
    config.customFields.Collection.push({
      name: "bcId",
      type: "string",
      internal: true,
    });
    return config;
  },
})

Types:

import "@vendure/core";
declare module "@vendure/core" {
  interface CustomCollectionFields {
    bcId: string;
    bcCode: string;
  }
}

And ending with this error:
Property 'bcCode' does not exist on type 'CustomCollectionFields'.

Using Vendure V.1.3.3

[heiko-r]

I'm having this issue again just now. I have a similar plugin definition and ambient module declaration, and I'm including the ambient module declaration by adding import './types' in my plugin.ts. I have two plugins that define custom fields like that.

It used to work fine, until I added an event handler to one of the plugins, which makes use of its own custom fields. Now all my packages run yarn build fine individually, but I get this same error when running 'lerna run build' from the root directory.

Interestingly, the error appears to occur when building my 'prod-server' package, which contains the vendure config and bootstrapping files. I can avoid the error for one plugin at a time, by importing it's types.ts into the vendure config file, but if I import both plugins' types.ts, then the second one appears to be ignored and I get the above error for the custom fields of that plugin.

[michaelbromley]

@heiko-r yes I also ran into strange and hard-to-define behaviour like this in my own project. Something to do with the interaction between extending the types in multiple locations. Have not nailed down the exact mechanics of what is going on yet.

My solution has been to centralize all custom field type defs in a single file. Not so nice because they are no longer co-located with each plugin that defines them, but avoids these issues for now.