We should create a setup script to symlink vanilla to /usr/local/bin and make sure that it is in the path. This setup script could also make sure that root level node_modules in /src/Vanilla/FrontendTools gets installed.

Building everything at once (in CI) allows for some more consistent builds, lowers the size of our repo over time, and reduces a lot of noise in git commits.

• Create a build-all command for the CLI. It should build everything in a vanilla installation in production mode and a dev mode.
• Ensure this can run inside of our vanilla-docker setup (normally in an intermediary persisted mode with fast source maps, and no uglification, but production builds should be able to run in it as well.).
• Ensure the builds happen fast enough that this is not a huge issue.
• Create a post-checkout hook to run the dev build in the container automatically on git checkout.
• Add this build process to the open source release packaging.
• Work with operations to get this running on deployment to infrastructure.
• Remove all build artifacts from version control.

Now that yarn has support for bower_components it becomes a lot more feasible to convert most of our existing themes to use the CLI's built tool. The last thing holding this back is a lack of support for less stylesheets.

This should configured with a command line argument or an additional property in the addon.json build key.

The actual switching out to less is rather trivial to implement.

This tool should synchronize with our vanilla/vanilla repo for the 2.7 release.

Eg. Needs a release branch, and a way to manage version from the top level.

The build tool currently requires nodejs, yarn, and a c++ compiler to be installed on the system. It needs to check if it's dependancies are installed every time it runs and then install them if they aren't. This should all be simplified by pre-compiling binaries of the build processes and shipping them with the cli. This would remove the requirement for node, yarn, and the compiler.

This should be rather trivial with either nexe or pkg. The largest reason why this wasn't done originally was because the bundling of native modules like fs and node-sass wasn't very good. This seems to have improved recently.

The build js is currently nested a bit deep too. There is a defunct entry point that should be removed (this logic was moved into php.) Then each build process needs to be built into separate binaries and called from the php command.

Depending on what kind of work you're doing, you may want more or less precision for the source maps. It would be nice to have a config for that.

Vanilla's core addon.json should be watched by cli for updates.

Currently files in the addon's node_modules are being watched so after a long enough period of time the watch process just stops working with no indication of what happened. These folders should be ignored.

Currently 1 error can actually display multiple times. An example of the errors when 1 theme is missing "type": "theme".

PHP Notice:  The addon in /themes/bigfish has 1 issues. in /www/vanilla/library/Vanilla/Addon.php on line 787
PHP Stack trace:
PHP   1. {main}() /git/vanilla-cli/bin/vanilla:0
PHP   2. Vanilla\Cli\Cli->run() /git/vanilla-cli/bin/vanilla:41
PHP   3. Vanilla\Cli\Cli->dispatch() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:71
PHP   4. Vanilla\Cli\Command\AddonJsonCmd->run() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:56
PHP   5. Vanilla\Cli\Command\AddonJsonCmd->doRun() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonCommandBase.php:58
PHP   6. Vanilla\AddonManager->scan() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonJsonCmd.php:48
PHP   7. Vanilla\Addon->__construct() /www/vanilla/library/Vanilla/AddonManager.php:323
PHP   8. Vanilla\Addon->scan() /www/vanilla/library/Vanilla/Addon.php:67
PHP   9. Vanilla\Addon->check() /www/vanilla/library/Vanilla/Addon.php:116
PHP  10. Vanilla\Addon->triggerIssues() /www/vanilla/library/Vanilla/Addon.php:771
PHP  11. trigger_error() /www/vanilla/library/Vanilla/Addon.php:787
PHP Notice:  The type info field is required. in /www/vanilla/library/Vanilla/Addon.php on line 789
PHP Stack trace:
PHP   1. {main}() /git/vanilla-cli/bin/vanilla:0
PHP   2. Vanilla\Cli\Cli->run() /git/vanilla-cli/bin/vanilla:41
PHP   3. Vanilla\Cli\Cli->dispatch() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:71
PHP   4. Vanilla\Cli\Command\AddonJsonCmd->run() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:56
PHP   5. Vanilla\Cli\Command\AddonJsonCmd->doRun() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonCommandBase.php:58
PHP   6. Vanilla\AddonManager->scan() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonJsonCmd.php:48
PHP   7. Vanilla\Addon->__construct() /www/vanilla/library/Vanilla/AddonManager.php:323
PHP   8. Vanilla\Addon->scan() /www/vanilla/library/Vanilla/Addon.php:67
PHP   9. Vanilla\Addon->check() /www/vanilla/library/Vanilla/Addon.php:116
PHP  10. Vanilla\Addon->triggerIssues() /www/vanilla/library/Vanilla/Addon.php:771
PHP  11. trigger_error() /www/vanilla/library/Vanilla/Addon.php:789
=== AddonManager's warnings ===

