Programmatic usage?

[callumlocke]

I need to use micro programatically, i.e. require('micro').

Is there any counterpart for this in micro-dev?

[leo]

micro-dev is a development CLI. For programmatic use, take advantage of the micro package. ☺️

[sergiodxa]

@leo I think the doubt is more about using micro-dev when using micro programmatically. You can just use micro-dev index.js if it's not exporting a function.

That mean if you use micro programmatically you can't get the advantages of using micro-dev

[leo]

The advantages of micro-dev can only be provided over the CLI. micro-dev is only meant to be used as a CLI in development. If you want its advantages, you need to use its CLI. There is no way we can provide this programmatically in a proper way.

[ramiel]

This is not clear. If I use micro in a programmatic way, there should be a way to launch micro-dev from cli and still support that way of launching the application

[alechp]

@leo Is there a way to use micro-dev from CLI while using micro programmatically?

Currently receiving this error:

micro: The file "/my...path/index.js" does not export a function.
micro: https://err.sh/micro/no-export

I tried @sergiodxa 's recommendation of appending the filename (ie. micro-dev index.js) but I received the same export error as just running micro-dev.

[tungv]

I know this is kind of an off-topic question. But I'm wondering why you guys want to use micro programmatically in the first place? I'm just trying to think about this issue another way around.

[alechp]

@tungv Good question.

Why programmatically?
I'm attempting to homogenize builds for multiple projects as much as possible.

What about micro CLI makes it difficult to homogenize builds?

• Inability to specify listen port (port exposure is relevant for Docker mapping)
• Needing to call micro instead of traditional node index.js equivalent (requires changes in both NPM builds and Dockerfile)

These are by no means hard blockers (I caved yesterday, reverted to non-programmatic build and specialized build for micro), but it's definitely frustrating to not be able to use micro-dev programmatically.

If that's a requirement, why not just use something like Express?

A few soft reasons (in order of high-low weighted relevance)

1. Emotionally bought into the zeit ecosystem. I love now & hyper
2. Micro-dev is beautiful & simple. Default hot reload and pretty logs save time
3. I'm interested in exploring; I've used Express for every microservice prior to this
4. Express has always seemed verbose to me

(PS. I see you contributed to hot reloading so thanks for that <3 )

[sergiodxa]

Inability to specify listen port (port exposure is relevant for Docker mapping)

You can use micro -p $PORT to customize the port.

Needing to call micro instead of traditional node index.js equivalent (requires changes in both NPM builds and Dockerfile)

With npm scripts I don't see how this is an issue, you can also use npx micro to run micro outside an npm script

[alechp]

I'm not sure I understand the relevance of npx micro suggestion. As I pointed out in previous post, I've already configured a specialty build for Micro. The mere fact of needing to alter my standard build/start script in the first place is the problem.

Having said that, given that I do need to specialize the build for micro, the port tip is helpful. Thank you, @sergiodxa

[sch]

Sounds like there's a lack of concrete use cases in this issue, so I'd like to throw in mine.

I currently use micro to serve a Typescript app. I have a src/index.ts file which gets compiled to a build/index.js file, which I point micro toward using the main key of my package.json. I have the following scripts set up for development and production:

{
  "main": "dist/index.js",
  "scripts": {
    "start": "micro",
    "build": "tsc",
    "dev": "ts-node --typeCheck node_modules/.bin/micro-dev src/index.ts",
    "postinstall": "npm run build"
  },
  "dependencies": {
    "micro": "^9.1.4"
  },
  "devDependencies": {
    "@types/micro": "^7.3.1",
    "@types/node": "9.4.7",
    "micro-dev": "^2.2.1",
    "ts-node": "^5.0.1",
    "typescript": "^2.7.2"
  }
}

I've also been testing a version that simply uses ts-node for production, to avoid an extra compilation step:

{
  "main": "index.ts",
  "scripts": {
    "start": "ts-node node_modules/.bin/micro",
    "dev": "ts-node --typeCheck node_modules/.bin/micro-dev"
  }
}

Being able to require a module before running the app might make this a bit cleaner, something like mocha's or nodemon's --require module flag: micro-dev --require ts-node/register. Or, being able to import micro-dev as a package would allow one to write their own start script, avoiding a tool like ts-node altogether:

// script/dev.ts
import microDev from "micro-dev"
import app from ".."

const server = microDev(app)

server.listen(3000)

This is similar to the issue pointed out in vercel/micro#337.

I hope this is helpful — something to keep in mind as you build out the micro ecosystem!

[LightningK0ala]

My use-case is I'm using websockets as per the micro examples.

[zackkrida]

I can definitely echo the websockets usecase—need to pass the server instance to socket.io so need to use micro programmatically.

[ansballard]

So I was making something similar work with tape, which doesn't have built in support for typescript/babel/etc. One of the workarounds to work with typescript (the others include --register flags like the ones mentioned above) is to call the tape binary from ts-node via ts-node node_modules/tape/bin/tape. This seems to work fine with micro-dev (as tested with sucrase):

sucrase-node node_modules/micro-dev/bin/micro-dev ./micro.ts -p 3001

Here I'm running a typescript file (types, imports, es7 syntax, etc) with sucrase, and passing args (port) to micro-dev, and it all seems to work as it should. Versions used:

micro: "^9.3.4",
micro-dev: "^3.0.0",

Hopefully that helps someone! Can confirm it's soooooooo much faster and concise than a separate tsc -w script.

Everybody else gave a use case, mine is that I run barebones mock APIs for my frontend typescript projects. I write my mock data in typescript so I can catch missing fields/typos, which means i can't import my mocks directly into micro without some sort of transpilation. Hence, this.