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












17















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).










share|improve this question

























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

    – Aljosha Novakovic
    Nov 19 '18 at 17:28











  • @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.

    – Joe Almore
    Nov 19 '18 at 17:34











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

    – Dipen Shah
    Nov 19 '18 at 18:09













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

    – Joe Almore
    Nov 19 '18 at 19:41











  • run npm install in your project directory

    – Har Kal
    Nov 19 '18 at 20:03
















17















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).










share|improve this question

























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

    – Aljosha Novakovic
    Nov 19 '18 at 17:28











  • @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.

    – Joe Almore
    Nov 19 '18 at 17:34











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

    – Dipen Shah
    Nov 19 '18 at 18:09













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

    – Joe Almore
    Nov 19 '18 at 19:41











  • run npm install in your project directory

    – Har Kal
    Nov 19 '18 at 20:03














17












17








17


1






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).










share|improve this 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).







javascript angular es6-module-loader






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 28 '18 at 17:37







Joe Almore

















asked Nov 15 '18 at 23:10









Joe AlmoreJoe Almore

1,34752956




1,34752956













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

    – Aljosha Novakovic
    Nov 19 '18 at 17:28











  • @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.

    – Joe Almore
    Nov 19 '18 at 17:34











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

    – Dipen Shah
    Nov 19 '18 at 18:09













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

    – Joe Almore
    Nov 19 '18 at 19:41











  • run npm install in your project directory

    – Har Kal
    Nov 19 '18 at 20:03



















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

    – Aljosha Novakovic
    Nov 19 '18 at 17:28











  • @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.

    – Joe Almore
    Nov 19 '18 at 17:34











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

    – Dipen Shah
    Nov 19 '18 at 18:09













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

    – Joe Almore
    Nov 19 '18 at 19:41











  • run npm install in your project directory

    – Har Kal
    Nov 19 '18 at 20:03

















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

– Aljosha Novakovic
Nov 19 '18 at 17:28





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

– Aljosha Novakovic
Nov 19 '18 at 17:28













@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.

– Joe Almore
Nov 19 '18 at 17:34





@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.

– Joe Almore
Nov 19 '18 at 17:34













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

– Dipen Shah
Nov 19 '18 at 18:09







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

– Dipen Shah
Nov 19 '18 at 18:09















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

– Joe Almore
Nov 19 '18 at 19:41





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

– Joe Almore
Nov 19 '18 at 19:41













run npm install in your project directory

– Har Kal
Nov 19 '18 at 20:03





run npm install in your project directory

– Har Kal
Nov 19 '18 at 20:03












1 Answer
1






active

oldest

votes


















7





+125









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.






share|improve this answer


























  • 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.

    – Joe Almore
    Nov 28 '18 at 17:45











  • @JoeAlmore, there's no reason that should happen

    – Eliran Malka
    Nov 29 '18 at 9:41











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53329161%2fes6-module-loader-cannot-locate-angular-core-in-angular-6%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









7





+125









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.






share|improve this answer


























  • 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.

    – Joe Almore
    Nov 28 '18 at 17:45











  • @JoeAlmore, there's no reason that should happen

    – Eliran Malka
    Nov 29 '18 at 9:41
















7





+125









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.






share|improve this answer


























  • 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.

    – Joe Almore
    Nov 28 '18 at 17:45











  • @JoeAlmore, there's no reason that should happen

    – Eliran Malka
    Nov 29 '18 at 9:41














7





+125







7





+125



7




+125





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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 29 '18 at 19:49

























answered Nov 28 '18 at 9:49









Eliran MalkaEliran Malka

12.6k46088




12.6k46088













  • 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.

    – Joe Almore
    Nov 28 '18 at 17:45











  • @JoeAlmore, there's no reason that should happen

    – Eliran Malka
    Nov 29 '18 at 9:41



















  • 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.

    – Joe Almore
    Nov 28 '18 at 17:45











  • @JoeAlmore, there's no reason that should happen

    – Eliran Malka
    Nov 29 '18 at 9:41

















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.

– Joe Almore
Nov 28 '18 at 17:45





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.

– Joe Almore
Nov 28 '18 at 17:45













@JoeAlmore, there's no reason that should happen

– Eliran Malka
Nov 29 '18 at 9:41





@JoeAlmore, there's no reason that should happen

– Eliran Malka
Nov 29 '18 at 9:41




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53329161%2fes6-module-loader-cannot-locate-angular-core-in-angular-6%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Bressuire

Vorschmack

Quarantine