leanup

Make things pure ... to become lean.

leanup^js

The @leanup ecosystem stands for a lightweight and pure way for application development in JavaScript/TypeScript.

Motivation
What makes the difference
Principles
Arguments
- Pro
- Contra
Demo’s
Tools
Ecosystem structure
Alternatives

Motivation

Learnability
Controllability
Universality
Flexibility
Scalability
Durability
Transparency

What makes the difference

Stop the transitive knowledge.

We use the minimal configuration and build no overhead stuff on top of the popular tools and make every native command transparent.

Principles

convention over configuration
pure commands under the hood
don’t repeat yourself
following the generic instead of the influenced way
keep the dependencies always up to date

Arguments

The arguments for and against this concept are documented here:

Pro

select only one pure and popular tool for each use case (e.g. bundling, unit-test)
there are extensible configuration files for each tool
due to the flat dependencies we can always stay up to date
the CLI bundles all the necessary tools in a portable/scalable way
the risk to get vulnerabilites in dependencies is lower
leanup’s own code is kept to a minimum

Contra

please give feedback

please show us your perspective

Demo’s

There are some working examples:

Tools

Tool/Technology	Description	Status	Note
TypeScript	Language	✔️	ready
Webpack	Bundler	✔️	ready
Snowpack	Bundler	⌛	in progress
Vite	Bundler	⌛	in progress
ESBuild	Transpiler	✔️	ready
Babel	Transpiler	✔️	ready
Mocha	Unit-Test-Runner	✔️	ready
Chai	Assertion	✔️	ready
Sinon	Mocking	✔️	ready
NYC	Code-Coverage	✔️	ready
ESLint	Code-Checker	✔️	ready
Nightwatch.js	E2E-Test-Runner	✔️	ready
Allsure	Report	✔️	ready
Cucumber	BDD	✔️	ready
robotframework	BDD	⌛	will be evaluated
Storybook	Documentation	⌛	in progress
OpenAPI	API	✔️	ready
GraphQL	API	✔️	ready
Workbox	PWA	✔️	ready
Lerna	Mono-Repo	✔️	ready
Ant-Design	Design-System	✔️	proved
Bootstrap	Design-System	✔️	proved
Material	Design-System	✔️	proved
Tailwindcss	Design-System	✔️	proved
WindiCSS	Design-System	✔️	proved
Nexus IQ	Vulnerabiliy-Gate	✔️	ready
Less	CSS	✔️	ready
Sass	CSS	✔️	ready
PostCSS	CSS	✔️	ready
TSArch	Architecture	⌛	in progress
Webhint	Webhint	✔️	moved ***
TestCafe	E2E-Test-Runner	⌛	will be evaluated ****
TSLint	Code-Checker	❌	removed **
Cypress	E2E-Test-Runner	❌	excluded *

* Arguments agains Cypress:

reinvent wheel

detect css selectors

BDD test syntax

principals

large tooling

a lot of binaries

many dependencies

ci integration vs selenium hub

It is difficult to keep focus with Cypress as it is more a nice tool than an effective tool. It is expected that a lot of time will be invested to justify the requirements of a project.

** TSLint is deprecated.

*** Webhint is not practical for the development of components, since component tags often have no relation to standard HTML. In addition, the webhint package alone is over 100 MB in size. I have good by using a IDE webhint plugin, like VSCode webhint.

**** TestCafe The idea that defined TestCafe architecture was that you don’t really need an external driver to run end-to-end tests in the browser. That’s interesting.