CustomFunctionsMetadataPlugin ERROR in Conflict: Multiple assets emit different content to the same filename

[andrewkittredge]

Using "custom-functions-metadata-plugin": "^1.5.3".

In webpack watch mode when I modify my functions.ts which is processed by

new CustomFunctionsMetadataPlugin({ input: "./scripts/office-js-addin/src/functions/functions.ts", output: "dist/functions.json" })

I get the error

ERROR in Conflict: Multiple assets emit different content to the same filename dist/functionsTest.json

I do not have anything else writing to dist/functionsTest.json

[andrewkittredge]

I think this might be because the comparison @ https://github.com/OfficeDev/Office-Addin-Scripts/blob/master/packages/custom-functions-metadata-plugin/src/customfunctionsplugin.ts#L60 is case sensitive but the path.resolve @https://github.com/OfficeDev/Office-Addin-Scripts/blob/master/packages/custom-functions-metadata-plugin/src/customfunctionsplugin.ts#L37 is not.

Windows should be case sensitive, also the path separator should be "/".

[KDean-Dolphin]

Adding support for this, carrying over from my discussion in Office-Add-in-samples.

Follow the quick start tutorial to create an add-in as follows:

Project type: Excel Custom Functions using a Shared Runtime
Script type: TypeScript

Then run:

npm run build
npm run start:desktop

The demo functions work as expected.

Next, edit functions.ts to add a sub() function (copy and paste of add with '+' replaced with '-'). Save the file. Back in Excel, multiple error messages are displayed:

ERROR in ./src/taskpane/taskpane.ts (/Users/kevindean/Projects/Excel Test/src/taskpane/taskpane.ts) 37:33-36
[tsl] ERROR in /Users/kevindean/Projects/Excel Test/src/taskpane/taskpane.ts(37,34)
TS2304: Cannot find name 'add'.

The above message repeats for all demo functions and for both taskpane.ts and command.ts.

The final message is this:

Conflict: Multiple assets emit different content to the same filename functions.json

One suggestion was to update the custom-funcions-metadata-plugin library (to 1.5.6 as of this writing):

npm run stop
npm install --save-dev custom-functions-metadata-plugin
npm run build
npm run start:desktop

That eliminates the repeating error messages related to the individual functions, leaving only the last one the moment that functions.ts is edited.

[KDean-Dolphin]

Any progress on this? This is a showstopper for add-in development.

[akrantz]

@MiaofeiWang It would be good to look at this.

I think this might even happen if a separate file unrelated to custom functions is modified. When the dev server rebuilds the code, it shouldn't encounter an error. It would be useful to understand why this happens with the plugin.

If a custom function definition is added, changed, or deleted, it would be ideal if it could re-register the custom functions with Excel. Not sure if that is feasible now. Currently it is expected that Excel needs to be restarted.

[KDean-Dolphin]

I tested plain JavaScript as well; the problem is not restricted to TypeScript.

[b-gonzalez]

I ran into this issue just now. It was because I added functions to the functions.ts file after I had started the project. To fix this, I closed out of the Excel and the addin. I rebuilt the add-in using npm run build. And then I restarted the project using npm run start:desktop. After I did that the add-in worked as expected.

[KDean-Dolphin]

I've gone through the comments and in particular that from @b-gonzalez and have run a few tests. I can confirm that there are problems with the following:

• Adding a function with a @customfunction annotation
• Deleting a function with a @customfunction annotation
• Changing the signature of a function with a @customfunction annotation

It's a little wonky with non-annotated functions as well, but only if they are exported, which is not really a concern.

So, in short, as long as functions aren't added or deleted or have their signatures changed, all is joy and happiness. I'm OK with that, as most of the development and debugging is in the functions themselves or the functions they call. Having to occasionally restart Excel because of the above is a minor nuisance by comparison, and frankly this issue has forced me to rearchitect my library in a way that is better decoupled from Excel.

I just have to keep in mind that, any time I do any of the above, I have to go through the following (documentation should be updated to reflect this):

npm run stop
npm run build
npm run start:desktop

The stop command is necessary because the start command saves the PID of the server, which fails the second time around because there's already a server running on the same port, which prevents any future stop command from working because it can't find the PID of the first, successful start.