Awkward store/challenge instantation #21

New Issue

Ghost · 2020-04-27T18:39:06Z

Ghost commented

2020-04-27 18:39:06 +00:00

It looks like I have to pass a file path to greenlock to load custom stores/challenges.

i.e.

greenlock.create({
    store: {
      module: __dirname + "/lib/le-sql-store",
    },
})

as opposed to:

greenlock.create({
    store: myStoreObj
})

The reason this is awkward is that the store now needs to be instantiated separately and the config for that instantiation saved into global vars.

e.g.

myStoreObj = CreateStore(postgresPool)
greenlock.create({
    store: myStoreObj
})

and the store looks like:

const config = {};
module.exports.create = function (options) {
  if (options.pgPool) {
    config.postgresPool = options.postgresPool;
  }

  const postgresPool = config.postgresPool;

It's fine... just a pain to debug unless you look at the source.

It looks like I have to pass a file path to greenlock to load custom stores/challenges. i.e. ``` greenlock.create({ store: { module: __dirname + "/lib/le-sql-store", }, }) ``` as opposed to: ``` greenlock.create({ store: myStoreObj }) ``` The reason this is awkward is that the store now needs to be instantiated separately and the config for that instantiation saved into global vars. e.g. ``` myStoreObj = CreateStore(postgresPool) greenlock.create({ store: myStoreObj }) ``` and the store looks like: ``` const config = {}; module.exports.create = function (options) { if (options.pgPool) { config.postgresPool = options.postgresPool; } const postgresPool = config.postgresPool; ``` It's fine... just a pain to debug unless you look at the source.

coolaj86 commented

2020-04-29 16:14:55 +00:00

Yes, there is a reason.

I didn't want to support multiple ways of doing it, and I wanted it to be possible to store the configuration as in a database.

Since you can store a module name in a database, but you can't store a function in a database, I picked the former.

What about it is hard to debug? Or how could I make that easier?

Yes, there is a reason. I didn't want to support multiple ways of doing it, and I wanted it to be possible to store the configuration as in a database. Since you can store a module name in a database, but you can't store a function in a database, I picked the former. What about it is hard to debug? Or how could I make that easier?

Ghost commented

2020-04-30 13:48:23 +00:00

What about it is hard to debug?

I think it currently returns an ambiguous undefined error. Then when I started looking into it, I was surprised that instantiation worked like this, I almost didn't believe it (relying on a global var cached in a module). Then I found an example store where I saw you instantiate and cache the config in the module.

Or how could I make that easier?

Just needs an error message.

> What about it is hard to debug? I think it currently returns an ambiguous undefined error. Then when I started looking into it, I was surprised that instantiation worked like this, I almost didn't believe it (relying on a global var cached in a module). Then I found an example store where I saw you instantiate and cache the config in the module. > Or how could I make that easier? Just needs an error message.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: root/greenlock.js#21