Bootstrap Kickstart 4.0

[mischah]

Roadmap for the next major release:

Working branch is v4-dev. Features should be implemented by creating feature branches and pull requests.

Basics (Prio 1)

• Replace Grunt with Gulp (4 Beta)
  • Update README
    • Changelog conventions
    • Replace Grunt with Gulp
    • Info regarding unit tests (watching) and coverage with Jest
  • Dev-Workflow (optional with watching)
    • Module bundling
      • Creating two bundles like before (own code / Vendor)
      • Rollup, Fuse-Box?!?
    • ES6 Transpiling (via Babel)
    • Linting
      • shouldn’t crash build
      • should run async (own pipe)
    • LESS Transpiling
      • Auto prefixing via LESS plugin
    • Dev Server
      • Browsersync
    • HTML Lint
    • Bootlint
    • Watch
    • Copy static files from node_modules to libs
    • Bundle external CSS to libs/libs.min.css
  • Production-Workflow
    • Exchange references to minified CSS/JS in HTML (processHTML)
    • Image Optimizing
    • Minify CSS via LESS transpiling
    • Minify JS via uglify
    • UnCSS
    • Serve build directory
    • NSP
  • Release Workflow
    • Bump version number
    • Git Tag version
      • Siehe krnlde/knockout-undoredo
• Sass instead of LESS (even with Bootstrap 3.x)
  • How will it work wit our workflow? See How to handle Bootstrap variables with Bootstrap 4  #41
  • Done: See Replace LESS with Sass #167

Nice to have (Prio 2)

• Dev-Workflow
  • Handlebars mit Frontmatterns und Templates und Partials
    • Done: See Compile handlebars templates #170
    • analog zu der jetzigen Grunt Lösung
    • Idee: Metalsmith nutzen. Siehe Beispiel oder eigenes Gulp Plugin schreiben.
• Production-Workflow
  • HTML minify (strip comments)
  • Unit Tests (mit Coverage) via Jest
  • Cachebusting
• Release Workflow
  • Changelog (Conventional Changelog)
    • Siehe krnlde/knockout-undoredo

Ideas / to discuss (Prio 3)

• Dev Workflow
  • Stylelint. See Linting LESS with stylelint #165 for details.
    • Done See Lint Less files using stylelint #168
• Node-RED
  • Evaluate Node-RED as alternative to the fake backend
    • Done: See Evaluate Node-RED as alternative to the fake backend #172

[mischah]

Question: Do we need JSDoc?

I don’t think so.
Okay. We are using JSDoc conventions for docBlock comments. But did we ever used generated docs in the past?

JSDocs make sense for generating API docs. But that’s not our use case with Bootstrap Kickstart.

Can I get a 👍 or 👎 for dropping JSDoc?

@krnlde @revrng cc/ @micromata/ux

[krnlde]

I prefer to read the docblock comments in the code itself rather than in a static, unsearchable documentation.

[mischah]

Removed JSDoc checkbox for now.
Willing to bring it back if someone desperately needs it.

[mischah]

Generating a changelog with »conventional changelog« using the Angular preset is now set up in the v4-dev branch.

You should write your commit messages with this conventions in mind.

Short summary of the conventions

Example commit message:

fix(uglify): Remove console output and debugger statements

Consists of:

type(scope): subject

Types

Types are used to group commits in the changelog.
Possible types which are rendered in the changelog are: feat, fix and perf.

There are additional ones which you can use. But these are only rendered if they introduce a breaking change:
docs, chore, style, refactor, and test.

Scope

The scope is optional and you can choose from whatever you want.
The scope is used as another grouping element below the type.

You can skip the parentheses if you don’t want to use Scope:

style: Fix linting errors 

Subject

The subject contains succinct description of the change:

• use the imperative, present tense: "change" not "changed" nor "changes"
• capitalize first letter
• no dot (.) at the end

Additional Info, Breaking changes and issue references

Are defined in the body of the commit message.

Example:

feat(build): Replace Grunt with Gulp
<BLANK LINE>
Closes #28
BREAKING CHANGE: Grunt Tasks aren’t available any longer.
But there are equvalent Gulp tasks. 
List the available tasks with `gulp --tasks`

The body can include the motivation for the change and contrast this with previous behavior.

Plus it should contain any information about Breaking Changes and is also the place to
reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Generated Changelog

This is how a changelog based on this conventions is rendered:
https://github.com/angular/angular/blob/master/CHANGELOG.md

---

See the last few commits of the v4-dev for some real life examples: https://github.com/micromata/bootstrap-kickstart/commits/v4-dev

[mischah]

I’ve released 4.0.0-beta.0 🎉

Let’s discuss what else we need to release v4 and what we could ship with a later release …

[mischah]

We won’t bring back ESLints fix option. See #164 for details. Thanks @krnlde for his valuable feedback.

[mischah]

I’ve released 4.0.0-rc.0 🎉

Can I haz sum feedback regarding #166?

Another question: Do you think we should add information how to change ESLint and Stylelint settings to the README?

[mischah]

Just made switched back the default branch to master in preparation for the release.
Related to #183

Make sure you switch to the correct target branch in case in case you open another PR for v4.

[mischah]

It’s done 🎉

https://github.com/micromata/baumeister/releases