Cannot access variable that is initialized when jQuery is ready

[bampakoa]

🐞 Bug report

Command (mark with an x)

- [ ] new
- [ ] build
- [x] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?

Yes, the previous version in which this bug was not present was: 8.0.6

Description

When a global variable is initialized inside a jQuery.ready callback, it is undefined when trying to be accessed from Angular code.

🔬 Minimal Reproduction

https://github.com/bampakoa/jquery-issue

1. npm install
2. ng serve
3. Check console error messages

🔥 Exception or Error

ERROR ReferenceError: App is not defined
    at AppService.show (app.service.ts:11)
    at AppComponent.ngOnInit (app.component.ts:36)
    at callHook (core.js:4847)
    at callHooks (core.js:4811)
    at executeHooks (core.js:4762)
    at executePreOrderHooks (core.js:4734)
    at refreshDescendantViews (core.js:11577)
    at renderComponentOrTemplate (core.js:11960)
    at tickRootContext (core.js:13242)
    at detectChangesInRootView (core.js:13278)

🌍 Your Environment

Angular CLI: 8.1.0-rc.0
Node: 10.15.3
OS: win32 x64
Angular: 8.0.3
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.801.0-rc.0
@angular-devkit/build-angular     0.801.0-rc.0
@angular-devkit/build-optimizer   0.801.0-rc.0
@angular-devkit/build-webpack     0.801.0-rc.0
@angular-devkit/core              8.1.0-rc.0
@angular-devkit/schematics        8.1.0-rc.0
@angular/cli                      8.1.0-rc.0
@ngtools/webpack                  8.1.0-rc.0
@schematics/angular               8.1.0-rc.0
@schematics/update                0.801.0-rc.0
rxjs                              6.4.0
typescript                        3.4.5
webpack                           4.35.0

Anything else relevant?

• The App object is initialized in this line.
• I have enabled Ivy compiler.

[mgechev]

We're serving scripts with script[type="module"], this means that they are automatically in strict mode.

In non-strict mode:

var App = function () {
  ...
};

Would make App global, but in strict mode it will not. I'd not recommend exposing globals but if you have to, the way to solve your problem is to update app.js:

window.App = function () {
  ...
};

[bampakoa]

@mgechev thanks for the feedback. What should we do if the script is from a 3rd party vendor and we cannot change it? This is a common case, especially in jQuery based plugins.

[mgechev]

You can disable differential loading, but still, not a recommendation. The best solution would be to use modern plugins which are compatible with strict mode.

[bampakoa]

Thanks again for your answer @mgechev . In our company, we are currently running two big projects that use a common theme, purchased from a 3rd party vendor. Scripts of the theme follow the principle that is described above.

We are now running Angular and CLI versions 8.0 Will this mean that we will not be able to upgrade to CLI 8.1 in the future? I think that this is something that the CLI team should consider.

[julianpoemp]

I have this problem, too. with:

• popper.js
• bootstrap-material-design.js
• ajv.js

@bampakoa we can use @angular-devkit/build-angular@8.00.6. With it it's working as it should be.

[cipchk]

Me to, but just only via ng s, working ng build.

[dbusacca]

This is a serious breaking change for who must use some old or broken third party library.

And is against what the angular guide itself says:

scripts | An object containing JavaScript script files to add to the global context of the project. The scripts are loaded exactly as if you had added them in a <script> tag inside index.html.

https://angular.io/guide/workspace-config

[clydin]

The behavior is part of how module-type scripts function. Script elements with a type of module are always in strict mode.
For more details on JavaScript modules, please see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
For details on strict mode, please see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode

If your application relies on behavior that is not supported in strict mode, ES2015 output can be disabled (and differential loading along with it) by changing the target field in the application's tsconfig to es5. The application will lose the benefits of the optimized output for newer browsers but the older third-party libraries will work.

[julianpoemp]

@mgechev can you please reopen this issue? It's not solved.

Is there an option in angular.json to disable the strict mode for third party scripts? I think there must be another way instead of disabling differential loading.

I'm sure there are a lot of people facing this issue, but can not change their third party scripts.

[bampakoa]

I do not think that disabling differential loading will solve any issues in my case. Our applications are working fine with Angular 8.0.3 and Angular CLI 8.0.6 with differential loading included. Here is our tsconfig.json file:

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "module": "esnext",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "importHelpers": true,
    "target": "es2015",
    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2018",
      "dom"
    ]
  }
}

[clydin]

Strict mode is an inherent property of module scripts and cannot be disabled independently.

However, the issue actually appears to be a defect in the ng serve HTML generation logic. It's currently being overzealous in its inclusion of type="module" attributes.

Trying the original authors reproduction with a build and manually serving resulting in a working application. However, ng serve did in fact exhibit the behavior.
Please note also that ng serve does not use differential loading and changing the target to es5 did fix the problem when running ng serve. However, this should not be necessary and a fix will be arriving shortly to correct the behavior of ng serve.

In addition, module scripts (and their inherent strict mode) are the future. Whenever possible, please consider updating code or notifying third-party library providers to request they make the transition.