Notice: The addon in /themes/bigfish has 1 issues. in /www/vanilla/library/Vanilla/Addon.php on line 787

Call Stack:
    0.0003     357192   1. {main}() /git/vanilla-cli/bin/vanilla:0
    0.0106     731272   2. Vanilla\Cli\Cli->run() /git/vanilla-cli/bin/vanilla:41
    0.0113     751144   3. Vanilla\Cli\Cli->dispatch() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:71
    0.0114     751144   4. Vanilla\Cli\Command\AddonJsonCmd->run() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:56
    0.0264    2121832   5. Vanilla\Cli\Command\AddonJsonCmd->doRun() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonCommandBase.php:58
    1.0479    2144048   6. Vanilla\AddonManager->scan() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonJsonCmd.php:48
    1.1674    2578576   7. Vanilla\Addon->__construct() /www/vanilla/library/Vanilla/AddonManager.php:323
    1.1674    2578576   8. Vanilla\Addon->scan() /www/vanilla/library/Vanilla/Addon.php:67
    1.1722    2583824   9. Vanilla\Addon->check() /www/vanilla/library/Vanilla/Addon.php:116
    1.1723    2585056  10. Vanilla\Addon->triggerIssues() /www/vanilla/library/Vanilla/Addon.php:771
    1.1723    2585136  11. trigger_error() /www/vanilla/library/Vanilla/Addon.php:787


Notice: The type info field is required. in /www/vanilla/library/Vanilla/Addon.php on line 789

Call Stack:
    0.0003     357192   1. {main}() /git/vanilla-cli/bin/vanilla:0
    0.0106     731272   2. Vanilla\Cli\Cli->run() /git/vanilla-cli/bin/vanilla:41
    0.0113     751144   3. Vanilla\Cli\Cli->dispatch() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:71
    0.0114     751144   4. Vanilla\Cli\Command\AddonJsonCmd->run() /git/vanilla-cli/src/Vanilla/Cli/Cli.php:56
    0.0264    2121832   5. Vanilla\Cli\Command\AddonJsonCmd->doRun() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonCommandBase.php:58
    1.0479    2144048   6. Vanilla\AddonManager->scan() /git/vanilla-cli/src/Vanilla/Cli/Command/AddonJsonCmd.php:48
    1.1674    2578576   7. Vanilla\Addon->__construct() /www/vanilla/library/Vanilla/AddonManager.php:323
    1.1674    2578576   8. Vanilla\Addon->scan() /www/vanilla/library/Vanilla/Addon.php:67
    1.1722    2583824   9. Vanilla\Addon->check() /www/vanilla/library/Vanilla/Addon.php:116
    1.1723    2585056  10. Vanilla\Addon->triggerIssues() /www/vanilla/library/Vanilla/Addon.php:771
    1.1733    2585056  11. trigger_error() /www/vanilla/library/Vanilla/Addon.php:789

Here we have

• A notice that there was 1 error for the addon
• A callstack for that notice
• A notice of what that error was
• A callstack for that notice
• The same errors and callstacks again

Really this should just be:

1 Addon has 1 issue

The addon in /themes/bigfish has 1 issue
    - The type info field is required

The callstacks really shouldn't be visible they don't provide any relevant context here as far as I can tell.

For our use case we don't need to go overboard. Just red, blue, green, and yellow should do the trick.

It should return strings with the proper ANSI escape sequences that can then be concatenated with other strings or printed to the console.

Once the vanilla docker container is completed we should offer a setup command in this tool.

It would have the following global dependencies

• git
• docker
• php/composer (already dependancies of the CLI)

It would

