Angular-cli: ng build --prod unable to process symbolic links

Created on 28 Feb 2017  路  26Comments  路  Source: angular/angular-cli

OS?

Linux Ubuntu

Versions.

@angular/cli: 1.0.0-rc.0
node: 7.4.0
os: linux x64

I am working on two angular-cli projects (frontend and backend). As they share many components, services etc, I created a folder "actual-common" and put a symbolic link "common" under the src folder of each project. This worked well until I performed an ng build using the --prod option, at which point every shared item gives the following message.

ERROR in ../actual-common/modules/auth0/logout/logout.component.ts
Module build failed: TypeError: Cannot read property 'text' of undefined
    at Object.getTokenPosOfNode (/home/Angular/frontend/node_modules/typescript/lib/typescript.js:6768:71)
    at IdentifierObject.TokenOrIdentifierObject.getStart (/home/Angular/frontend/node_modules/typescript/lib/typescript.js:80500:23)
    at IdentifierObject.TokenOrIdentifierObject.getText (/home/Angular/frontend/node_modules/typescript/lib/typescript.js:80521:77)
    at refactor.findAstNodes.filter (/home/Angular/frontend/node_modules/@ngtools/webpack/src/loader.js:139:44)
    at Array.filter (native)
    at refactor.findAstNodes.forEach.node (/home/Angular/frontend/node_modules/@ngtools/webpack/src/loader.js:138:14)
    at Array.forEach (native)
    at _removeDecorators (/home/Angular/frontend/node_modules/@ngtools/webpack/src/loader.js:129:10)
    at Promise.resolve.then (/home/Angular/frontend/node_modules/@ngtools/webpack/src/loader.js:292:33)
 @ ./src/$$_gendir/app/app.module.ngfactory.ts 81:0-79
 @ ./src/main.ts
 @ multi ./src/main.ts

I noted that the error refers to my absolute path "actual-common", so I presume it is a webpack issue similar to https://github.com/webpack/webpack/issues/1643 I also note that a custom webpack configuration is not available using Angular-Cli, so the workaround described on the issue is not available to me.

My workaround was to clone the project and replace the "common" symlink with the actual files.

(Is there a better way to share code between local projects?)

2 (required) bufix faq

Most helpful comment

Further to my previous comment, it would appear that we now have a --preserve-symlinks flag available in "ng build" https://github.com/angular/angular-cli/pull/6460

This cured my symbolic link problem with vscode debugging - all my symbolic link problems have been solved, as far as I am concerned this is a closed issue.

All 26 comments

+1
Same on Windows 10
But the symlinks are correctly resolved with "ng serve"

As @kipy-be says, symbolic links work with "ng serve", plus "ng lint" and even "ng build" just as long as you do not use the --prod flag. Both "ng build --prod" and "ng serve --prod" cause the error.

+1

Getting this too, on Windows though.

It looks like when I run ng build --prodinside a location thats a symlink, all of the nodes coming back from this code have an undefined parent.

If I run the command inside the actual directory, the parents are correctly set.

EDIT:
I can actually fix the issue if I pass the sourceFile argument into getStart() in the typescript compiler here, but I don't think that's actually a fix. Not sure why the parents are undefined inside the symlink.

After more debugging, program.getSourceFile(fileName) is coming back undefined when inside the symlink directory.

So the typescript compiler's currentDirectory is the symlink location, but the paths getting passed into getSourceFile are resolved paths(so the actual location on disk), which I guess is throwing the typescript compiler out of whack, so it's just returning undefined.

I've noticed that AOT is now enabled by default with the --prod flag.
I tried disabling it to see what happens, and... It seems to work.

So, both
ng build --prod --aot false
ng serve --prod --aot false

are working with symlink resolution.

The issue is aot related.

I concur with @kipy-be, I am able to compile with symbolic links when I set --aot false. To be honest, I have no idea what I lose by turning AOT off. Is it a practical workaround to the symbolic link problem, or should I stick to my cloning with the actual files?

@MortimerCat You would want to use AOT in a production environment. It compiles your html/css files into the internal angular components. If you skip this step, it ends up happening in the browser which will increase page load time.

Sounds like a bug. Thanks for reporting it.

Same issue on latest tooling.
How does it looks like, when can we expect AOT to be working again? Thx.

I'm getting a similar issue on Windows 7 which appears related to routing, but I'm not using symlinks. But I get the error only in IE11, not Chrome. I'm using all the recommended IE polyfills from polyfills.js. Angular 4.0.0, CLI 1.0.0.

