Skip to content


Make things pure ... to become lean.


licenselernajsprettier@leanup/cli

leanup js

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

Motivation

  • Learnability
  • Controllability
  • Universality
  • Flexibility
  • Scalability
  • Durability
  • Transparency

Our home stories

In 2021

Transpilers

We switched from Babel to esbuild and from esbuild to swc (without Angular and Vue with proprietary template notation). And we can switch again if we want.

The performance of esbuild and swc are almost twice as fast as with the classic configuration. But there is currently no noticeable difference in performance between esbuild and swc.

Frameworks

We added two more frameworks (Lit and Solid) without any problems, without having to change the basic stack.

We have switched our Demo-Template from Bootstrap to Tailwindcss and from Tailwindcss to WindiCSS and now use the automatic application-specific CSS generation.

Bundlers

We tried two new bundlers (Vite and Snowpack) and integrated them for most frameworks. Alternatively, they can be installed alongside or instead of webpack.

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/TechnologyDescriptionStatusNoteRating
TypeScriptLanguage✔️readytypescript
WebpackBundler✔️readywebpack
SnowpackBundlerin progresswebpack
ViteBundlerin progresswebpack
esbuildTranspiler✔️readyesbuild
swcTranspiler✔️readyswc
BabelTranspiler✔️ready@babel/core
MochaUnit-Test-Runner✔️readymocha
ChaiAssertion✔️readychai
SinonMocking✔️readysinon
NYCCode-Coverage✔️readynyc
ESLintCode-Checker✔️readyeslint
Nightwatch.jsE2E-Test-Runner✔️readynightwatch
AllsureReport✔️ready
CucumberBDD✔️readycucumber
robotframeworkBDDwill be evaluated
StorybookDocumentationin progressstorybook
OpenAPIAPI✔️ready
GraphQLAPI✔️readygraphql
WorkboxPWA✔️readyworkbox
LernaMono-Repo✔️readylerna
Ant-DesignDesign-System✔️provedantd
BootstrapDesign-System✔️provedbootstrap
MaterialDesign-System✔️proved@material/textfield
TailwindcssDesign-System✔️provedtailwindcss
WindiCSSDesign-System✔️provedtailwindcss
Nexus IQVulnerabiliy-Gate✔️ready
LessCSS✔️readyless
SassCSS✔️readysass
PostCSSCSS✔️readypostcss
TSArchArchitecturein progresshint
WebhintWebhint✔️moved ***hint
TestCafeE2E-Test-Runnerwill be evaluated ****testcafe
TSLintCode-Checkerremoved **tslint
CypressE2E-Test-Runnerexcluded *cypress

* 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.

Ecosystem structure

Vanilla Java-/TypeScript are supported by default. That means for example custom elements and any plain Java-/TypeScript code.

Frameworks

Vanilla Java-/TypeScript are supported by default. That means for example custom elements and any plain Java-/TypeScript code.

The selection of the following frameworks depends in parts on the following references:

Currently the following framework extensions are available:

Extensions

A separate package contains some nice but not required addons for webpack.

Thinks

There a separate packages for important application features.

Alternatives

  • Angular @angular/cli
  • Neutrino neutrino
  • Rome neutrino

About

Generic CLI to develop, test and build a SPA/PWA (framework independently)

Resources

Code of conduct

Contributing

Security policy

Stars

34 stars

Watchers

1 watching

Forks

Releases

Sponsor this project

Packages

Contributors

Languages