angular: Incorrect imports when targeting es2015 using ngc in Ng 4.x
I’m submitting a … (check one with “x”)
[X] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
The particular issue I’m having is with ramda, but I believe it could apply to any other library that does not provide typings where we have to add the typings from @types.
Current behavior
When setting the target on tsconfig.app.json to es2015, the output code’s import statement for ramda library is incorrect:
import {uniq} from ‘ramda/index’;
Expected behavior
The import statement in the output file should be:
import {uniq} from ‘ramda’;
Minimal reproduction of the problem with instructions
I created a new app using the cli, and just changing the target on the tsconfig.app.json file to es2015. When you run npm run release, the build/app/app.component.js file contains the incorrect path to ramda.
Here is the repo to use to easily reproduce the issue: https://github.com/alvaro450/typings-issue
What is the motivation / use case for changing the behavior?
When creating a library, having the incorrect import statement would mean that when I use the library in an app, it will fail when it tries to resolve that import.
Please tell us about your environment:
MacOs Sierra, Visual Studio Code, npm 5
- Angular version: ^4.0.0
It is still an issue.
- Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
Browser independent, since this is the build process.
-
Language: [all | TypeScript X.X | ES6/7 | ES5] Typescript
-
Node (for AoT issues):
node --version
=
6.10.0
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 8
- Comments: 17 (2 by maintainers)
Commits related to this issue
- fix(tsc-wrapped): don't rewrite imports when annotating for closure Port of f24ea59f74552113f8e8586d2d69045254512aa to 4.4.x Closure no longer needs to have the imports rewritten so avoid rewriting ... — committed to chuckjaz/angular by chuckjaz 7 years ago
- fix(tsc-wrapped): don't rewrite imports when annotating for closure Port of f24ea59f74552113f8e8586d2d69045254512aa to 4.4.x Closure no longer needs to have the imports rewritten so avoid rewriting ... — committed to chuckjaz/angular by chuckjaz 7 years ago
- fix(tsc-wrapped): don't rewrite imports when annotating for closure (#19579) Port of f24ea59f74552113f8e8586d2d69045254512aa to 4.4.x Closure no longer needs to have the imports rewritten so avoid r... — committed to angular/angular by chuckjaz 7 years ago
I’m having the same issue with lodash-es. It’s transpiling this:
to this
Note that if I transpile my code with
tsc
instead ofngc
, then I get the correct output. So the problem is withngc
, nottsc
.This landed on 4.4 as c9f8718d2a72640da3889ac0ddf47a40ee627f67
To get around this issue, I forced
@angular/compiler-cli
to4.1.3
while I let all the other angular artifacts to get4.2.2
. So far things are working, albeit I have not tested aot builds. For me, I was creating a reusable angular module library for our private npm registry. Building that lib with anything above 4.1.3 compiler-cli was creating these incorrect imports with/index
suffixed.I wrote this rollup plugin that will fix it temporarily, looking forward to see you guys fix it 😃
@aminpaks Thanks for the plugin - works great!
Note: In ng 5, this is fixed via https://github.com/angular/angular/commit/f24ea59f74552113f8e8586d2d69045254512aa1
Another way to use the latest compiler was to do some post processing like https://github.com/merrillpaul/angular-md-pattern-lib/blob/master/lib/gulpfile.js#L152