Get build passing for AOT example - #578

Also note that because this PR uses direct module paths the server won't run as the files at the full paths use ES modules which the server will throw on "unexpected token import" at runtime, so far us to be able to move on we need to resolve the issue of ngc not properly emitting .d.ts information for double underscore prefixed variables or find another workaround

What happens in @angular/platform-browser? It has the same imports from
other @angular packages, and compiles with metadata.json produced. Does it
have the same missing information in the output .d.ts files? Sorry, I think
I need a more minimal repro to follow exactly what's happening here. Is it
reproducible within the repo now, or do you still have to install universal
into an example app to see the problem?

On Thu, Oct 6, 2016 at 11:50 AM Steve Sewell notifications@github.com
wrote:

@steve8708 commented on this pull request.

In modules/platform-node/node-platform.ts
#578:

-import {

• KeyEventsPlugin,
• DomEventsPlugin,
• HammerGesturesPlugin,
• BROWSER_SANITIZATION_PROVIDERS,
• DomRootRenderer,
• SharedStylesHost,
• DomSharedStylesHost,
  -} from './private_imports';
  +// Private imports - Remove me!
  +import { KeyEventsPlugin } from '@angular/platform-browser/src/dom/events/key_events';
  +import { DomEventsPlugin } from '@angular/platform-browser/src/dom/events/dom_events';
  +import { HammerGesturesPlugin } from '@angular/platform-browser/src/dom/events/hammer_gestures';
  +import { DomRootRenderer } from '@angular/platform-browser/src/dom/dom_renderer';
  +import { SharedStylesHost, DomSharedStylesHost } from '@angular/platform-browser/src/dom/shared_styles_host';
  +import { DomSanitizerImpl } from '@angular/platform-browser/src/security/dom_sanitization_service';

Sorry, the issue is when we import from private_imports (which is a
set of exports that are imported from private exports from angular, e.g.
platform_browser_private from @angular/platform-browser when we
compile with ngc the generated .d.ts file are missing type information for
anything from those private exports

Before, your suggestion to set skipInternal to false fixed the @internal
tags not being transpiled, but also fixed the private_imports as
well, so it seemed related

Now, for some reason though, we are seeing the issue again. And the __noop
vs _noop example also showed the same result, i.e. if noop was prefixed
with two underscores, it seems to be treated by ngc as being @internal,
but removing one of the underscores leaves it treated as any other export
again and emits properly

Let me know if I can clarify this better, it's certainly an odd issue that
I've yet to fully wrap my head around so can be a little tough to describe
well

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#578, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5Iy8y7Ry51UM6--nO93m58THydw1Lks5qxUMIgaJpZM4KQRMa
.

@alexeagle just made this branch to help easily reproduce the issues

It is the same as @gdi2290's branch but with the other build fixes so that as soon as the __private_imports__ work properly the full build should work end to end

to reproduce you'll want to

npm install 
gulp pre-publish
cd to examples/express-aot
npm run ngc && npm run build

You should see typescript complaining that everything from __private_imports__ is suddenly missing in the last step of the build

Interestingly, you will see that you will get the same issue if you, for example, rename _noop to __noop in node-http.ts, but naming it back to not have two underscores will allow it to be found again

Hope that helps, and thank you for your help!

@alexeagle in case it helps, after a little more testing, it looks like with either ngc or tsc the .d.ts files that are created always seem to skip emitting metadata for anything with a double underscore prefix

So even when using tsc instead of ngc, our __private_imports__.d.ts file looks like this

export { BROWSER_SANITIZATION_PROVIDERS, SharedStylesHost, DomSharedStylesHost, DomRootRenderer, DomEventsPlugin, DomAdapter, setRootDomAdapter, KeyEventsPlugin, HammerGesturesPlugin, SelectorMatcher, CssSelector, ViewUtils, AnimationKeyframe, AnimationPlayer, AnimationStyles, RenderDebugInfo };
declare var __empty: any;
export default __empty;

Note it strips all of the imports of what is being exported (BROWSER_SANITIZATION_PROVIDERS, etc). Also note that in the original file those are being imported from a double underscore prefixed export (e.g. __platform_browser_private)

The original typescript file for __private_imports__.ts is

import { __platform_browser_private__ } from '@angular/platform-browser';
import { __core_private__ } from '@angular/core';
import { __compiler_private__ } from '@angular/compiler';

// PRIVATE
const {
  BROWSER_SANITIZATION_PROVIDERS,
  SharedStylesHost,
  DomSharedStylesHost,
  DomRootRenderer,
  DomEventsPlugin,
  KeyEventsPlugin,
  DomAdapter,
  setRootDomAdapter,
  HammerGesturesPlugin
} = __platform_browser_private__;

const {
  ViewUtils,
  AnimationKeyframe,
  AnimationPlayer,
  AnimationStyles,
  RenderDebugInfo
} = __core_private__;

const {
  SelectorMatcher,
  CssSelector
} = __compiler_private__;


// @internal
export {
  // platform-browser
  BROWSER_SANITIZATION_PROVIDERS,
  SharedStylesHost,
  DomSharedStylesHost,
  DomRootRenderer,
  DomEventsPlugin,
  DomAdapter,
  setRootDomAdapter,
  KeyEventsPlugin,
  HammerGesturesPlugin,

  // compiler
  SelectorMatcher,
  CssSelector,


  // core
  ViewUtils,
  AnimationKeyframe,
  AnimationPlayer,
  AnimationStyles,
  RenderDebugInfo,
}

var __empty = null;

export default __empty;

Perhaps it is just written into typescript to not emit exports or imports with a __ prefix, similar to @internal with stripInternal but maybe has it's own flag to turn off this behavior or has none at all. That or for some reason it seems to think that those imports are globally available (based on it's prefix?)

