The helpers do not have to have an own file and can be put into the e2e.task.ts file.

This would then generate statistics about the webpack bundle using the stats-webpack-plugin and visualize the bundle sizes using the webpack-visualizer-plugin.

Currently the tests are run by using karma and webpack simultaneously. It should be to configure it using https://github.com/webpack/karma-webpack plugin.

We should add an E2E test for each command.

Currently the defaults of the slim.config.ts are written inline in the cli-helpers.ts file. We should move the defaults and the slim.config.d.ts to a new directory from where the typings can be published.

The functions in cli-helpers.ts are mostly used by one task each. This means we can move the functions to their respective task and delete the file.

We should use the conventional changelog to generate a CHANGELOG.md from the git log.

In order to use something like https://github.com/nordnet/cordova-hot-code-push we should add a --watch option to the build command.

This would allow components to import a variables file that is not available until the component is used by another project.

#88 introduced a regression. The specified Sass files are now always excluded and not just during testing.

yargs already does all the things the three libraries are doing with an easier to use API. We should switch to yargs to reduce dependencies.
See http://blog.npmjs.org/post/119317128765/adding-subcommands-to-your-command-line-tool for an example.

The coverage report does not work currently. We could try using this package.

The target option could be used to build the application for a specific target. Possible values would be ios, android for apps and electron|nw.js for Portals.

Background

Currently we only start the unit tests in chrome by default. There is also the --browsers flag for the test command where you can supply a list like --browsers=chrome,safari,firefox to start the tests in several browsers.

Detect browsers automatically

There is this project, that allows us, to run the tests in all available browsers. This would especially be helpful for Continuous Integration systems.

Discussion

The discussion would be whether we should make it the default behavior or stick with the current one of just starting chrome.

#77 should have resolved the problem but it is still there.

When entering images into the slim.config.ts#images section, they are not rendered to the targetDir.

Black can't be seen on Dark terminal backgrounds.

We should make it possible to launch the tests in the Internet Explorer using https://github.com/karma-runner/karma-ie-launcher.

We should try to integrate https://github.com/AngularClass/angular2-hmr-loader for faster reloads.

Webpack 2 supports that functionality out-of-the-box, so we can remove the dependency.

It should be possible to declare libraries in the im2m.config.ts that should be included in the vendors.dll.js bundle which is generated by the dev --update-dlls command.

It does not make sense to minify the images during the build. This adds dependencies and build time and the results are not really predictable.
We will remove the images configuration in slim-config and rename extras to assets. The entries will have the following form:

{
    from: string,
    to: string,
    flatten: boolean
}

Projects like https://github.com/mgechev/codelyzer can help catch bugs early in the development process. So it should be possible to add lint rules that have also the ability to make a build fail.

It should be possible to create a component, application or cordova (with ionic) project. This should be done through the use of https://github.com/SBoudrias/Inquirer.js/.

When using the dev command there is the possibility to press "enter" to open the browser. Currently this opens a new window/tab for about:blank. It should navigate to http://localhost:<port>.

The dependency is not used and is an artifact of previous developments.

Currently one has to run dev --update-dlls after updating the vendor dependencies. This could be automated by a task that determines whether the DLLs have to be updated.

Current webpack.config.common.ts resolves modules using ["node_modules", path.resolve(__dirname, path.join(config.rootDir, "node_modules"))].

"node_modules" is relative to the cwd of the terminal executed in (=directory of consuming project) .

path.resolve(__dirname, path.join(config.rootDir, "node_modules")) explictly resolves to the directory of the consuming project.

It should first try to resolve modules through "node_modules" of the consuming project, but should fallback to "node_modules" in the slim project.

Otherwise consuming projects are required to install Webpack-Plugins and Entrypoints themself.

A flag should be added to the test command that creates a JUnit test result xml file after the tests have run.

The project is currently a mix of the workflow and the E2E test. The test project should be moved into an e2e directory.

When using the slim dev command without git versioning the following error appears.

fatal: Not a git repository (or any of the parent directories): .git
../../slim/src/cli-entry.ts dev

A real e2e test should be implemented and run on each PR.

We should use a tool like https://github.com/indexzero/ps-tree to kill all child processes after slim was shut down.

The templates have options that should be documented using a standalone typings project (similar to the slim-config) in src/config/template-config.

We should add unit tests to the project. We have to decide whether to use jasmine or mocha/chai/sinon. I am tending to jasmine as that is already the tool we are using in out client e2e and unit tests.
Mocha allows us to write the unit tests in typescript without compiling them first so I would rather choose mocha.

The custom typings should be moved into a separate directory and should be contributed to https://github.com/DefinitelyTyped/DefinitelyTyped if possible.

Currently when including moment.js in the build, all locales are included. It should be possible to set the languages of the application in the slim.config.ts.

awesome-typescript-loader is not as good as maintained as ts-loader. We should investigate whether a switch has any advantages. The effort would be pretty small.

Is the yarn.lock file necessary in development branch?
It's a source of merge conflicts.

Version 2.1.1 of webpack-merge just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As webpack-merge is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The command will publish the project to npm and if it succeeds to the remote git repo.

We should add a doc command that generates documentation for the current project using https://github.com/compodoc/compodoc

The release command should use the git flow style of releasing.

When there is no templates directory for the current user slim always issues this warning. The warning should only be visible if the new command is used.

The E2E tests should be executed using protractor and jasmine.

Is currently blocked by #5