webresource push addition

[dmcweeney]

Hi @neronotte

Firstly thanks for putting the work into this tool and making it available.

Secondly, how would you fell about an additional option to allow webresources be defined in a json manifest as opposed to a physical folder structure. I was thinking of adding a manifest param to specify the json file that describes the webresources and the source file for each webresource. When the manifest param is specified, the path should point to the build output folder that contains the generated web resource files. For example:

{
    "publisher": "publisher-name",
    "contents": [
        {
            "name": "ribbon",
            "type": "folder",
            "contents": [
                {
                    "name": "ribbon1.js",
                    "type": "file",
                    "path": "relative/from/path/ribbon1.js"
                },
                {
                    "name": "ribbon2.js",
                    "type": "file",
                    "path": "relative/from/path/ribbon2.js"
                }
            ]
        },
        {
            "name": "another.js",
            "type": "file",
            "path": "relative/from/path/another.js"
        }
    ]
}

Would result in the following webresource structure

publisher-name
- ribbon
-- ribbon1.js
-- ribbon2.js
- another.js

I could do a PR if you are interested.

Ref here also: 661

Thanks, Donal

[neronotte]

Hi @dmcweeney ,
do you mean to have the webresource files in a flat structure locally, and then upload them with a structure defined in the json on the system?
What's the use case for it? In my experience, having a matching structure simplifies long term management of the customization... tell me more about how do you work with webresource, and we'll figure out something

[RemyDuijkeren]

I agree with you on this, just map the local file structure to Dataverse. Long-term this is the best for management.

I see other tools using a mapping file, and managing that is annoying and error prone. Please don't go this route :-)

[neronotte]

HI @dmcweeney,
request implemented in the current PACX version (1.2025.3.162).

Steps:

1. Create a pacx webresource project via pacx wr init
2. Add a reference to an external js file via pacx wr addReference (documentation)
3. Push webresources to dataverse via pacx wr push -r all (documentation, you have several options to tweak the behavior of pacx wr push)

The pacx wr addReference command will update the.wr.pacx file to act as as mapping file, with a structure similar to the following:

{
  "Version": "1",
  "ExternalReferences": [
    {
      "Source": "../../out/account.js",
      "Target": "greg_account.js",
      "Type": "Script"
    },
    {
      "Source": "../../out/contact.js",
      "Target": "greg_contact.js",
      "Type": "Script"
    }
  ]
}

Where:

• Source: is the relative or absolute path of the wr file on disk (matches path in your example)
• Target: is the name of the wr in the target environment (matches name in your example)
• Type: is the web resource type. Can be:
  • WebPage
  • StyleSheet
  • Script
  • Data
  • ImagePng
  • ImageJpg
  • ImageGif
  • Silverlight
  • Xsl
  • Icon
  • ImageSvg
  • Resx

Try it out and let me know what do you think about it!

[dmcweeney]

@neronotte, this looks good - many thanks for putting this together. I've been diverted to something else for the foreseeable future so wont get to test this out soon. Unfortunately...

What's the use case for it? In my experience, having a matching structure simplifies long term management of the customization... tell me more about how do you work with webresource, and we'll figure out something.

When the webresources were uploaded via the xrm toolbox they were uploaded from a flat structure to a structure that contained folders. Then there was some restructuring of libs into an nx monorepo where all webresources were included in the same lib which resulted in them being generated into a flat structure.... but then manually uploaded via xrm toolbox to the legacy folder structure... too much room for manual error, this the need for the mainifest to keep track of this.

Thanks, Donal