Repository navigation
cannot require files with dynamic path anymore #3306
Description
Please provide us with the following information:
OS?
Mac os Siera
Versions.
v1.0.0-beta-21
Hi
We used to be able to to do this :
let path = 'test.component.ts';
let file = require('./path/to/file/'+path);
console.log('file',file);
But this is not working any more with the latest cli.
This works :
let file = require('./path/to/file/test.component.ts');
console.log('file',file);
So basically , webpack wont let me require file dynamically anymore in cli .
Activity
xe4me commentedon Dec 10, 2016
@TkachenkoAptem
How is this related to dynamic requires ?
[-]cannot load dynamic require anymore [/-][+]cannot require files with dynamic path anymore [/+]filipesilva commentedon Dec 29, 2016
We moved to using https://github.com/angular/angular-cli/blob/master/packages/@ngtools/webpack/README.md, which is more strict due to using
ngc. I think the reason your code doesn't work anymore is because it wouldn't work with AoT anyway.xe4me commentedon Dec 29, 2016
@filipesilva Why did you close this ?
Why it wouldn't work with ngc ?
I don't understand why and even if it's not gonna work with AOT, I think your loader or cli itself should be smart enough to give me the option of not using AOT.
You can't just eliminate all the world and force them to use AOT, doesn't make sense at all.
filipesilva commentedon Dec 29, 2016
Have you tried to see if it works with ngc?
You have to remember that
requiredoes not exist in the browser, it's a keyword that only exists in node. Angular is at the end of the day a front-end framework and not a node framework.requireworks in Webpack apps overall but it doesn't work in, say, SystemJS.It's also important to get people used to using AoT rules by default otherwise they will just be very disappointing when their app does not work with AoT. They wouldn't even know how to start fixing all the errors that AoT compilation would show them.
That is why the CLI made the choice to default to AoT. I understand that you might not be interested in AoT at all though, but this is the choice we made and we stand by it. If you absolutely need dynamic imports via
require, then the CLI might not be the best choice for your project.xe4me commentedon Dec 30, 2016
Thanks @filipesilva for your quick response.
Yes I know what require exactly doing , and I know that webpack will create a regex of all the possible path when you do require('./'+path) and then makes them available when you actually require them in the browser.
FYI , webpack will create a function called require and will make it available in the browser too.
There is absolutely no reason why it wouldn't work with this method because ngc cares about your component and creates a ngFactory of them , and for that , as far I know , I'll check your declaration list and your entryComponent list ( I might be wrong because there is no doc about it).
All this aside, let's say I want to load a json file ( not a component ) like bellow :
let my jsonFile = require('./src/jsons/'+aVariable);So I just want to load this file later in the browser. ( we've been doing this more than 100 years);
There is absolutely no technically reason why above shouldn't work with AOT and if it doesn't , there is no reason for my company to use Angular altogether !.
With this, you're simply saying Angular doesn't let you create a dynamic component anymore and you should just create a simple form and that's it.
And by the way, "but this is the choice we made and we stand by it" : Thanks for caring about the community .
I'm 100% sure there are heaps of other companies like us needing this simple feature.
filipesilva commentedon Dec 30, 2016
Ok, so you understand how the dynamic chunks are created in webpack. But have you considered how that affect AoT compilation? It's way more strict and tries to statically analyse your code.
It doesn't allow for components or directives that are not in an
NgModulefor instance. That would happen if you dynamically load a component.ngcdoesn't really know about webpack (nor should it) so it can't possibly figure out what dynamic chunks have at a Typescript level.That being said this is only reasoning, and I admit that in practice it might work except for some bug present in the CLI or the AoT loader.
It's true that webpack users are used to dynamically lazy loading chunks via webpack's mechanism, I don't deny it. It does work as far as the actual loading of them is considered, aka the raw code can be made available at a later date, but getting it to work properly in the framework context is another matter entirely.
The mechanism available in Angular to ensure it works is lazy loading through the router. Which doesn't work for the dynamic chunk scenario you're proposing, but to be fair I don't think there's a way to both have completely dynamic chunks and both have them be statically analysable at the moment.
Overall in the CLI we tried to completely remove any trace of node/webpack specific code like
requireormodule.idso that users wouldn't rely on Webpack functionality. So even though JSON loading viarequiremight work, it's not something the CLI encourages or cares much about. The only reason there are even node typings in CLI generated apps is because Protractor needs it.So while I recognise that usecase is wholly legitimate from a webpack point of view, it's not very important from a CLI point of view.
I don't have a lot of interest in discussing the issue at length because there a lot of other issues that are also awaiting a response. The best I can do is refer you to places where you can identify the issue in an effort to help:
Issues for the AoT loader are also submitted in this repo, but the usecase might be out of scope. I'm not the one who coded it so am not 100% sure.
xe4me commentedon Feb 21, 2017
@filipesilva
I can see that this is now fixed, despite all your disagreements :).
Thanks anyways.
filipesilva commentedon Feb 21, 2017
@xe4me we ended up fixing a related bug that unlocked this functionality in #4153.
angular-automatic-lock-bot commentedon Sep 6, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.