Right now out props/targets for defining and building the JS bundle assumes that each app only has one bundle. However, we have a case within our own native integration test projects where we generate multiple bundles via defining multiple <JsBundleEntry> items, and multiple bundles are created via a custom bundle target with multiple inputs.
Instead we should standardize our props/targets on that, even if most apps only have one bundle entry.
Motivation
Rather than have this useful logic hidden within our test code, we could share it for app projects that require more than one bundle. While the default template should only set up one entry (pointing at the standard index.windows.js entry file) it would make it a lot easier for app devs to just add new entries in their project and end up with more bundles as part of their build.
Summary
Right now out props/targets for defining and building the JS bundle assumes that each app only has one bundle. However, we have a case within our own native integration test projects where we generate multiple bundles via defining multiple
<JsBundleEntry>
items, and multiple bundles are created via a custom bundle target with multiple inputs.Instead we should standardize our props/targets on that, even if most apps only have one bundle entry.
Motivation
Rather than have this useful logic hidden within our test code, we could share it for app projects that require more than one bundle. While the default template should only set up one entry (pointing at the standard
index.windows.js
entry file) it would make it a lot easier for app devs to just add new entries in their project and end up with more bundles as part of their build.Basic Example
No response
Open Questions
No response