cc @gdi2290

@alexeagle @gdi2290 I pushed another commit here that works around the interfaces not found issue by using the private exports object directly without destructuring

Unfortunately, this causes this issue to happen. I believe this is a bug in the compiler CLI (if interested, see comments on issue for detail). I've run into it before and always use the same workaround

Manually updating the angular/compiler-cli code (gross, I know) with the sample I note in the github issue allows the build to work end to end. Even if we don't want to use these updates as-is, at least hopefully this information is useful by demonstrating a workaround to the .d.ts issue that does in fact work

@gdi2290 FYI this completely works now once this in angular/angular gets merged

(also note the reason the build fails is for the same issue my PR to angular/angular resolves, so once that is merged and published this should pass build and be unblocked)

I've also manually verified through linking that with my updates to angular the build passes as expected

@steve8708 thanks, merged to my PR

@gdi2290 👍

note there is one more issue I've found. If you manually updated node_modules/@angular/compiler with a similar change as my PR to allow the build will pass but you'll get runtime errors that providers cannot be found (e.g. DomRootRenderer)

Taking a look at that now but it is a strange one that is a little tricky to try and poke into why exactly that happens only in AOT mode and not in JIT mode

I had similar problem with providers not found. The issue was the ngfactory
needs to determine if two static symbols are the same: the one imported and
the one used in the constructor of the component being compiled. If these
are accidentally not the same, the generated code will try to ask the
parent injector for the dependency instead.
It may be that your fix for the isStaticSymbol is the wrong fix...

On Mon, Oct 10, 2016 at 12:09 PM Steve Sewell notifications@github.com
wrote:

@gdi2290 https://github.com/gdi2290 👍

note there is one more issue I've found. If you manually updated
node_modules/@angular/compiler with a similar change as my PR to angular
the build will pass but you'll get runtime errors that providers cannot be
found (e.g. DomRootRenderer)

Taking a look at that now but it is a strange one that is a little tricky
to try and poke into why exactly that happens only in AOT mode and not in
JIT mode

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#578 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC5IxUAt8l1tZwZuQ097KudIp5FpZ-wks5qyo1kgaJpZM4KQRMa
.

Ah... this is very helpful, thank you @alexeagle! I'll dig in deeper and see if I can verify. Poking around the compiled ngfactory code could possibly help, will try that first

Maybe it's not direct related to this issue, but since I got here:
I had a missing dependency in a generated *.ngfatory for the constructor. With JIT it worked fine, with AOT not. Error was: I forgot the @Injectable() above the service class. Did put it there and it worked again.

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