I was trying to create a repro but haven't narrowed it down to something small yet. Again, only get the error with ng serve --prod (or ng build); error goes away with --aot false.

"Uncaught (in promise): TypeError: Unable to get property 'initialNavigation' of undefined or null reference
TypeError: Unable to get property 'initialNavigation' of undefined or null reference
   at t.prototype.isLegacyDisabled (http://localhost:4200/vendor.35a56695c585013b7d07.bundle.js:407:2550)
   at Anonymous function (http://localhost:4200/vendor.35a56695c585013b7d07.bundle.js:407:1510)
   at t.prototype.invoke (http://localhost:4200/polyfills.1b67348a0bf296656461.bundle.js:36:9782)
   at onInvoke (http://localhost:4200/vendor.35a56695c585013b7d07.bundle.js:316:8090)
   at t.prototype.invoke (http://localhost:4200/polyfills.1b67348a0bf296656461.bundle.js:36:9782)
   at n.prototype.run (http://localhost:4200/polyfills.1b67348a0bf296656461.bundle.js:36:5065)
   at Anonymous function (http://localhost:4200/polyfills.1b67348a0bf296656461.bundle.js:36:2119)
   at t.prototype.invokeTask (http://localhost:4200/polyfills.1b67348a0bf296656461.bundle.js:36:10439)
   at onInvokeTask (http://localhost:4200/vendor.35"

A way to look for the problematic code: Find the Node primitive (fs.whatever) for resolving symlinks - this is the thing we don't want CLI or anything it calls, to use. Add a "throw" there. Look at stack trace. Use that to find wherever in CLI it gets called. Then work through how CLI calls libraries to avoid this happening.

I also use a symlink on a "imgs" folder that is located inside "src" folder and referenced in "angular-cli.json"
"apps": [ { ... "assets": [ "assets", "imgs", "favicon.ico" ], ... } ]
the content of "imgs" folder is a symbolic link to another computer that has tons of images assets, so I can't copy them all on my own computer.

The ng serve --aot false command does not work (I use angular-cli 1.0.6), my images are not displayed.
test.jpg:1 GET http://localhost:4200/imgs/subfolder/test.jpg 404 (Not Found)
Whereas when I used the 1.0 beta angular-cli images with symlink were rendered.

This is pretty blocking at that moment.

@djtahl Sound likes the Assets not working after update issue. Try the following

 ng serve --base-href /

@MortimerCat thank you for your answer, unfortunately I tested this command

ng serve --base-href /

And nothing changed.
It still gives the 404 when I try to call an image from a symlink folder, whereas it works correctly when I load all the images on my computer folder, here is a screenshot to explain my issue :
symlink_folder

Having the same issue here, build --prod works in local, but breaks in development server. I will test the with aot --false and I will give some feedback.

I was having a similar issue with accessing third party libraries, disabling aot resolved this issue and the prod build was a similar size to that that is was when using aot.

I am now on version @angular/[email protected] and my original problem seems to have been resolved. Not sure when and why - I just happened to notice that I have been doing the production compiles with my symbolic links in place.

Further to my previous comment, it would appear that we now have a --preserve-symlinks flag available in "ng build" https://github.com/angular/angular-cli/pull/6460

This cured my symbolic link problem with vscode debugging - all my symbolic link problems have been solved, as far as I am concerned this is a closed issue.

We have made a few changes to how we process symlinks, and think this issue was fixed in one of them. Closing then.

Hi,
How do you guys use this flag when running ng serve? it doesn't seem to have this flag, so how do you start the server while preserving symbolic links?

My ng server command in full is as follows.

ng serve --host 0.0.0.0 --disable-host-check --preserve-symlinks --base-href /

You need to make sure you are running an up to date version of the CLI or at least @angular/[email protected] which is the version that originally worked for me.

According to the source file of the serve command (here) there is no --preserve-symlinks for the serve command.

Its handled within the build command (here) . I am not an expert in the details of how ng serve works, but I always assumed ng serve calls ng build and would pass the parameters across?

ng build --preserve-symlinks --watch, does not allow angular-cli to build my project with symlinked files inside node_modules. My issue is not resolved. I cannot develop locally without npm link.

So, Angular + symlink issues add up as following?

  • --aot must be used with --preserve-symblinks
  • But when --aot is on, due to Webpack's watchpack issue, watch symlink directories might malfunction

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

Was this page helpful?
0 / 5 - 0 ratings