search

superfly / fly

Deploy app servers close to your users. Package your app as a Docker image, and launch it in 17 cities with one simple CLI.
https://fly.io
985 stars 48 forks source link

Usage of buildApp function in @fly/build v0.53.0 #243

Closed Siilwyn closed 5 years ago

Siilwyn commented 5 years ago

:wave: hi there, I'm trying to update @fly/build from 0.51.2 to the latest version and noticed the buildApp function's signature changed in 0.53.0. With the 'old' function I wouldn't need to pass the output path: promisify(buildApp)(process.cwd(), { watch: false, uglify: true })

So I'm trying to figure out what to pass but the defaults for the input and output path seem quite complex now that JS and TS are automatically detected. Would it be an idea to have the defaults locally for buildApp to ease external usage so only uglify is necessary?

buildApp({
  uglify: true,
})

Edit, my perhaps naive external approach assuming defaults would be:

buildApp({
  inputPath: process.cwd(),
  outputPath: path.resolve('.fly/build'),
  uglify: true,
})

Is that correct?

michaeldwan commented 5 years ago

The values you have for inputPath and outputPath look good.

That got refactored heavily a few weeks ago while adding the new fly build cli command. While in there I fixed several path related bugs that surfaced after shipping prebuilt cli binaries that live in /usr/local rather than in ./node_modules. Reducing options and defaults helped simplify things a quite bit.

I can't remember exactly what your use case was, but if it's faster building I'm curious if the new cli would help you without having to call the build api directly.

Siilwyn commented 5 years ago

Ah I understand, I'm using fly in a CLI tool just to pack an app up so I don't want to include the heavy fly core for such a specific task. Guess I'll go with the defaults in my example then, thank you for your quick reply!