1. Check that git and docker are installed and link to setup docs for them if not installed.
2. Prompt for a directory to setup vanilla into.
3. Verify that it can write to those directories.
4. Clone vanilla/vanilla, vanilla/vanilla-docker, and vanilla/addons into that directory.
5. Save that directory to configuration file.
6. Install dependencies for Vanilla.
7. Initialize the docker container (run it's setup script).
8. Open a browser to that installation so the setup page opens.
9. Print out the configuration that needs to be entered.

Let's make this an OSS project.

Bundle should be able to be dynamically imported with import('modulename').then(module => {});.

These will need to have a deterministic base path so they can automatically be loaded.

A star entry will be process as being a part of every section.

addon.json

{
    "key": "core",
    "build": {
        "process": "core",
        "exports": {
            "*": [
                "./src/scripts/events",
                "./src/scripts/utility",
                "./src/scripts/dom-utility",
                "axios",
                "react",
                "react-dom",
                "api-utility"
            ],
            "app": ["./src/scripts/other"]
        }
    }
}

{
    "key": "core",
    "build": {
        "process": "core",
        "entries": {
            "bootstrap-app": "./src/scripts/bootstrap/bootstrap.js",
            "bootstrap-admin": "./src/scripts/bootstrap/bootstrap.js"
        },
        "exports": {
            "app": [
                "./src/scripts/events",
                "./src/scripts/utility",
                "./src/scripts/dom-utility",
                "axios",
                "react",
                "react-dom",
                "api-utility",
                "./src/scripts/other"
            ],
            "admin": [
                "./src/scripts/events",
                "./src/scripts/utility",
                "./src/scripts/dom-utility",
                "axios",
                "react",
                "react-dom",
                "api-utility"
            ]
        }
    }
}

The polyfills are always getting loaded from the root which won't work when Vanilla is installed in a subdirectory.

Note that this PR adds a meta variable called assetPath which is the proper root for the javascript static assets.

Currently the tool expects the core js

• src to be at /core/src/js
• addon.json file at /core/addon.json
• build to /core/js

All of this should be moved up so that

• src is at at /src/js
• addon.json file at /addon.json
• build to /js

Something in line with this https://webpack.js.org/guides/shimming/#global-exports

This will need to be configurable through the addon.json file.

We should check for this case and throw an error.

If an addon specifies "hidden": true we should probably not throw an icon error. These plugins are not meant to be seen in the dashboard.

Adding this for sprint purpose.

The dashboard application is enabled in config-defaults rather than config. Adding the following to config is a workaround for now:

$Configuration['EnabledApplications']['Dashboard'] = 'dashboard';

Currently many of the pluins and themes are using completely different build processes, many of which are barely tested or have weird bugs in them. Our addons should migrate to a single (possibly extensible) build process for all addons. This would:

• Make our builds more consistant
• Prevent us from having to install hundreds of MBs of dependancies (lots of duplication) across all of our different addons
• Make contributing to an addon easier
• Allow us to have much shorter Readme's for themes and plugins (No need to document build process)

All of the tooling for front-end dependancies are in javascript and I have already written some tools to scaffold out much of the tooling, but keeping the build process here would prevent most of that code duplication. It would also allow us to enforce basic linting and code quality metrics across our frontend code.

As a result of most this tooling being javascript based this would make vanilla-cli require a local node installation however.

Often customer plugins do very little, but are quite disconnected due to the event handling nature of plugin classes. There are a couple of things here where the Vanilla CLI could auto generate stuff (events handled and events fired).

We should create a command that generates documentation about:

• Events that are handled
• Endpoints created
• Permission created
• ...

• Babel 6 -> 7

Status: In late stages of beta. We will wait for the release.

• Updated simpler polyfills

• Updated transforms (many of our stage 3 transforms are not official and in stage 4), and rest/spread + class properties are stage 3, + private properties and methods.

• Webpack 3 -> 4

Status: Releases of ~1 month. Will wait for the babel changes.

• 2x build speed / Large speed improvements.
• Smaller configs.
• Bundle size decreases

https://github.com/gaearon/react-hot-loader

The addon build process is meant to build against an already generated DLL from the core build process #45.

It must support

• React/JSX
• Preset-env
• FlowType
• object-reset-spread
• Multiple bundles. addon.js && addon-admin.js.
• Builds against the core bundle and does not duplicate common modules.

Add typescript support.

Look into:

• Do we need typescript -> babel or will typescript on its own work. I think it will now.
• Make sure interop between js and ts works.
• Ensure we can rename files gradually.

Running the addon-doctor command has revealed that many addons now have keys that are lowercased where they were previously UpperCamelCased. As a result many of our core plugins now have mismatched keys and folder names.

This is the commit that seems to have done it.

Is this related to #5680 Properly set keyRaw for applications if not defined?

In order for the CLI to run from a composer global install it should have it's bin properly set up. Have a look at https://github.com/vanilla/github-sync for details.

A build referencing a parent DLL currently needs to import with file paths include the root of the src.

EG.

import Foo from '@core/src/js/Foo';

// instead of 

import Foo from '@core/Foo';

JSON_UNESCAPED_UNICODE and JSON_UNESCAPED_SLASHES needs to be added.

#24 Provides a custom importer function to allow easier importing of css from the node_modules folder. I failed to consider the way sass imports file with the explicit extension of .css. If sass sees an @import 'somefile.css' It will transform it into a true css import like so: @import url("somefile.css"). Some popular libraries mark the package field with a css extension like this, so the importer should handle this case. It just needs to subtract the extension from the file and sass will compile it without issue.

This script should crawl all addons in a vanilla installation (regardless of their enabled state) running the core build process and build production versions of their scripts and stylesheets.

Once the vanilla docker container is completed we should offer a testing command in this tool.

It would have the following global dependencies

• docker
• php/composer (already dependancies of the CLI)

Parameters

• --testsuite [suitename]
• --vanillaSrcDir [dirname]

What it would do

• Check for saved installation directory, enviromental variable, or passed arg to determine the installation folder.
• Prompt for one if it is not provided and save it.
• Check that docker is installed/setup.
• Attempt to run the given test-suite (or all as the default) in the docker container.

When I'm building a theme I want to be able to access the scss from its parent theme(s). If I add my own scss file then it should be used instead. Here is my basic idea.

Parent theme: style.css

@import "theme/style";

Child theme: style.css

@import "variables";
@import "theme/style";

The child theme overrides the parent theme completely, but we make the files that are overridden very light.

I can see an issue where the child may accidentally override a parent theme's file when it shouldn't. My proposed solution involves a convention where parent themes but their SCSS into an implementation folder where child themes always add to the root. In the example above the parent theme would have a file called theme/variables for default variables and the child theme overrides it in just variables. Let's discuss.

Create the vanilla doctor command that will scan addons and check for issues that can be corrected. The initial issues should be:

1. Addon folder name does not match its key.
2. Addon does not have an icon.

Right now the BuildCmd implements its own logic and lookups for the the enabled addon of a site. Instead it should leverage Vanilla's AddonManager or AddonApiController. The existing AddonManagerTrait can get us the AddonManager.

The build commands should lint the files they are building. It is tedious to have to run the linter in another window.

Use Jest to get some basic testing setup. Snapshot testing seem like a good match for file output.

Add a GPLv2 license file.

The new base theme will have a new style standard for CSS and JS. We need to add support in vanilla-cli to use the linter config inside the new base theme.

Eventually, when we're satisfied with it, we can move it into vanilla-cli and version it, so the config will be the same across vanilla.

I'd like to discuss the build tool's javascript functionality. Here is some of the functionality I want:

Addon concatenation

Addons have their javascript built seperately and will be included in sequence for development and concatenated in production (eventually).

• We can have a core javascript libary that all addons can assume exists. Addons should not include the core javascript in each build.
• Can we still get hot reloading with multiple javascript files in development? Is there another way we can handle development? (ex. devs just specify the addons to include in development builds in a JSON somewhere).

React.js capability

We want react.js functionality in core. I think this just means adding it the the config and making sure it is built into the core bundle.

Regular js

We have a lot of plain non-react javascript that will have to be built or ported. It would be nice to be able to program in ES6 modules though.

Conditionally loading polyfills

Can we have conditionally loaded polyfills asyncronously loaded into older browsers? It would be nice to not have to think about this loading.

So for example, I specify babel-polyfill in a polyfills config somewhere and it gets built into a seperate javascript file and automatically loaded if necessary in older browsers.

Dynamically loading libraries

This is similar to conditional polyfill loaders, but would allow us to specify some larger, rarely used libraries to load dynamically.

• A couple examples would be c3.js and swagger-ui.js. Both these libraries are only required on one page in the dashboard and it would be nice to load them on-demand.
• The best solution would involve allowing developers to specify dependencies using ES6 like usual and then specifying some of those dependencies as dynamic in a config somewhere and then having webpack know to load them asyncronously. If webpack has a plugin that can do this we could make an endpoint to resolve the libraries in a normalized way.
• If the above is not possible the programmer could ask to dynamically load the library.

Multiple entry points

Addons will often have several javascript files. Here are some examples:

• Addons will often have user-faceing javascript administrative facing javascript. These are almost like two seperate applications.
• Addons may need to include other vendor libraries that are dynamically loaded.
• In the future we may have a mobile javascript app which will need a seperate entry point.

Best practicies for jQuery and globals like window and document

Let's go over best practices for converting some of our current code into ES6.

• Currently we use IEFE's to protect the global scope. I think we can convert these to ES6 modules.
• In old javascript it's a best practice to take browser globals as parameters in your IEFE so that they can be changed later if necessary. Is there an ES6 module equivalent?

This build process should:

• Not have any export bundles (ignored, everything is one bundle).
• Dynamically generate a single entry point from all entries.
• take a --section parameter in order to build only for a certain section.
• Build all sections in parallel if no section parameter is passed.
• Make each dev server bundle available at the on a webpack dev server.
• Enable hot reloading (not react components yet).

I have no idea what you meant by this, but it was in #19.

• build command
• addon-json command
• addon-cache command
• addon-doctor command

We should have a wiredep plugin. The one we were using is incompatible with the current build process.

Create a build process for the the core vanilla javascript.

Requirements

• Babel support for: React, preset-env, FlowType, object-rest-spread
• Multiple entrypoints
• Separation between admin and frontend bundles
• Addons to build on top of other addons without screwing things up.
• Multiple bundles. core.js && core-admin.js.