Repository navigation
Barrel file imports not updating correctly on dev-server #12589
Description
Bug Report or Feature Request (mark with an x)
- [x] bug report
- [ ] feature request
Command (mark with an x)
- [ ] new
- [ ] build
- [x] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Versions
Windows 10
Node v8.11.1
Yarn V1.5.1
Angular CLI: 6.2.4
Node: 8.11.1
OS: win32 x64
Angular: 6.1.9
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router
Package Version
@angular-devkit/architect 0.8.4
@angular-devkit/build-angular 0.8.4
@angular-devkit/build-optimizer 0.8.4
@angular-devkit/build-webpack 0.8.4
@angular-devkit/core 0.8.4
@angular-devkit/schematics 0.8.4
@angular/cdk 6.4.7
@angular/cli 6.2.4
@angular/elements 6.1.10
@angular/material 6.4.7
@angular/material-moment-adapter 6.4.7
@ngtools/webpack 6.2.4
@schematics/angular 0.8.4
@schematics/update 0.8.4
rxjs 6.2.2
typescript 2.9.2
webpack 4.20.2
Repro steps
Import something through multiple barrel files with an alias wildcard: 'import * as fromTest from "../../test"'. And rename an imported variable. After renaming both the exported value and the imported name, the compiler still reports an error and the application crashes in the browser.
The log given by the failure
When renaming fromTest.thisIsFoo to -> fromTest.thisIsBar, this error and warning are given after renaming the imported name (which is expected behaviour):
However, after renaming the exported value to thisIsBar the error + warning should dissapear. But the warning is still thrown and the application breaks...
Only after modifying each index.ts barrel file leading to the thisIsBar const will the warning dissapear OR after re-running ng serve.
Desired functionality
The exported values from the barrel files seem to be cached or something, it would be better if such renames (which happen very often) trigger a reload of those barrel files.
Mention any other details that might be useful
This just recently came to our attention when updating to the Angular CLI v6, befire that we were running a custom webpack config from an ejected CLI project and this never happened thus far.
Activity
[-]Barrel file imports not updating correcly on dev-server[/-][+]Barrel file imports not updating correctly on dev-server[/+]binu101 commentedon Oct 15, 2018
After trying to fix this for myself by replacing the * as wildcard imports with named imports from those barrel files, the issue still persists..
The only way for me to be able to rename an exported member is when the import references the file directly, thereby eliminating my index.ts files completely..
I just rolled my repo back to my previous webpack 3 config to see if we'd simply never encountered this error, but following my repro steps the previous setup does work and updates the references correctly.
Edit:
Discovered that it has nothing to do with lazy loading modules, also occurs when reprocucing in appComponent. Any import through barrel file can't be renamed without restarting the dev-server...
binu101 commentedon Oct 15, 2018
As a test, created a new CLI v6 project created a two-level folder structure with an index on each level and imported this in the AppComponent, problem is also present.
How come this was not the case with the older CLI and/or an ejected webpack config?
alan-agius4 commentedon Oct 15, 2018
This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via
ng new repro-appand adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.This might be related to your directory structure so its really important to get an accurate repro to diagnose this.
binu101 commentedon Oct 15, 2018
https://github.com/binu101/repro-angularcli-12589
angular-automatic-lock-bot commentedon Sep 8, 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.