--noDeploy -> serverless package

[mthenw]

TLDR:

Rename serverless deploy --noDeploy to serverless package or serverless artifact

Discussion:

I see great value in that feature. I think it should be separate command because right now it's not intuitive, it's confusing and serverless deploy --noDeploy is just weird.

It's not important but definitely something that IMHO should be solved before stable v1.0.

[nicka]

Agreed, specifying both deploy and noDeploy in one command could be confusing.

[pmuens]

@mthenw @nicka thanks for kick-starting the discussion. I would also like to keep everything in one plugin which implements the noDeploy functionality.

However this means that we might need to introduce new lifecycles. Furthermore this could be way too complex to get this artifact or package plugin implementation up and running (as @flomotlik pointed out).

Renaming the option might be an option here...

[flomotlik]

The problem with adding a separate command is that it just doesn't reflect the whole deployment workflow. At the moment the way the lifecycle and plugin system works we could not guarantee that a package plugin would run all the same plugins a deploy plugin runs. This could mean events aren't compiled or other custom plugins aren't run.

As we're not just zipping up the local folder but also want to write out the CF template we need to go through the whole deployment workflow.

So I'm very open to renaming the parameter. Anything we thought of so far in #1808 like package-only, plan or dry-run or others are just as confusing as we are not just packaging, planning or doing a dry-run. If somebody comes up with a better name I'm very open to that, but we won't implement a separate plugin due to the above mentioned issues with it. And this is an edge case in our plugin system that I don't think we need to spend a lot of time on implementing.

[nicka]

@flomotlik good point regarding the lifecycle hooks! What about something with the word compile in it?

[flomotlik]

Compile captures some parts of what is happening during deploy, but not everything. I don't think we can use a word that describes what happens, but we have to use something that describes what doesn't happen, e.g. noDeploy. Anything like compile, build, ... doesn't cover everything that could be potentially happening.

The other important thing to note here as well is that with noDeploy we also kind of force people to support it in their plugins. If they don't a specific plugin might still do something related to deployment (or fail like the info plugin currently is). So the whole thing kind of sucks, but I don't know a better way that makes sure it works longer term and is decently descriptive

[nicka]

I know we talked about separate build|compile and deploy command before. But the following might be possible.

Example:

• build|compile It's responsibility is to create the archives and the CF template
• deploy It's responsibility is to deploy(upload archives and trigger CF). If no archives or templates are present in runs the build or compile, or it could always start with doing this.

CI could also benefit from this during the build phase. Knowing your archives and template will be able to be build prior to the deploy phase(sort of already possible with --noDeploy).

[flomotlik]

you mean splitting the whole thing into two commands? The downside then is that the onboarding experience is MUCH worse (running two commands instead of one). --noDeploy is typically a rarely used feature. So just to make this a little nicer I wouldn't impact deployment or other key workflows that we have.

And its going to take time now to implement this when there honestly isn't really a need for it and we only have very limited resources. So I do see the point how this could make a few things better, but in general I don't think we're going to spend time on it at the moment.

[nicka]

Yeah exactly, two commands. The second command would just call the first one if it didn't run before. Anyways, I get your point that it would take quite some time to refactor etc 👍

[mbokman]

How about --export?

[flomotlik]

@mbokman getting closer to what it does, but the problem is still that its potentially not just exporting artefacts, but potentially doing more things depending on the plugins you've installed.

[flomotlik]

As we don't have any specific plans to change this now and to keep our open issue count low I'm going to close this issue. If you have any further ideas please put them here and we can reopen in case we get a good new proposed name