Proposal for serve command? about microbundle

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

[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?

[benadam11]

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

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

[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?

[andria-dev]

@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"
}

[andria-dev]

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"
}