@leanup/cli-svelte

This package contains the Svelte framework extension for the @leanup/cli.


Keywords
babel, snowpack, webpack, svelte, sinon, nyc, nightwatch, mocha, sass, typescript, cli, spa, pwa, lean, compiler, transpiler
License
Apache-2.0
Install
npm install @leanup/cli-svelte@1.3.51

Documentation


Make things pure ... to become lean.


license lernajs prettier @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/Technology Description Status Note Rating
TypeScript Language ✔️ ready typescript
Webpack Bundler ✔️ ready webpack
Snowpack Bundler in progress webpack
Vite Bundler in progress webpack
esbuild Transpiler ✔️ ready esbuild
swc Transpiler ✔️ ready swc
Babel Transpiler ✔️ ready @babel/core
Mocha Unit-Test-Runner ✔️ ready mocha
Chai Assertion ✔️ ready chai
Sinon Mocking ✔️ ready sinon
NYC Code-Coverage ✔️ ready nyc
ESLint Code-Checker ✔️ ready eslint
Nightwatch.js E2E-Test-Runner ✔️ ready nightwatch
Allsure Report ✔️ ready
Cucumber BDD ✔️ ready cucumber
robotframework BDD will be evaluated
Storybook Documentation in progress storybook
OpenAPI API ✔️ ready
GraphQL API ✔️ ready graphql
Workbox PWA ✔️ ready workbox
Lerna Mono-Repo ✔️ ready lerna
Ant-Design Design-System ✔️ proved antd
Bootstrap Design-System ✔️ proved bootstrap
Material Design-System ✔️ proved @material/textfield
Tailwindcss Design-System ✔️ proved tailwindcss
WindiCSS Design-System ✔️ proved tailwindcss
Nexus IQ Vulnerabiliy-Gate ✔️ ready
Less CSS ✔️ ready less
Sass CSS ✔️ ready sass
PostCSS CSS ✔️ ready postcss
TSArch Architecture in progress hint
Webhint Webhint ✔️ moved *** hint
TestCafe E2E-Test-Runner will be evaluated **** testcafe
TSLint Code-Checker removed ** tslint
Cypress E2E-Test-Runner excluded * 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