Open austencollins opened 5 years ago
I like what you did with Component Command + No File. It's obvious that the CWD always have to reflect a component (because there's a .serverless
dir), and it can get confusing without a serverless.yml
or serverless.js
file. This way users could add inputs easily via the yml file.
also, I'd remove the Using Components Programmatically Outside Of A Component section and add the following NPM cases:
if the user runs serverless imageResizer@1.0.0
, the framework would download this component from npm into the home directory (with caching funcntionaliy), and install it into the cwd via a yml file, and run the default command.
serverless imageResizer@1.0.0
- downloading imageResizer@1.0.0 in home dir (if it doesn't already exist)
- installing imageResizer@1.0.0 in cwd (via a yml file)
- running imageResizer
if a user needs to use a component from npm programatically as a child component, they'd have to install it locally with npm i -s imageResizer@1.0.0
, the use this.load
const imageResizer = await this.load('imageResizer')
Thoughts?
hmmm @ac360 honestly I think you're right. I'm starting to get confused when it comes to using serverless
without any arguments (componentName & method). It handles so many cases. Maybe we should be more explicit with serverless create
and/or serverless install
?
Yes, I agree with @eahefnawy here.
I like the listed functionalities, but I got confused about what happens when while reading through it.
Although, maybe it's just the written format which looks intimidating. I'd love to keep the CLI minimal and just typing in serverless
is really nice since you don't have to remember all the commands. Might be worthwhile to give it a spin and see how it feels.
This seeks to identify the usage patterns of V.2 so that we can focus on those exclusively.
Default Command + No File
If the user runs
$ serverless
in a directory where there is noserverless.js
orserverless.yml
, this should happen...Component Command + No File
If the user runs
$ serverless ChatApp
in a directory where there is noserverless.js
orserverless.yml
, this should happen...This installs the Component into the current working directory via a filled in
serverless.yml
file that looks like the one below. It also runs the Component's default method.Default Command + YAML File
If the user runs
$ serverless
in a directory where there is aserverless.yml
, this should happen...This runs the ComponentDeclarative Component default command.
Custom Method Command + YAML File
If the user runs
$ serverless [method]
in a directory where there is aserverless.yml
, this should happen...Only
$ serverless remove
is supported at this time in the ComponentDeclarative Component. Later, we can see if we'd like to add more (e.g.test
).Method & Component Command + YAML File
If the user runs
$ serverless [method] [component]
in a directory where there is aserverless.yml
, this should happen...This targets one of the top-level child components listed in the YAML file and tries to run that method.
Default Method + JS File
If the user runs
$ serverless
in a directory where there is aserverless.js
, this should happen...This runs the Component's default method.
Custom Method + JS File
If the user runs
$ serverless
in a directory where there is aserverless.js
, this should happen...This runs the Component's custom method, if it exists.
Using Components Programmatically Outside Of A Component
If the user requires a Component via NPM and chooses to run the default or a custom method in their code, this should happen...
The Component's logic runs.
It's not clear how this will work since the Framework constructs each Component and fills it with essential state to allow the Component to work.