External dojo deps

[maier49]

Type: feature

The following has been addressed in the PR:

• [x] There is a related issue
• [x] All code matches the style guide
• [x] Unit or Functional tests are included in the PR

Description:

Partially addresses #165, by providing a mechanism for integrating Dojo 1 libraries, or any library that can be consumed with the Dojo 1 loader into a Dojo 2 application.

[maier49]

@dylans I believe I've addressed all of your feedback.

[matt-gadd]

@maier49 so I have a potentially stupid question, if i built my library on a way older version of dojo 1 (silly I know), and now want to include it I but have no loader in the layer. When we include a loader in the build, it will be from the version of dojo in cli-build package.json?

[matt-gadd]

how would we build on this to support more external library types? could this be more generic in terms of it being an AMD externals configuration? (rather than dojo?). or even better decoupling ourselves completely kind of like intern 4 does in terms of it's loading mechanism and config?

[maier49]

@matt-gadd To your question about the loader, if you don't include any layer with a loader, then yes you will get the version of dojo defined in the package.json. However there's nothing stopping you from building a separate layer that just includes the loader, or bringing along a specific version of dojo yourself and using the loader from that.

[agubler]

I don't think we should be including Dojo as a dependency of cli-build, rather document that if the external needs a loader that it needs to be included specifically (if it's not built into the external itself).

[maier49]

@agubler I've removed Dojo as a dependency

@matt-gadd I've reworked this to allow the registration of multiple loaders and left the loader config up to the developer. An example of providing a loader for Dojo 1 modules can be seen in the readme. Unfortunately the way that externals are loaded is pretty baked in, so this basically involved copying an existing plugin and selectively overriding functionality. See here, and here for discussion in related issues.

[matt-gadd]

Just trying to digest this. Is the reason for the copied plugin to support something other than UMD? Because the issues linked seem to be related to bespoke module formats, which I don't think we should bother supporting?

[maier49]

@matt-gadd The UMD plugin that I copied and overwrote is responsible for writing the UMD wrapper itself, and it automatically adds calls to require external modules. That could be problematic in the case that, for example, we need to load a layer file before other external dependencies will be available, and couples us to using either global variables or a global require as the mechanism for loading external modules.

[maier49]

@dylans @agubler I've made updates to address your feedback.