<script src="node_modules/@webcomponents/webcomponentsjs/webcomponents-loader.js"></script> should load without throwing an error.
TypeError: script is null[Learn More]
webcomponents-loader.54a01869.js:249:9
parcelRequire<[84]</<
http://localhost:61333/webcomponents-loader.54a01869.js:249:9
parcelRequire<[84]<
webcomponents-loader.js:11
newRequire
http://localhost:61333/webcomponents-loader.54a01869.js:48:7
parcelRequire<
http://localhost:61333/webcomponents-loader.54a01869.js:75:5
<anonymous>
http://localhost:61333/webcomponents-loader.54a01869.js:10:18
I'm trying to use Parcel for a Polymer 3 app. Polymer 3 apps rely on Custom Elements V1, which is not supported by all browsers (e.g. Firefox 60). The @webcomponents/webcomponentsjs/webcomponentsjs-loader.js script detects what features are missing and dynamically loads the appropriate polyfills. It is possible to use @webcomponents/webcomponentsjs/webcomponents-bundle.js, but it increases the size by ~91k for browsers that don't require a polyfill. The reason that webcomponentsjs-loader.js fails can be observed in the following code:
var script = document.querySelector('script[src*="' + name +'"]');
var newScript = document.createElement('script');
// Load it from the right place.
var replacement = 'bundles/webcomponents-' + polyfills.join('-') + '.js';
var url = script.src.replace(name, replacement);
newScript.src = url;
// if readyState is 'loading', this script is synchronous
if (document.readyState === 'loading') {
// make sure custom elements are batched whenever parser gets to the injected script
newScript.setAttribute('onload', 'window.WebComponents._batchCustomElements()');
document.write(newScript.outerHTML);
document.addEventListener('DOMContentLoaded', ready);
} else {
newScript.addEventListener('load', function () {
asyncReady();
});
newScript.addEventListener('error', function () {
throw new Error('Could not load polyfill bundle' + url);
});
document.head.appendChild(newScript);
}
They're referring to the script by name, but Parcel has changed it.
One possibility I've seen discussed before is to provide a way to tell Parcel to not process a dependency.
I encountered this problem as well. I tried to use the --no-content-hash option but I guess that's not what it's for because it still mangles the names. The setting says:
--no-content-hash disable content hashing
Okay, it doesn't hash it, then why is my file named: dist/webcomponents-loader.f9867c3d.js ? The random hex string changes if I add or remove that cli flag, but there is always a number. Is one a hash and one just a random string?
Still a bug since July eh?
There are 599 open issues with this project right now, but there are over 1000 issues closed. I am impressed with this project and have faith that this issue will be resolved eventually.
@ErikGrimes Did you ever find a workaround?
I've found that if I comment out the webcomponents-loader.js script tag, and then put it back in it works fine. Another alternative was to not target the html file and instead just build the script files you need to build. Anyhow, just dodge that file for now so it doesn't get processed at all.
@adjenks I created a workaround for this a few months ago: https://www.npmjs.com/package/parcel-plugin-webcomponents
It just adds the webcomponensjs scripts to all builds without the hash and imports webcomponents-loader.js in the bundled HTML. It's pretty basic but maybe this is already sufficient for your use case.
@Cortys Thank you.
I still look forward to a real fix though.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.
Most helpful comment
@adjenks I created a workaround for this a few months ago: https://www.npmjs.com/package/parcel-plugin-webcomponents
It just adds the webcomponensjs scripts to all builds without the hash and imports
webcomponents-loader.jsin the bundled HTML. It's pretty basic but maybe this is already sufficient for your use case.