SMD (Static Module Definition)

[eric-brechemier]

I would like to implement a subset of AMD for Static Module Definition (SMD).

I have two use cases in mind:

• static loading of optimized scripts combining several modules
• static loading of one module per script file during development in platforms that do not support dynamic loading

I have developed a partial implementation of AMD for the first use case here: https://github.com/eric-brechemier/lb_js_scalableApp/blob/master/src/amd/define.js

I plan to develop a more limited implementation for the LIME Starter Kit project, using a subset of JavaScript, for TV sets: https://github.com/eric-brechemier/lime-starter-kit

I feel like 3 areas of the code are oversized for a basic implementation:

• management of optional arguments of define() from line 84 to 102
• management of relative dependency identifiers from line 114 to 165
• management of reserved dependency identifiers from line 189 to 204

I would suggest to define a property, define.amd0 or define.smd, for basic implementations that claim only support for:

• define(id, dependencies, factory) with all arguments included, with their types fixed to string, array and function
• absolute identifiers in id and dependencies
• no reserved module identifiers: "module", "exports", "require"

Modules using the basic syntax may still be loaded by full-featured AMD script loaders. It may be possible to convert (most of) existing modules to the basic syntax in optimization tools.

[eric-brechemier]

I actually ended with a more limited subset for TV, due to restrictions of this platform: the lack of support for function.apply() makes use of variable number of arguments more cumbersome:

https://github.com/eric-brechemier/lime-starter-kit/blob/master/lab/js/define.js

[jrburke]

I was hoping this would just be managed by the loader specifying what parts of AMD it supports. For instance, the almond API shim has a list of constraints that limit the types of AMD modules it supports.

The amdjs tests also have an opt-in of different levels, so that an implementation can prove some AMD conformance without having to implement all of it.

Otherwise, I think it is too difficult to try to reflect in the spec a list of values that indicate level of conformance, and then even harder to communicate those values.

I would rather see loaders suggest using different types of tools/optimizers to format the input modules into the types that are usable by a particular loader.

I am going to mention @unscriptable here so he gets notified of the comment, he expressed getting notifications of new tickets, but we do not seem to be getting them, so trying to manually trigger a notification.

I am going to close this for now, but we can reopen if we need to after further discussion.

[eric-brechemier]

Thanks for the detailed answer.

I am now experimenting with a new approach, an intermediate layer to facilitate the migration from static code to dynamic code using AMD: https://github.com/eric-brechemier/scopeornot

The idea is to define an API compatible with AMD but without requiring any compliance. The implementation of scope() can be selected to migrate modules slowly, first using a static implementation which does not manage dependencies and expects scripts to be defined in the correct order, before switching to a dynamic implementation which handles dependencies at a later step.