Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow opt-out of global Xrm namespace #181

Open
chrisdmacrae opened this issue Apr 23, 2020 · 7 comments
Open

Allow opt-out of global Xrm namespace #181

chrisdmacrae opened this issue Apr 23, 2020 · 7 comments

Comments

@chrisdmacrae
Copy link

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

We're looking to unit test our webresources using xrm-mock, as it's the only mature type-safe testing library for the Xrm Api.

However, xrm-mock is typed against @types/xrm and therefore cannot be used in conjunction with XDT.

Describe the solution you'd like
A clear and concise description of what you want to happen.

E.g:

namespace Xrm
{
  ...
}

namespace Form.workflow.main
{
  ...
}

Would become:

namespace MyCustomXrmDefinitelyTypedNamespace
{
  namespace Xrm
  {
    ...
  }
}

namespace MyCustomXrmDefinitelyTypedNamespace
  namespace Form.workflow.main
  {
    ...
  }
}

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

I have tried a thousand things other the sun, but there is no alternative. Typescript attempts to merge declared namespaces found in declaration files, and there is no way to opt out.

This means right now you use XrmDefinitelyTyped, or any other libraries typed against @types/xrm.

Additional context
Add any other context or screenshots about the feature request here.

I would be happy to submit a PR to do this.

@chrisdmacrae chrisdmacrae changed the title Allow _all_ generated types to be scoped to a custom namespace, to allow interop with other libraries and types Allow opt-out of global XRM namespace Apr 23, 2020
@chrisdmacrae chrisdmacrae changed the title Allow opt-out of global XRM namespace Allow opt-out of global Xrm namespace Apr 23, 2020
@chrisdmacrae
Copy link
Author

chrisdmacrae commented Apr 23, 2020

@TomMalow @magesoe

As an alternative to the solution above, simply allowing the Xrm namespace to be renamed would also work, but I feel like this would feel less ergonomic.

Again, more than happy to submit a pull request as being able to use XDT with xrm-mock is paramount for us.

@chrisdmacrae
Copy link
Author

chrisdmacrae commented Apr 23, 2020

Given that half of the files are static, my gut tells me the right approach is to:

  • add a unique token to both generated and static type declarations at the top and bottom of the file, or;
  • replace the "Xrm" namespace with a unique token in both generated and static type declarations

Then:

  • run a final method that opens each of these files and:
    • replaces the unique tokens with the custom namespace and the closing brace, or;
    • replace the "XRM" token with the custom namespace name, or;
    • replace the "XRM" token when no custom namespace name is provided

This will leave everything working backwards compatible, while adding a new command line and configuration option to specify the custom namespace(s).

This would also open up the door for more customization of other things down the road, via tokenization.

E.g:

// src/XrmDefinitelyTyped/Resources/xrm.d.ts
declare namespace %NAMESPACE% {
   interface SomeControl extends %NAMESPACE%.AnyControl {}
}
// XrmDefinitelyTyped.exe.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="crmVersion" value="8.2" />
    <add key="out" value="./out" />
    <add key="namespace" value="XrmDefinitelyTyped.Xrm" />
    <add key="entities" value="contact" /
</configuration>
// out/xrm.d.ts
declare namespace XrmDefinitelyTyped.Xrm {
   interface SomeControl extends XrmDefinitelyTyped.Xrm.AnyControl {}
}

@magesoe
Copy link
Collaborator

magesoe commented Apr 23, 2020

I love the idea! You should definitely submit a PR

@daryllabar
Copy link

I wrote a tool to do this for me post generation. It also does other additional tapings for some custom libraries, but I'm not ready to share it as of yet (although it's on my github profile, so if you're really crazy, you can look at it if you want)

@majblackburn
Copy link

majblackburn commented Jul 14, 2022

We have this same issue, a collision between XRMDT and @types/xrm. Just allowing a parameter to set the generated namespace to something other than Xrm seems simple and should fix the problem. Or did DlaB ever publish his post-op tool? @daryllabar any hints?

@hansgfixed
Copy link

I wrote a tool to do this for me post generation. It also does other additional tapings for some custom libraries, but I'm not ready to share it as of yet (although it's on my github profile, so if you're really crazy, you can look at it if you want)

Hi @daryllabar , guess you meant "xdt-formext"? Have you lately been able to successfully use jest with xdt but without using your tool? Afaik your npm package "xdt-formext" isn't available anymore and I struggled to implement everything according to TypeScripting the Heck Out Of Model Driven Forms.

We have this same issue, a collision between XRMDT and @types/xrm.

Hi @majblackburn too, do you have any news on this issue? I don't want to use @types/xrm at all.

@daryllabar
Copy link

I've haven't tried XDT without my post processor. My name package is still available:

https://www.npmjs.com/package/xdt-formext

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants