# Bundling Remote Scripts with Webpack

DevFeed: [Bundling Remote Scripts with Webpack](<https://devfeed.tech/articles/bundling-remote-scripts-with-webpack-19043.md>)

Original publisher: [Read original article](<https://httptoolkit.com/blog/bundling-remote-scripts-with-webpack/>)

Author: HTTP Toolkit; Tim Perry

Published: 2019-02-07T16:45:00Z

Content type: tutorial

Language: en

Sources: [HTTP Toolkit](<https://devfeed.tech/sources/http-toolkit.md>)

Topics: [Webpack](<https://devfeed.tech/topics/webpack.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [npm](<https://devfeed.tech/topics/npm.md>), [Code](<https://devfeed.tech/topics/code.md>), [Promise](<https://devfeed.tech/topics/promise.md>), [SDK](<https://devfeed.tech/topics/sdk.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [js-sdk](<https://devfeed.tech/tags/js-sdk.md>), [node](<https://devfeed.tech/tags/node.md>), [npm](<https://devfeed.tech/tags/npm.md>), [script](<https://devfeed.tech/tags/script.md>), [webpack](<https://devfeed.tech/tags/webpack.md>)

## AI overview

This tutorial explains how to bundle JavaScript files that are available only from remote CDNs. It presents webpack's val loader, which executes a Node module at build time, waits for an exported function or promise, and bundles the resulting content through an import or require.

## Source excerpt

As a JavaScript developer nowadays, almost everything you use comes from npm. Unfortunately, not absolutely everything: there's still a small subset of scripts that expect to be included from a remote CDN somewhere, and when bundling your application these pose a problem. You could use these scripts from the CDN, as intended. If you do so you'll lose opportunities for bundling benefits like tree shaking, but more importantly you now have to independently load scripts from one more domain at the same time as your other bundle(s). That means another point of failure, and means you need logic in your main app to wait until the remote script has loaded before using it, and to potentially handle loading failures too. Instead, you could download the script directly, save it into your codebase ('vendor' it), and treat it like your own source. What if it changes though? Many of these CDN scripts change frequently, so you'll need to repeatedly update this, and every change is extra noise and mess in your codebase & git history. I hit this recently working on HTTP Toolkit trying to use the JS SDK for a 3rd party service, which is only available from a CDN, and isn't published on npm. Fortunately, there's another option: webpack can solve this for us. Val Loader Webpack's little-known val loader allows you to easily define your own loading logic that is run at build time. When you load a file with most webpack loaders they read the file, transform the content somehow, and add some content to your bundle, which will later be returned from the initial import/require statement. When you load a file with val loader however it: Executes the file contents as a node module Looks for an exported function or promise from the module Waits on the promise/calls the function (which may in turn return a promise) Takes the code property from the final result, and uses this as the content to be bundled and returned by the original import/require This means you can write a simple node script t