es6-module-loader cannot locate @angular/core in Angular 6

Question

I used this es6-module-loader in an Angular 2 project and it worked great for loading TypeScript modules in real time in the web-browser. Now, I am upgrading this project to Angular 6, but here the dependencies are not met for the imports of the loading module. For example:

declare var SystemLoader:any;

export class DemoClass {
  constructor() {
    var source = "export class Foo { " +
    "constructor() { console.log('Created the ES6 class foo!'); } " +
    "execMethod() { console.log('Executed method!') }" +
    "}";

     SystemLoader.module(source, {name: _name}).then(function (module: any) {
        module.Foo.prototype.execMethod();
     }
  }
}

This previous code works in Angular 6. It will load the module Foo and print those lines in the Console. But if I get the module a little complexity and add some import like this:

declare var SystemLoader:any;

export class DemoClass {
  constructor() {
    var source = "import {Component} from \"@angular/core\"; " +
    "export class Foo { " +
    "constructor() { console.log('Created the ES6 class foo!'); } " +
    "execMethod() { console.log('Executed method!') }" +
    "}";

     SystemLoader.module(source, {name: _name}).then(function (module: any) {
        module.Foo.prototype.execMethod();
     }
  }
}

Then it won't work and complains with error 404 loading @angular/core. So, in Angular 2 this was no problem because all the node_modules required for the project where loaded by Angular as is, but in Angular 6 it seems like all those dependencies are all shewed by Webpack and spitted all in one big fat JavaScript file. So, how can I get around this Webpack simplification so that the dynamic module can load?

Edit:

Or at least a sample to migrate from es6-module-loader(deprecated) to es-module-loader using the same process exposed above (loading source code, compile [transpile] and render in the client's machine).

Michelinamicheline

Are you using Angular CLI? Also, have you tried deleting all of your node modules, and re-installing? (just re-running npm install) – Surgery

@AljoshaNovakovic It is not related to a bad installation in the development environment, the issue happens during run-time only once the files are loaded into the server. There the files are all simplified and use other names due to the action of Webpack. – Michelinamicheline

@JoeAlmore Are you sure the problem is not due to source string? It should be "import { Component } from '@angular/core'; " + – Laquanda

@DipenShah Sorry the string wasn't escaped, just fixed the typo. – Michelinamicheline

run npm install in your project directory – Familial

@JoeAlmore es6-module-loader is deprecated so there could be something amiss with the support. Try upgrading to es-module-loader – Kelson

@Royson, certainly the es6-module-loader is deprecated, but is used to work very well for Angular 2. The main issue I have had migrating to es-module-loader is the lack of samples, with es6-module-loader it is quite simple as the samples I show above, but es-module-loader has no samples likes these above, which leads me to think that this type of loading/transpile is not supported by es-module-loader. Can you provide any sample with es-module-loader like the ones I show above? – Michelinamicheline

Answer 1

I'm not familiar with angular 6, but the issue seem to stem from webpack's module resolution process, where the module loader does not have a chance to pick up that module dependency at compile time. there can be couple of ways to address this.

You might do away just adding @angular/core as an external dependency, assuming it's declared in a compatible fashion (as common-js, umd etc.). If it's not already declared that way, you can always create a wrapper around it to expose it, e.g. as a common-js module.

Another way is to have a code-split point at this dependency (either with dynamic imports or require.ensure). I'm not sure it will do, but if the relevant angular loader (the one that parses the source text into source code) has its chance to work, and its output is compiled code, it might.

Grilse

Yes, but if I create a wrapper to expose the dependencies, then I would be loading the dependencies twice in the client's machine, one from webpack and one for the wrapper. – Michelinamicheline

@JoeAlmore, there's no reason that should happen – Grilse