Working Solution?? #1
Comments
|
I am actively working on this project https://github.com/robianmcd/open-dvs. The build for it is based on hello-angular-rollup and it has been working out pretty well for me. I am trying to remember to reflect any changes I make to the build in both projects. The builds have gotten a little bit different on the two projects because I have some unit tests on open-dvs and did a bit of refactoring but nothing major. If I was personally starting a new project I would use this repo. It is not documented though so if you try using it let me know if you have any questions. |
|
So here's a question for you---what's your sense of how hard it would be
to carry forward the notion of splitting out the vendor bundle even in
the production mode? While that might seem stupid at first blush, my
particular problem space is a portal-style environment where i may end
up with multiple self-contained A2 apps on a page...
....and I assuming there is noparticular value of ngc vs "straight
typescript" when run against the A2 framework itself....
I'd love to both be able to run ngc against the apps themselves but
perhaps have them share a singlee copy of the angular runtime (aka the
vendor bundle) likely injected into the heade. The google combination of
'ngc rollup vendor bundle' i think it what took me to your site, and i
think its very, very close to what i am looking for in general
…On 3/14/2017 5:15 PM, Rob wrote:
I am actively working on this project
https://github.com/robianmcd/open-dvs. The build for it is based on
hello-angular-rollup and it has been working out pretty well for me. I
am trying to remember to reflect any changes I make to the build in
both projects. The builds have gotten a little bit different on the
two projects because I have some unit tests on open-dvs and did a bit
of refactoring but nothing major. If I was personally starting a new
project I would use this repo. It is not documented though so if you
try using it let me know if you have any questions.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKPLg_PRqPd66D0j3mdbMaaM18g96YqKks5rlxGKgaJpZM4MdEws>.
--
------------------------------
This e-mail may contain confidential or privileged information. If you
believe you have received this e-mail in error, please notify the sender by
reply e-mail and then delete this e-mail immediately.
|
|
The problem with keeping the bundles separate is that you can't take advantage of rollup's tree shaking. e.g. in the dev build for this repo the vendor bundle contains everything from the vendor files but in the production build, rollup removes any unnecessary vendor code. There is an open issue on rollup to add support for splitting code into multiple bundles after tree shaking happens rollup/rollup#372. But I'm not sure if any progress has been made on it. If you are ok when the vendor bundle containing some unnecessary code and the file size being bigger then I don't see any other issues with keeping it separate in production. |
|
Interestingly enough when i tried this i didn't have much success -- it
seems that an aot (ngc) compiled app doesn't play well with a non-AOT
compiled vendor bundle for reasons not immediately clear based on the
nasty stack trace....
…On 3/14/2017 5:50 PM, Rob wrote:
The problem with keeping the bundles separate is that you can't take
advantage of rollup's tree shaking. e.g. in the dev build for this
repo the vendor bundle contains everything from the vendor files but
in the production build, rollup removes any unnecessary vendor code.
There is an open issue on rollup to add support for splitting code
into multiple bundles after tree shaking happens rollup/rollup#372
<rollup/rollup#372>. But I'm not sure if any
progress has been made on it. If you are ok when the vendor bundle
containing some unnecessary code and the file size being bigger then I
don't see any other issues with keeping it separate in production.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKPLgxWoGiuYHdzQU2_kOecDw-FWxF9Pks5rlxm3gaJpZM4MdEws>.
--
------------------------------
This e-mail may contain confidential or privileged information. If you
believe you have received this e-mail in error, please notify the sender by
reply e-mail and then delete this e-mail immediately.
|
|
hmmm not sure why. As far as I know compiling your app with |
|
Well, I've identified at least one major issue with the approach of
having aot-compiled app trying to use a separate vendor bundle through
Rollup....it turns out the generated TS code for every file ngc outputs
as a result of template compilation each contain a crap ton of imports
that look like...
import * as import0 from '../../../src/app/app.component';
import * as import1 from '@angular/core/src/linker/view';
import * as import2 from '@angular/core/src/render/api';
import * as import3 from '@angular/core/src/linker/view_utils';
import * as import4 from '@angular/core/src/metadata/view';
...and then the problem with that is of course that the external/globals
that are passed into Rollup only include module IDs like @angular/core,
@angular/common and so on. So Rollup isnt able to (apparently) detect
that these imports in the aot-generated code are actually available
externalto the app code..
…On 3/17/2017 12:56 PM, Rob wrote:
hmmm not sure why. As far as I know compiling your app with |ngc|
shouldn't affect the vendor code at all.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKPLg1_CjNCj8yR3jHkJ-h329BjQrZDAks5rmslfgaJpZM4MdEws>.
--
------------------------------
This e-mail may contain confidential or privileged information. If you
believe you have received this e-mail in error, please notify the sender by
reply e-mail and then delete this e-mail immediately.
|
|
yeah that looks problematic. I did some googling but can't find anything on weather there is a way to avoid those generated imports of angular source files |
So I am really intrigued by your potential solution here as it may solve a pressing need i have to bust an ngc-compiled Angular 2 application up into three bundles--(1) polyfills (2) vendor and (3) app. And I really want to use Rollup instead of Webpack as Webpack makes my head hurt.
So I notice this solution hasn't been updated in a couple months? Does it actually work well enough for you, or was this just an experiment?
The text was updated successfully, but these errors were encountered: