Breaking: v6 with backward compatibility

[oliverfoster]

fixes #2526
fixes #2363

original issues #3044
original prototype #3324

What's changed?

1. We have NPM install support for plugins via our normal registry server. The server is publically available for those who wish to host their own registries. A registry server can be setup to fallback to any other public npm registry. The default server fallback registry is to the npm public registry but it is possible to chain to the adapt registry which then chains to the npm one. Any plugins registered in the server should be installable via npm using the registry at https://adapt-bower-repository.herokuapp.com/npm/. With:

//.npmrc
registry=https://adapt-bower-repository.herokuapp.com/npm/

2. We've gotten rid of src/course in favour of build/course
3. It will be possible to use (most/some) npm modules in courses moving forwards (tbc as to limitations).
4. All existing plugins should work without amendment

Testing

1. Run the following commands

git clone https://github.com/adaptlearning/adapt_framework v6-test
cd v6-test
git checkout issue/v6-simple
cd src/
npm install
cd ../
npm install
grunt dev

2. Once built, cancel the dev task with ctrl+c, then run

grunt server

3. Please have a look around and post any comments on this pr

Todo

• SCHEMAS: The grunt tasks do not yet apply defaults from the new AAT schemas, the old AAT schemas will not work with v6 without sustantial work but the new AAT schema styles should be able to do what's necessary, they have yet to be cleaned up and trimmed. We need to decide if v6 will support the classic AAT / vice-versa.
• adapt-cli is not yet compatible with v6 but the adapt install command etc will be made v6 compatible Add npm layer adapt-cli#175
• grunt build includes do not yet work with dependent extensions, such that if resources is included but drawer is not, drawer will not yet be added to the construction phase

[chris-steele]

with the maps and paths now specified here can we remove the corresponding config from scriptLoader?

[oliverfoster]

No. The ones in the scriptLoader.js are client-side and they happen before adapt.min.js is loaded, the mappings from the compiler happen at the top of adapt.min.js, after those modules are needed. Oftentimes external libraries/ files will expect jQuery at minimum and will need access to jQuery before adapt.min.js is loaded.

We will be able to remove some of them as we move over to node_modules, specifically: regenerator-runtime, core-js, react, react-dom, html-react-parser and semver. The others will be more difficult.

[chris-steele]

ah, of course, though is the scriptLoader map used at all?

[chris-steele]

The only use I saw was spoor's offline_API_wrapper.js, but I think that has recently been moved into compilation, right?

[oliverfoster]

The map properties are used heavilly in adapt-devtools. The paths section is used further down the scriptLoader.js to load the foundational libraries+templates and some of those libraries are used by name at various places throughout the core and plugins.

map

  coreJS: 'core/js',
  coreViews: 'core/js/views',
  coreModels: 'core/js/models',
  coreCollections: 'core/js/collections'

These shortcuts were mostly removed when we switched to babel and jsdoc, both of which really only work correctly with resolvable file paths.
#930

[oliverfoster]

Effectively, when core is updated to switch to node_modules, we can also drop the scriptLoader.js directives, where reasonable to do so, considering backward compatibility and load order. jQuery, jqueryMobile, underscore, backbone, handlebars and Modernizer will be most difficult I imagine. imageReady, inview and jquery.resize are libraries I made, so they should be quite easy to integrate into the core. bowser, scrollTo, requirejs and velocity I haven't analysed yet.