You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 5, 2023. It is now read-only.
The recommended setup process is rather unconventional and difficult to recall without referencing the README. I think a better approach would be for the fly CLI to have a built in generator replicating the project structure in the referenced gist.
Setup might then look something like:
# create fly app, project folder, and `.fly.yml` config# walk user through setup (similar to `npm init`):# - name: example-app# - eject (Y/n): y# - typescript (Y/n): y# - ...
fly apps create
If the user chose not to "eject" their fly app configuration into code upon initial setup, that can still be done later at anytime (prior art: Angular's ng eject):
# code generation based on current `.fly.yml` config# create webpack, tsconfig, etc if they don't exist (error if they do)# create/update `package.json` (adding `@fly/cdn` dependency)# remove `flyCDN` config from `.fly.yml`
fly apps eject --app <name>
Another option, upon ejecting the config, would be to store fly-related configuration in the package.json and eliminate .fly.yml entirely. As an example, babel allows you to do this in place of a .babelrc.js). Would be nice because things like name could be shared between the two.
The text was updated successfully, but these errors were encountered:
The cli's app generator could do this. Right now it's giving the user a choice to clone an app from the examples package, but maybe it'd be better to remove the multiple choice and clone a fully configured cdn app instead.
The recommended setup process is rather unconventional and difficult to recall without referencing the README. I think a better approach would be for the
fly
CLI to have a built in generator replicating the project structure in the referenced gist.Setup might then look something like:
If the user chose not to "eject" their fly app configuration into code upon initial setup, that can still be done later at anytime (prior art: Angular's
ng eject
):Another option, upon ejecting the config, would be to store fly-related configuration in the
package.json
and eliminate.fly.yml
entirely. As an example,babel
allows you to do this in place of a.babelrc.js
). Would be nice because things likename
could be shared between the two.The text was updated successfully, but these errors were encountered: