Changes to the SFX bundle

@rkirov

To start with the current SFX bundle (angular2.sfx.dev):

contains the following barrels: zone, reflect-metadata, common, core, instrumentation, platform/browser, upgrade, http, router:
- common, core, instrumentation, platform/browser are exported on the ng namespace
- http is exported on the ngHttp namespace
- router is exported on the ngRouter namespace
is using dev output
isn't minified
doesn't have source maps
provides support for noConflict mode -> although it is broken now since it doesn't restore ngHttp and ngRouter namespaces

As part of our bundling discussion(s) we've been several times touching upon role, content and setup of the SFX bundle. More specifically the open questions were / are:

who is the main consumer of the SFX bundle (ES5, ngUpgrade?). AFAIK @rkirov is aware of another use-case
shell we use the same bundle for ES5 and ngUpgrade scenarios?
what should be the content? Some barrels are non-controversial (common, core, instrumentation, platform/browser) other are disputable
what exact namespaces shell be used to export different barrels?
should we keep the non-conflict mode?

From the list above we can see that there are number of small decisions that we need to take.

Proposal:

use the same bundles for ES5 and ngUpgrade users
include the following barrels: common, core, instrumentation, platform/browser, upgrade, http, router. This means dropping zone and reflect-metadata barrels (those should be loaded from the external-dependencies)
drop the noConflict mode (it is broken today anyway)
add prod mode with source maps and min

Open questions:

export namespace: I'm leaning towards using ng for everything - this is to make life easier for ES5 / ngUpgrage users

Exporting namespaces to window objects is the easiest way to interop between different module loaders. In particular we are using the sfx bundle to shim into Closures' module loader like this:

goog.provide('angular2.angular2');

angular2.angular2 = window.ng;

About the proposal, sounds good on:

removing platform deps (we still need a better name than external-dependencies).
adding min output for sfx bundle
moving ngRouter to ng.Router (same for http)

I also propose moving away from the name SFX, since it is very custom to system.js, but the consumer doesn't need to know about that. I suggest either "global export bundle" or "ES5 bundle".

Also don't see what's the problem with noConflict once Router lives in ng.Router?

Also don't see what's the problem with noConflict once Router lives in ng.Router?

This wouldn't be a proper CJS bundle, if this matters. What I'm saying is that this would be a bundle in the "global" format and not UMD format any more.

@pkozlowski-opensource

+1 to @pkozlowski-opensource's proposal except for the namespaces.

I think we should preserve the namespaces as they are in es6/typescript, but reexport via the ng namespace the most commonly needed stuff used for defining components, directives, pipes and services via chained DSL. This should be just a handful of symbols and we should document that they are being reexported in ES5 bundles for convenience.

Can't we overlay the namespaces onto window objects as such:

import * as core from 'angular2/core';
import * as di from 'angular2/di';
import * as router from 'angular2/router';

window.ng = {};
window.ng.core = core;
window.ng.di = di;
window.ng.router = router;
etc.

I am not so concerned where exactly the symbols live as long as they are:

separated (so that they can be mapped back into other notions of "modules")
accessible through window.foo.bar, without referencing a particular module loader shim.

Can't we overlay the namespaces onto window objects as such

This is the exact plan now! Names on ng should follow structure of our barrels.

@rkirov

Proposal:

import * as core from './core';
import * as common from './common';
import * as platformBrowser from './platform/browser';
import * as instrumentation from './instrumentation';
import * as http from './http';
import * as router from './router';
import * as upgrade from './upgrade';

export {core, common, instrumentation, http, router, upgrade};
export var platform = {
  browser: platformBrowser
};

and this will get bundled as a UMD bundle where ng is used as a global var name.

@rkirov if you've got more specific needs / comments please let me know!

@IgorMinar

FYI, if implemented as suggested this is the type of code one would write for an ES5 application:

 var MyComponent = ng.core.Component({
      selector: 'my-app',
      template: '' +
      '<h1>Hello, {{name}}!</h1>' +
      ' Say hello to: <input [value]="name" (input)="name = $event.target.value">' +
      ''
    }).Class({constructor: function() {
      this.name = 'World';
    }});

    ng.platform.browser.bootstrap(MyComponent);

@IgorMinar chaining actually works fine so we might want to skip this part:

reexport via the ng namespace the most commonly needed stuff used for defining components, directives, pipes and services via chained DSL. This should be just a handful of symbols and we should document that they are being reexported in ES5 bundles for convenience.

Preparing a PR

@IgorMinar

lgtm

On Tue, Dec 8, 2015 at 4:46 AM Pawel Kozlowski [email protected]
wrote:

FYI, if implemented as suggested this is the type of code one would write
for an ES5 application:

var MyComponent = ng.core.Component({
selector: 'my-app',
template: '' +
'
Hello, {{name}}!
' +
' Say hello to: <input [value]="name" (input)="name = $event.target.value">' +
''
}).Class({constructor: function() {
this.name = 'World';
}});
ng.platform.browser.bootstrap(MyComponent);
@IgorMinar https://github.com/IgorMinar chaining actually works fine so
we might want to skip this part:

reexport via the ng namespace the most commonly needed stuff used for
defining components, directives, pipes and services via chained DSL. This
should be just a handful of symbols and we should document that they are
being reexported in ES5 bundles for convenience.

Preparing a PR

—
Reply to this email directly or view it on GitHub
#5665 (comment).

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

Navigation Menu

Repository navigation

Changes to the SFX bundle #5665

Proposal:

Open questions:

Hello, {{name}}!

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Changes to the SFX bundle #5665

Description

Activity

pkozlowski-opensource commented on Dec 7, 2015

Proposal:

Open questions:

rkirov commented on Dec 7, 2015

pkozlowski-opensource commented on Dec 7, 2015

IgorMinar commented on Dec 7, 2015

rkirov commented on Dec 7, 2015

pkozlowski-opensource commented on Dec 7, 2015

pkozlowski-opensource commented on Dec 7, 2015

pkozlowski-opensource commented on Dec 8, 2015

IgorMinar commented on Dec 8, 2015

Hello, {{name}}!

angular-automatic-lock-bot commented on Sep 7, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions