scottdurow / dataverse-gen Goto Github PK

When generating the definitions for the Account, a custom field has the type FileType in the generated file. Which package would be needed to be imported? This is the attribute:

custom_logo?: FileType | null;

For now I changed it to string | null, otherwise the type is not found.

Hey Scott, I've got a feature suggestion/request.

This tooling is awesome for generating types, but one thing I've noticed that its missing is the ability for it to generate an Interface for WebAPI Types.

As you likely know, when you go to retrieve records with the WebAPI, some of the attribute names you get back are slightly different. To give an example lookups have the format of _xxx_,myattribute_value... and each record gets an @odata.etag appended.

Also when you to to make updates, you have to use the capital sensitive [email protected] attribute.

So would it be possible to get the ability to generate API Types added in? I`m thinking it would mainly just be a variant of the IEntity Interface Types that are already being generated, but it would generate two entries for the Lookups. One for the API Retrieval Format, and one for the Create/Update format.

Hello Scott,

Is there a way to turn off the enum generation ?

Thanks,
Kim Anh

I logged in Dataverse and generated the token, but when I try to execute npx dataverse-gen init I get the following error:

node:internal/modules/cjs/loader:988
  throw err;
  ^

Error: Cannot find module 'dataverse-ify/lib/xrm-webapi/TokenCache'
Require stack:
- C:\Users\alber\AppData\Roaming\npm\node_modules\dataverse-gen\lib\index.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:985:15)
    at Function.Module._load (node:internal/modules/cjs/loader:833:27)
    at Module.require (node:internal/modules/cjs/loader:1057:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (C:\Users\alber\AppData\Roaming\npm\node_modules\dataverse-gen\lib\index.js:19:22)
    at Module._compile (node:internal/modules/cjs/loader:1155:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1209:10)
    at Module.load (node:internal/modules/cjs/loader:1033:32)
    at Function.Module._load (node:internal/modules/cjs/loader:868:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    'C:\\Users\\alber\\AppData\\Roaming\\npm\\node_modules\\dataverse-gen\\lib\\index.js'
  ]
}

I also tried to move this file inside the node_modules folder and then it works, but I would prefer to not to do this. When I change node_modules\dataverse-gen\lib\index.js line 19 from const TokenCache_1 = require("dataverse-ify/lib/xrm-webapi/TokenCache"); to const TokenCache_1 = require("dataverse-ify/lib/webapi/TokenCache"); it works fine.

VERSION: 1.0.13

When adding metadata for types such as BigIntAttributeMetadata, BooleanAttributeMetadata that inherit from AttributeMetadata, dataverse-gen fails with the error Error:Cannot read properties of undefined (reading 'LogicalName')

My .dataverse-gen.json has the following settings:

  "entities": [
    "account",
    "contact",
    "email",
    "incident"
  ],
  "actions": [],
  "functions": [],
  "output": {
    "outputRoot": "./src/dataverse-gen"
  },
  "generateFormContext": true,
  "generateEntityTypes": true
}

Versions I use:

    "dataverse-gen": "^2.0.15",
    "dataverse-ify": "^2.0.7",
    "dataverse-auth": "^2.0.7"

The files are generated, I love it, the only issue is that the LookupAttributes and LookupControls are not generated for the formContext.
Do I miss something here or it's not working out of the box?
@scottdurow

Quite new to dataverse-gen but I have an odd issue where all the enums for the system entities are named incorrectly, e.g. account_acccount_accountcategorycode.ts, which should simply be acccount_accountcategorycode.ts, it's both the TS filename and also the enum declaration!

I've been able to modify the enum.ejs template to modify the generated enum file in this scenario, but then this doesn't help as the generated entity file is then broken due to the reference using the typescript filename! I guess I could change the entity.ejs too but I feel like I shouldn't need to do this and there is something I am fundamentally missing that means all the system enums are behaving in this way, but it doesn't happen for any custom entities and their enums!?

If an attribute metadata description has a line break, it will output as multiple lines in the code comments for that attribute which causes a syntax error.

Hi,

I'm getting timeouts errors when I try to generate the metadata using npx dataverse-gen. If I reduce the fetched entities to like below 10, it goes through sometimes, however sometimes it times out even on only one entity fetched. The entity it fails on is different basically every time.

Any help would be appreciated.

Kind regards,
Tom

Fetching CDS metadata for account
Fetching CDS metadata for activityparty
Fetching CDS metadata for activitypointer
Fetching CDS metadata for annotation

Error:Exception in execute:connect ETIMEDOUT ip:443
Stack:Error: connect ETIMEDOUT ip:443
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)
{"errno":"ETIMEDOUT","code":"ETIMEDOUT","syscall":"connect","address":"ip","port":443}```

Generating types for OpportunityClose entity causes a case only conflict with the following error:

module "c:/repos/dataverse/dataverse-ify/src/dataverse-gen/enums/opportunityclose_opportunityclose_opportunity_statuscode"
Already included file name 'c:/repos/dataverse/dataverse-ify/src/dataverse-gen/enums/opportunityclose_OpportunityClose_opportunity_statuscode.ts' differs from file name 'c:/repos/dataverse/dataverse-ify/src/dataverse-gen/enums/opportunityclose_opportunityclose_opportunity_statuscode.ts' only in casing.
  The file is in the program because:
    Imported via "../enums/opportunityclose_OpportunityClose_opportunity_statuscode" from file 'c:/repos/dataverse/dataverse-ify/src/dataverse-gen/entities/OpportunityClose.ts'
    Matched by include pattern '**/*' in 'c:/repos/dataverse/dataverse-ify/tsconfig.json'

The workaround is simply to correct the case of the import statement.

After some detective work, I found that .dataverse-gen.json didn't contain a property for output.templateRoot.
Adding this property solves it. I then did a bit more digging in the repo and I think to solve this in the package, the .dataverse-gen.template.json file should have content something like this:

{
    "entities":[],
    "actions":[],
    "functions":[],
    "generateIndex": true,
    "generateFormContext": false,
    "generateEntityTypes": true,
    "output": {
        "useCache": false,
        "outputRoot": "./src/dataverse-gen",
        "templateRoot": "./_templates",
        "fileSuffix": ".ts"
      }
}

However, there may be more to it than this, as there are some other things going on, which I don't fully understand yet . In MetadataGeneratorConfig.ts the interfaces look correct. There is an object exported (see below) but I haven't figured out how it is used, beyond that it's referenced in TypescriptGenerator.ts. Maybe @scottdurow you could elaborate (if its relevant).
I'm not sufficiently confident yet to submit this as a pull request, though if someone agrees that this is all that's needed, I will happily do so.

export const defaultOptions = {
  entities: [],
  actions: [],
  functions: [],
  referencedTypes: {
    Object: {
      name: "ObjectValue",
    },
    Guid: {
      name: "Guid",
      import: "dataverse-ify",
    },
    Entity: {
      name: "IEntity",
      import: "dataverse-ify",
    },
    EntityReference: {
      name: "EntityReference",
      import: "dataverse-ify",
    },
    WebApiExecuteRequest: {
      name: "WebApiExecuteRequest",
      import: "dataverse-ify",
    },
    StructuralProperty: {
      name: "StructuralProperty",
      import: "dataverse-ify",
    },
    OperationType: {
      name: "OperationType",
      import: "dataverse-ify",
    },
    ActivityParty: {
      name: "ActivityParty",
      import: "dataverse-ify",
    },
    enums: {
      import: "../enums/",
    },
    complexTypes: {
      import: "../complextypes/",
    },
    entityTypes: {
      import: "../entities/",
    },
  },
  generateIndex: true,
  generateFormContext: false,
  generateEntityTypes: true,
  output: {
    useCache: false,
    outputRoot: "./src/dataverse-gen", // Default
    templateRoot: "./_templates",
    fileSuffix: ".ts",
  },
} as DataverseGenOptions;

When dataverse-gen runs and creates the typings for a table there are 3 objects created in the entities ts file (Metadata, Attributes and the entity itself).
There is an inconsistency in this naming. The Metadata object is in camalCase where as the other two are in PascalCase.
If you for example generate the typings for Account you will get the following objects/definitions:

• accountMetadata
• AccountAttributes
• Account

I think they should be named the same way.

The output order of enums can vary between instances which can result in a 'noisy diff' in generating the enum. The solution is to sort by the integer value.

When the status reason has duplicate entries the transpile will fail since there are duplicate entires with the same name in the generated enum.

An example:
One of our customers has the status reason "Price" and "Quality" both for Active and Inactive status. The generated enums will get "Price" and "quality" twice. This will lead to errors while transpiling the TS to JS. Something like a pre or suffixed "active"/"inactive" might be helpful in that case.

For non-interactive scenarios (or convenience) allow auth using a client id and secret - similar to the Power Platform CLI.
This would by-pass the dataverse-auth profile, and use the secret as-is without any persisted token.

When generating metadata - often only a subset of columns are required - these could be included/excluded using a list of columns names or prefixes.