${param} variables are not resolved in constructs

[pedrodim]

I just spent several hours trying to understand why the parameters from the serverless dashboard weren't correctly being passed to lift plugin until I came across this note on the serverless plugins' guide.

Note: Variable references in the serverless instance are not resolved before a Plugin's constructor is called, so if you need these, make sure to wait to access those from your hooks.

Which means that trying to do the following will result in an error "ARNs must start with "arn:" and have at least 6 components: ${param:CERTIFICATE}".

constructs:
  app:
    domain: ${param:DOMAIN}
    certificate: ${param:CERTIFICATE}
    type: static-website
    path: dist

I fixed it on a fork moving the Constructs loader to the initialize hook pedrodim@1c47638, which seems to work fine for the Static website construct (it does correctly deploy my website without errors) but obviously now some tests are broken and I have no idea how to fix those.

[mnapoli]

Hey @pedrodim, thanks for the report. This is indeed something that we need to clarify: because of the way Serverless loads all the plugins and resolves variables, this leads to some circular dependencies with constructs.

Using the initialize hook indeed messes up a few things.

I'll investigate right away if we can solve this specifically. If we can't, I'll document the limitation.

[pedrodim]

Thank you so much!

An idea could be have each construct expose a initialize hook (like they do currently with afterDeploy) so that they could instantiate any dependency or internal config which could use variables there instead on the constructor.

From what I've seem on serverless/serverless#3911 other plugins have solved this by moving any logic that uses variables to a hook, maybe it is something that cannot be possible for all actual constructs but for some this could be a workaround.

[mnapoli]

constructs:
    jobs:
        type: queue
        worker:
            handler: worker.handler
        maxRetries: ${param:maxRetries}
        batchSize: ${env:BATCH_SIZE}

In the example above, ${env:BATCH_SIZE} will be resolved correctly, but not ${param:maxRetries}.

The reason (I suspect) is related to the order in which variables are resolved. I'm still digging into it, I may have a lead.

[mnapoli]

I am working on #31 that should fix this issue.