Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

klap vs microbundle? #36

Open
tleunen opened this issue Jan 16, 2020 · 7 comments
Open

klap vs microbundle? #36

tleunen opened this issue Jan 16, 2020 · 7 comments
Labels
documentation Improvements or additions to documentation help wanted Extra attention is needed

Comments

@tleunen
Copy link

tleunen commented Jan 16, 2020

Looks like klap is in the same domain as microbundle. Would be nice to compare the 2?

@tunnckoCore
Copy link

For me, personally

  • cleaner and more organized codebase
  • zero deps
  • different set of default babel and rollup plugins
  • microbundle supports Buble

@osdevisnot
Copy link
Owner

Let's add comparison section in readme. I'll keep this open in case someone gets there before me.

@osdevisnot osdevisnot added documentation Improvements or additions to documentation help wanted Extra attention is needed labels Jan 17, 2020
@osdevisnot
Copy link
Owner

@tunnckoCore it seems microbundle moved away from buble. Am I missing something?

@osdevisnot
Copy link
Owner

osdevisnot commented May 13, 2020

I did a quick comparison between klap, microbundle and tsdx. Here are notable differences:

👼 Comparison with microbundle and tsdx

Feature klap microbundle tsdx
Typescript Support
No Dependencies
Scaffolding
Dev Server
CSS
CSS Modules
Build Constants
Testing/Linting

We should probably start supporting build constants and some variation of CSS (maybe using postcss).

The testing/linting setup is not a primary goal for klap and we can skip it.

@tunnckoCore
Copy link

Yup, true, they kind of moved to a hybrid approach as I remember.

Agree.

Build Constants

What do you mean with that? TSDX supports transforming such things, I think. :)

@osdevisnot
Copy link
Owner

Build constants are essentially constant variables that are pre-defined. Similar to process.env.NODE_ENV, but more granular.

For example, you can define a constant called DEBUG = true and use DEBUG in your library code when developing, maybe like this:

if(DEBUG){
	console.log('this was never supposed to happen')
}

Then you just run the build for distribution with DEBUG = false and all your code within the if block get's removed.

Another use case is when you want to create multiple versions of your library with certain features on/off based on a defined build constant.

@tunnckoCore
Copy link

Exactly. TSDX does this. Dev expressions, node_env and etc, also uses the replace plugin, so.. probably possible to customize further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants