Consider monorepo / ECDSA Support #4

Closed
opened 2018-01-08 13:06:27 +00:00 by Ghost · 4 comments

Currently, the family of greenlock packages are split across a dozen or so repos across different git hosting sites, each at different version. Links in docs are also constantly being broken.

This makes it very difficult to track what versions are actually in use, and very difficult to contribute things requiring coordination between different greenlock packages.

Considering switching the whole family of packages to a monorepo. This has all the benefits of having independently versioned modules, while still allowing easy coordination between them. Links in docs can also be relative to the repo instead of absolute to a git hosting site, which is apparently subject to changes every once in a while.

(P.S. I'd like to contribute ECDSA support, but I'm having a very hard time tracking the lower layers of greenlock, and figuring our what to contribute where, so at this point, I've given up before I've even made an attempt... Switching to a monorepo would help me A LOT)

Currently, the family of greenlock packages are split across a dozen or so repos across different git hosting sites, each at different version. Links in docs are also constantly being broken. This makes it very difficult to track what versions are actually in use, and very difficult to contribute things requiring coordination between different greenlock packages. Considering switching the whole family of packages to a [monorepo](https://github.com/babel/babel/blob/master/doc/design/monorepo.md). This has all the benefits of having independently versioned modules, while still allowing easy coordination between them. Links in docs can also be relative to the repo instead of absolute to a git hosting site, which is apparently subject to changes every once in a while. (P.S. I'd like to contribute ECDSA support, but I'm having a very hard time tracking the lower layers of greenlock, and figuring our what to contribute where, so at this point, I've given up before I've even made an attempt... Switching to a monorepo would help me A LOT)
Owner

Yeah... this repo has been an unfortunate victim of a lot of political nonsense. :-/

I agree in theory with the monorepo and have considered the approach before. The only problem is that npm doesn't support git subtrees and they have no plans to support it.

I can help you add ECDSA support. I'd love that.

Yeah... this repo has been an unfortunate victim of a lot of political nonsense. :-/ I agree in theory with the monorepo and have considered the approach before. The only problem is that npm doesn't support git subtrees and they have no plans to support it. I can help you add ECDSA support. I'd love that.
Owner
ECDSA key support needs to happen around here: ~~https://git.coolaj86.com/coolaj86/le-acme-core.js/src/master/lib/register-new-account.js#L12~~ And here: ~~https://git.coolaj86.com/coolaj86/le-acme-core.js/src/master/lib/acme-client.js#L15~~ And here: https://git.coolaj86.com/coolaj86/greenlock.js/src/master/lib/core.js#L15 And there would need to be some sort of new option here: https://git.coolaj86.com/coolaj86/greenlock.js/src/master/lib/core.js#L49
coolaj86 changed title from Consider monorepo approach to Consider monorepo approach / ECDSA Support 2018-04-19 20:12:05 +00:00
coolaj86 changed title from Consider monorepo approach / ECDSA Support to Consider monorepo / ECDSA Support 2018-04-19 20:12:16 +00:00
Owner

I've updated the API library for Let's Encrypt v2 (aka ACME v2 aka ACME draft 11)

https://git.coolaj86.com/coolaj86/acme-v2.js

That's the first place to start to add ECDSA support.

I've updated the API library for Let's Encrypt v2 (aka ACME v2 aka ACME draft 11) https://git.coolaj86.com/coolaj86/acme-v2.js That's the first place to start to add ECDSA support.
Owner

Closing as the feature is being worked on in the aforementioned repo, but making a note to update for those following when it's released.

Closing as the feature is being worked on in the aforementioned repo, but making a note to update for those following when it's released.
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: coolaj86/greenlock.js-ARCHIVED#4
No description provided.