fix(types): Origin within OriginFunction can be undefined

[joshmeads]

In reference to #236 origin cannot be assumed to always be a string. Propose making it string | undefined to ensure people handle it correctly. This would flag quickly in the sync example on the README that new URL constructor can't work with undefined and should be tested to ensure it's a string first.

This also matches an existing test setup:

const corsDelegate: OriginFunction = (origin, cb) => {
  if (typeof origin === 'undefined' || /localhost/.test(origin)) {
    cb(null, true)
    return
  }
  cb(new Error(), false)
}

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[Uzlopak]

Can you add a typing test please?

[joshmeads]

Can you add a typing test please?

@Uzlopak apologies for the slow reply, busy time of year. What do you mean by typing test exactly? The altered code matches the test within tests/index.test-d.ts linked in the description. I can't see any type specific tests within the codebase unless I'm missing something obvious. Happy to do it though - just need a pointer on where to look :)

Thanks guys!

[Uzlopak]

Well, what issue does your PR fix. As you didnt change any test, we have to assume nothing was wrong in the first place...

[jeanvalentin]

This PR would prevent users from blindly calling new URL(origin) and throwing, like I just did. I assumed origin was always a valid URL; it is in fact not even guaranteed to be a string. Good call. You might want to update the example in the readme as well, by adding an instruction such as if (!origin) return cb(null, true); on top.

Another option is to prevent CORS checks from being performed when origin is empty, since that would not be cross-origin.

[Uzlopak]

How about patching tests/index.test-d.ts to reflect that?

[Uzlopak]

patched accordingly

[mcollina]

lgtm