diff --git a/web/index.html b/web/index.html
index 92dfb169..78a1a14a 100644
--- a/web/index.html
+++ b/web/index.html
@@ -5,7 +5,7 @@
DataHarmonizer
-
+
diff --git a/web/webpack.config.js b/web/webpack.config.js
index 2624b4fc..3cffcf63 100644
--- a/web/webpack.config.js
+++ b/web/webpack.config.js
@@ -11,6 +11,7 @@ module.exports = (env, argv) => {
filename: 'scripts/[name].js',
},
externals: {
+ // Schemas lib external to this webpack build. Imported in html file.
schemas: 'schemas',
},
plugins: [
@@ -54,14 +55,25 @@ module.exports = (env, argv) => {
},
};
+ // Difficult to run two webpack instances on a single dev server (i.e., this
+ // file, and the other webpack file that builds schemas). So for dev servers,
+ // we will insert all schema content into the webpack build generated by this
+ // file, and this singular build serves the entirety of the application. This
+ // is fine, because the whole point of having a separate build for schema
+ // content was to reduce production build times when users are only editing
+ // schema files (and not the rest of the application), but the dev server
+ // already gets around this problem through hot loading.
if (argv.mode === 'development') {
config.devtool = 'eval-source-map';
+ // The schemas lib will come from a direct import of the javascript, instead
+ // of embedding an external lib into the html
config.resolve = {
alias: {
schemas: path.resolve(__dirname, 'schemas.js'),
},
};
delete config.externals;
+ // Need pdf SOPs that schema build previously supplied
config.plugins.push(
new CopyPlugin({
patterns: [
@@ -73,6 +85,7 @@ module.exports = (env, argv) => {
],
})
);
+ // False emits don't play nice with dev servers either
for (const rule of config.module.rules) {
if (rule.hasOwnProperty('generator')) {
delete rule.generator.filename;