Skip to content

Instantly share code, notes, and snippets.

@gotdibbs
Last active August 15, 2017 15:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gotdibbs/70c808e600724a404c2ca257ca8c9c36 to your computer and use it in GitHub Desktop.
Save gotdibbs/70c808e600724a404c2ca257ca8c9c36 to your computer and use it in GitHub Desktop.
Webpack for Dynamics 365
module.exports =
module: {
loaders: [
{
test: /\.(ttf|eot|woff|woff2)$/,
loader: `url-loader?limit=5000&name=fonts/[name].[ext].css`
}
// ... rest of loaders ...
]
}
// ... rest of webpack config ...
};
module.exports = {
plugins: [
new webpack.LoaderOptionsPlugin({
options: {
customInterpolateName: (loaderContext) => {
return loaderContext.replace(/-/g, '');
}
}
})
// .... rest of plugins ...
]
// ... rest of webpack config ...
};
module.exports = {
output: {
sourceMapFilename: 'map.[file]',
filename: '[name].js'
/// ... rest of output config ...
}
// ... rest of webpack config ...
};
module.exports =
module: {
loaders: [
{
test: /\.svg/,
use: {
loader: 'svg-url-loader',
options: {}
}
}
// ... rest of loaders ...
]
}
// ... rest of webpack config ...
};

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

Unsupported File Types - Fonts

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.

<script src="https://gist.github.com/gotdibbs/4f58a0c7c2cbf8b11722fb32e51fd726.js?file=webpack.config-fonts.js"></script>

Unsupported File Types - SVG

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.

<script src="https://gist.github.com/gotdibbs/4f58a0c7c2cbf8b11722fb32e51fd726.js?file=webpack.config-svg.js"></script>

Filename Special Character Restrictions

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.

<script src="https://gist.github.com/gotdibbs/4f58a0c7c2cbf8b11722fb32e51fd726.js?file=webpack.config-hyphen.js"></script>

Sourcemaps

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.

<script src="https://gist.github.com/gotdibbs/4f58a0c7c2cbf8b11722fb32e51fd726.js?file=webpack.config-sourcemap.js"></script>

Conclusion

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment