Microbundle: Proposal for serve command?

[tunnckoCore]

Heya! :tada:

First of all, yea.. it is not for apps (i think?), but it is possible to some extent. So we may include rollup-plugin-serve or *-server, and rollup-plugin-livereload.

Currently you can use watch and in another terminal to use some static serving tool, like wrapping micro(-dev) or directly us serve / budo. Budo is good enough and has livereload, but it bundles one more time unneccesary (cuz the trick is to budo dist/bundle.cjs.js --live). Also, you need to handle cleaning of dist and creating a index.html. So the scripts are something like that

{
  "scripts": {
    "index": "echo '<script src=\"./index.js\"></script>' > dist/index.html",
    "clean": "rm -rf dist",
    "predev": "yarn clean && mkdir dist && yarn index",
    "dev": "microbundle watch -f cjs --inline none",
    "server": "budo dist/index.js --live --port 5000"
  }
}

[fwilkerson]

@olstenlarck Hi, I put together a small wrapper on microbundle that will serve your files and give you live reload. You can find the repo here https://github.com/fwilkerson/microenvi. It still needs a few features, but has served me well for prototypes and some browser environment libraries I've been working on.

[developit]

Why don't we add a link to Microenvi to the readme? I like the idea of keeping build + serve separate - in my case, I only use Microbundle for libraries, so I don't need the server bit.

[fwilkerson]

That would be cool, I just put up a new version to go with 0.4.4.

Perhaps link to it and other things using microbundle between roadmap and license?

[developit]

Yup! That'd be great, if you want to PR :)

[cvan]

first off, thanks so much for making this useful project! it reduces all the unnecessary boilerplate build-step BS I am not fond of that is so prevalent these days.

@developit: do you feel strongly about not including this in the core project? I have used @mattdesl’s https://github.com/mattdesl/budo for a lot of projects. it ships with a local-dev server, but the project is admittedly more aimed for web-app development.

in the projects I am working on that use microbundle, I also have an npm-run-all -p command to also run live-server with live-server-https. it works well!

any appetite for including that setup or @fwilkerson's microenvi out of the box?

[developit]

I'm not entirely against including a serve command. It would need to be useful for libraries though, not just web apps - maybe allow passing an alternative entry module so that a lib could microbundle serve its demos?

[ChrisBrownie55]

@developit I found this issue looking up how to do exactly that. I'm making a component to publish on npm and I'm planning on using microbundle and a microbundle serve command would definitely make that easier.

I think one of these might be nice:

Default values

Overriding the default values may become a concern at some point depending on what issues could arise. But defaulting to a tree structure like the following seems logical where demo/index.js is injected into demo/public/index.html.

.
└── demo
    ├── index.js
    └── public
        └── index.html

Pass filenames to serve

microbundle serve demo/public/index.html demo/index.js

Package.json

We could keep the information for serving in the package.json file under something like demo:

"demo": {
  "public": "demo/public/index.html",
  "entry": "demo/index.js"
}

[ChrisBrownie55]

I was looking at the directories.example for package.json and was thinking that if we defaulted to a specific folder structure one could change the folder that is used for serving via this property.

"directories": {
  "example": "path/to/my/demo-folder"
}

[benadam11]

Something like https://github.com/lukejacksonn/servor seems like it would pair really well with microbundle