Repository navigation
Conversation
|
thanks for this. lgtm |
| 1. Metadata storage by thirdparties in `package.json`. This must be accessible by plugins for | ||
| the build process or even when scaffolding. | ||
| 1. Proper configuration of SystemJs in the browser. | ||
| 1. SystemJs configuration needs to be kept separated from the autogenerated part. |
|
I really like the I can't imagine that a lib that uses these hooks could be used without All these configuration options also seem to severely be overloading Perhaps the key issue here is the separation of cli addons vs simple libraries. Addons should change the functioning of the CLI, whereas simple libraries should be no more than imported and perhaps have some simple prompts for automatically add providers/configuration to an app. |
| We will not use SystemJS bundles in development. This is for better debugging, future proofing | ||
| (when moving the build system) and better CDN support, as many of the loaded files will end up | ||
| being pulled from a CDN in production. During the `ng build` process for production, the | ||
| SystemJS configuration script will be rebuilt to fetch from the CDN. |
There was a problem hiding this comment.
It feels a bit superfluous to have a strong commitment to SystemJS (for the CDN functionality) and still keep the brocolli build step.
Perhaps we could move to SystemJS TS browser compilation for dev builds, and have the production build step simply compile TS to spare SystemJS from doing it.
There was a problem hiding this comment.
We have no strategy for a production build, but it will involve concatenating + minifying, so it's safe to say we'll have to revisit broccoli.
6771e54 to
76d6b66
Compare
cc54f64 to
7a88bae
Compare
|
@wesleycho you said you wanted to take a look at this proposal. |
hansl
changed the title
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
No description provided.