Repository navigation
Improve absolute import parsing for editors by moving baseUrl #7964
Description
Bug Report or Feature Request (mark with an x)
- [] bug report -> please search issues before submitting
- [x] feature request
Versions.
@angular/cli: 1.4.4
node: 6.11.3
os: linux x64
@angular/animations: 4.4.4
@angular/common: 4.4.4
@angular/compiler: 4.4.4
@angular/core: 4.4.4
@angular/forms: 4.4.4
@angular/http: 4.4.4
@angular/platform-browser: 4.4.4
@angular/platform-browser-dynamic: 4.4.4
@angular/router: 4.4.4
@angular/cli: 1.4.4
@angular/compiler-cli: 4.4.4
@angular/language-service: 4.4.4
typescript: 2.3.4
Repro steps.
This improvements refers mainly to vscode/#24362 but i think it will be reproduced by other editors in the future as well. Currently the main (and only) typescript config file parsed by editors is tsconfig.json. Since the files ./src/tsconfig.app.json and ./src/tsconfig.spec.json both contains"baseUrl": "./" but there is no baseUrl property in ./tsconfig.json which they both extend there is no way for the common editor to know what the main baseUrl is and it will struggle with resolving and refactoring absolute imports (although compiling with ng build works fine).
The log given by the failure.
For example just "out of the box" app after ng new and changing one relative import to absolute one produces :
Desired functionality.
if (as I wrote here) the baseUrl property will be moved from ./src/tsconfig.app.json and ./src/tsconfig.spec .json files to ./tsconfig.json and it will hold there "baseUrl": "./src/" it will solve the issue and will create better parsing for other editors in the future.
Activity
delasteve commentedon Oct 7, 2017
This has been discussed at length multiple times. Currently, the team thinks it's best how it is and if you would like to use absolute paths, you will have to change it yourself.
(Some) Relevant issues/PRs:
#5875
#6861
filipesilva commentedon Oct 8, 2017
I think @delasteve's answer covers the why of things right now pretty well.
It's important to note that in #5875, the problem was that having
baseUrlset meant vscode defaulted to using absolute urls. That is unexpected and wouldn't work well with completion for e2e specs.I think this is overall a small QoL adjustment that any user can do to their project. I don't think it should be the default because:
nitzano commentedon Oct 8, 2017
@filipesilva can you please demonstrate why it would mess up path completion for e2e specs or multi-app setups?
Also just to add more views: vscode project itself is using absolute imports over relative ones and using absolute imports is even preferred in other languages (e.g Python). Also just checked with latest vscode 1.17.0 that comes with import resolving and it didn't fallback to absolute imports automatically but let the user choose how to solve it (relative imports were even the first option after baseUrl was set).
All in all I can do this change for myself and adjust it in my project but it made more sense to maybe not to have baseUrl at all in
./src/tsconfig.app.jsonand./src/tsconfig.spec.jsonover currently compiling withbaseUrlin them but editing without the editor knowing about it as these files are ignored.I agree that this is a small change that any user can do but without it absolute import paths won't work "out of the box" in a new app.
filipesilva commentedon Oct 10, 2017
Well if you change
"baseUrl": "./src/"you're telling your editor that./src/is where your code is. But the e2e tests are not in./src/, they are in./e2e/.And if you have multiple apps under
./src/, for instance./src/app1and./src/app2/, then your baseUrl will be incorrect for all of them.Your change works for your specific case because you have a single app and don't care much about the e2e folder, but that's not generalizable to all cases the CLI covers. So that would be a bad default to add.
victornoel commentedon Oct 26, 2017
@filipesilva I see you reopened this issue, if it's not a mistake, I would say we could simply set
baseUrltosrcin the root of the project and renametsconfig.e2e.jsontotsconfig.json.I think this should cover everything, no?
vivainio commentedon Nov 10, 2017
Bumped into this myself just now. Fix was to add baseUrl: './src' to tsconfig.json.
It's a bit suboptimal that this is broken out of the box on vscode. Until vscode gets a feature to select tsconfig.app.json, it would be a good idea to do this in the default tsconfig.json.
filipesilva commentedon Dec 7, 2017
@victornoel I reopened it because I closed it by mistake. Your proposed solution still breaks for multi-app projects like I mention in my previous comment.
victornoel commentedon Dec 7, 2017
ok, noted, thx for the update :)
vivainio commentedon Dec 7, 2017
@filipesilva It would seem more sensible to have correct behavior for the 95% use case (users starting new apps with angular-cli). Once you go multi-app, you can find out how to change the config yourself.
4 remaining items
angular-robot commentedon Feb 1, 2022
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
angular-robot commentedon Feb 21, 2022
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
alan-agius4 commentedon Oct 3, 2023
Closing as I believe this is solved by #25934. If the issue still persists please open a new issue.
angular-automatic-lock-bot commentedon Nov 3, 2023
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.