Publish an add-in using Visual Studio Code and Azure - Suggestion for improvement

[SussexGooner]

Article URL
https://learn.microsoft.com/en-us/office/dev/add-ins/publish/publish-add-in-vs-code#using-visual-studio-code-to-publish

Describe the problem
I am using the instructions on to deploy an office addin to Azure. It works great but I have a suggestion for improvement to the process. Step 9 reads:

9. Open your project's manifest file (manifest.xml) and change all references to your localhost URL (such as https://localhost:3000) to the URL you've copied. This endpoint is the static website URL for your newly created storage account. Save the changes to your manifest file.

There are two issues with this step. First, after deploying to Azure, I start working on the development side again and I have to undo this change. Second, all of my code is under source control and I have to take care to know what state the manifest file is in before checking in my changes.

To avoid this problem, I edited the webpack.config.js file. I replaced urlProd with the URL from step 8 and removed the trailing / from urlProd and urlDev. This last step was necessary so that the https://localhost:3000 gets updated correctly. I believe that this means that the manifest in the dist folder is correct and I no longer need to do step 9. Thus, step 9 could be amended to
be

9. Open your project's webpack.config.js file. Change urlProd to be the URL you just copied. Remove the trailing "/" from both urlDev and urlProd. Save the changes to webpack.config.js.

Step 13 would then be changed:

13. Finally, sideload the manifest file from the dist folder (https://learn.microsoft.com/en-us/office/dev/add-ins/testing/sideload-office-add-ins-for-testing) and the add-in will load from the static web site you just deployed.

I am sure that the removal of the trailing / could be implemented in the transform(content) section of the webpack.config.js file rather than manually in step 9 but that would involve changing yeoman's addin creation.

thanks,

[Rick-Kirkham]

@SussexGooner Can I get some clarification about what you mean by "start working on the development side again"?

Do you mean that you've moved the add-in to production and now want to work on developing the next version? Or do you mean that you encountered a bug/problem when running on the Azure URL and you are going back to development to fix it? Or some third thing?

[SussexGooner]

Hi, I'm switching back to developing the next version.

It looks like the instructions as currently written avoids a bug in the set up of webpack.config.js by yeoman (I think). The webpack.config.js seems to do everything right but it does not handle the AppDomain correctly. This is because in the AppDomain you do not include the trailing "/"

https://localhost:3000

If this were fixed then I believe that the manifest file in the dist directory is correct and can be used.

[Rick-Kirkham]

1. Now, I'm unclear on what you mean by "AppDomain". There can be one or more <AppDomain> elements in the manifest, but the string "AppDomain" is not in webpack.config. Normally, the localhost domain will NOT be a value of an <AppDomain> element, so the transform part of webpack.config won't change any of these elements.

2. I think it's standard to fork/branch source code into dev and prod forks/branches. If you did that, then carry out the manifest changes only in the prod fork/branch. You could then resume work in the dev fork/branch without having to reverse anything. When you're ready to move the next version to prod, just merge dev to prod and repeat the changes to the manifest. You'd only be doing that once per version. Would this work for you?