These days if you're building any complex custom UI, you're going to come across webpack, and for good reason. What is webpack? It's a build tool that you can read more about here.
Webpack is great, but when using it with D365 you will likely encounter a few bumps down the road. You'll likely notice that you are unable to load SVG or Font assets into D365, stumble across the restrictions on which characters can appear in web resource filenames, and flip a table over trying to get sourcemaps into D365 as well.
How do we get around these hurdles? The most obvious answer might be to use the url-loader
module to embed your assets as Data URIs. That approach may work out fine in some cases, but there's a whole host of very valid reasons not to use the Data URI approach. Since we've got some significant downsides, let's take a look at other approaches to solving each of our problems.
Note: the below examples are targeting v3.4.1 of webpack
The way around most unsupported file types we care about is to append .css
. We primarily use this for font files however. All you need to do to fix this in webpack-land is to adjust your output name pattern such that .css
is appended, and you're all set. Therefore a font called something like awesomebold.ttf
would become awesomebold.ttf.css
.
While we have support for SVG web resources supposedly coming in the next release, how do we handle this until then? You could certainly go with the same append .css
to the filename trick we used for fonts, but in our experience we like another approach. We find our SVG assets do not change all that often, and are generally pretty small, so one would think we might lean back towards the url-loader
approach mentioned above. And we do. Kinda. url-loader
always does Base64 encoding of your assets, but SVG under the hood is just XML. As it is therefore human readable we prefer to pull the XML in pretty much as-is with svg-url-loader
.
If you've dealt with web resources for more than a hot second, you've likely stumbled across the fact that D365 will not allow you to name a web resource with a hyphen in it. According to the docs they technically only support:
[The] name can only include letters, numbers, periods, and nonconsecutive forward slash ("/") characters.
This means no hyphens. These are pretty darn common in asset filenames though, so thankfully we have a way around it! What we typically do here is simply ask webpack to strip out the hyphens using the customInterpolateName
option. While the customInterpolateName
option is not well documented, it is certainly available for us to hook into and thus solves our problem.
While it is arguable whether or not you want to store a sourcemap in D365, for homegrown applications these can be very handy for debugging, especially if you're not using something awesome like Imposter for Fiddler. Thankfully getting these into D365 is fairly easy. What we can do is use something similar to our first trick. In this case we prepend the word map
as transforming the filename in any other way doesn't seem to work in all cases. Again, here we only need a quick change to our webpack config and we're off to the races.
So you see, with a few simple tweaks to our webpack config, we can now use just about any resources we want. Make a few config updates, kick off a new webpack build, and you've got your assets all set and ready to be uploaded to D365.
Have you come across any other issues with web resource development in D365 that you've yet to solve? We'd love to hear about them in the comments!