New command: spfx project externalize

[baywet]

I had an idea a couple of days ago. Based on the spfx project upgrade command, why not building a spfx project externalize command?
The idea is that it'd be based on detection rules, scan the package.json (and maybe some source files) to detect packages that could be externalized and suggest a config.json external configuration.
This way a developer could be sure he has the proper configuration, didn't miss out any package and so on.
Thoughts?

[waldekmastykarz]

Interesting suggestion. How would you determine, which packages could be externalized?

[baywet]

For example, if we detect that @pnp/sp is being used and/or in the package.json, we know that could be offloaded to a CDN instead of bundling it. The idea would be to build detection rules this first one would be CDN001_pnp_sp or something like that. Of course this set of rules would be separate from the upgrade ones.

[waldekmastykarz]

With over 700.000 packages on npm how would we handle them in a way that scales? Theoretically, every package could be defined as an external so how could we deal with it in a way that won't require us adding every single package explicitly?

[baywet]

Agreed, however each package can have different module definition, a global var or not exposed as well as different supported CDNs and url formats (meaning file name on the CDN, versioning tag…). So I can't think of a reliable consistent approach.
The idea was to help sharepoint devs move faster improving performances with more commonly used libraries in our ecosystem, things like lodash, moment, office ui fabric, pnp, ….
Then maybe we could have some kind of dynamic detection system by "observing" the package (kind of the umd/amd/… detector you built online) and guessing the url on one selected CDN, but again I don't think there's a way to make sure it's consistent in terms of urls.
Maybe for the URLs we could pull an API, or issue web requests and do scrapping on the cdnjs/unpkg index pages… What do you think?

[waldekmastykarz]

It might be interesting to build a proof of concepts to see if this is viable. As you mentioned, it might be hard to get this done reliably so having something to look at would give us a better idea what's possible.

[wictorwilen]

I would recommend to have a dedicated tool for this as there would be to many "options" in making a decision on externalizing or not. The reason for externalizing could be many (compliance, reuse, performance, size...) which would it extremely difficult to create this command without building in biased thoughts.

[waldekmastykarz]

Depending on the complexity, it could be a separate tool or a separate command in the CLI, which would free folks from having to install yet another tool. But yes, definitely something separate.

[wictorwilen]

"One tool to rule them all" :-)