🐞 bug report

Affected Package Angular 8

Is this a regression? YES

Description

My production distribution is being served from Azure Blob Storage static site. Is it possible that serving from the static site is causing this error?

This issue happens in Chrome but not Edge.

After upgrading to Angular 8, production builds can't load. Browser console error: Failed to load module script: The server responded with a non-JavaScript MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.

🔬 Minimal Reproduction

Upgrade an Angular 7 app to Angular 8. Do production build, deploy the production build to Azure Blob storage static web site and attempt to open it.

🔥 Exception or Error

Failed to load module script: The server responded with a non-JavaScript MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.

🌍 Your Environment

Angular Version:

Angular CLI: 8.0.1
Node: 11.6.0
OS: win32 x64
Angular: 8.0.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.800.1
@angular-devkit/build-angular     0.800.1
@angular-devkit/build-optimizer   0.800.1
@angular-devkit/build-webpack     0.800.1
@angular-devkit/core              8.0.1
@angular-devkit/schematics        8.0.1
@angular/cdk                      7.3.7
@angular/cli                      8.0.1
@angular/material                 7.3.7
@ngtools/webpack                  8.0.1
@schematics/angular               8.0.1
@schematics/update                0.800.1
rxjs                              6.5.2
typescript                        3.4.5
webpack                           4.30.0

You must change the property "target" in the file "tsconfig.json" to "es5". Read this blog entry, "Differential Loading by Default":

https://blog.angular.io/version-8-of-angular-smaller-bundles-cli-apis-and-alignment-with-the-ecosystem-af0261112a27

This property chooses between modern or legacy JavaScript based on the browser capabilities:

<script type="module" src="…"> // Modern JS

<script nomodule src="…"> // Legacy JS

@Aurora7Sys

I found the source of the problem. Angular 8 removed -- type="text/javascript" from the script tags in index.html. Angular 7 had them which is why it worked with Azure Storage.

We also discovered that the Azure portal manual upload did not add the MIME metadata to .js files that were uploaded. So... when I manually uploaded my Angular 8 site, it produced the above errors.

I started using Visual Studio Code to publish my Angular 8 apps to Azure Storage and it's working because the publish extension adds the correct MIME metadata to the files.

Microsoft will look into correcting the Azure portal manual upload to add the MIME metadata so this can't happen on their server.

@alan-agius4

Why is this closed? This is a regression. ng7 created a proper index.html. At least in some situations, ng8 does not. I have not seen a single "solution" that was not a work-around for an ng8 flaw and unrelated to the consumer's code. ng8 should not be creating ambiguous script tags.

I got the same problem when I host the files on AWS S3. The problem is from the "type='module'", I had to manually change it into "type='text/javascript'" to make it work again.

Why "type='module'" in Angular 8, I'm wondering? What is the benefit of it over "type='text/javascript'" ?

I am not so sure this should be closed or sent off to Stack Overflow just yet.
You can reproduce this problem with a brand new version 8.02 "hello world" app generated from the CLI.
The exact same version 7 app has always worked just fine and still does up on Azure storage.
So, since there is not really anything we can do to reconfigure Azure Storege, what can we do to get Version 8 apps running up there? Something has changed that broke this capability and free hosting is a pretty good reason to use Angular. :)

Version 8 apps Do work fine on a "real" web server though.

Thanks!