Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-architect Library to make more friendly for re-use #146

Open
zzolo opened this issue May 26, 2020 · 1 comment
Open

Re-architect Library to make more friendly for re-use #146

zzolo opened this issue May 26, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@zzolo
Copy link

zzolo commented May 26, 2020

Library is great, thanks for the awesome project. This is a large critique, but it is meant with the best of intentions. I fully understand that you all did not initially design this with a larger user-base outside NYT in mind.

Problem Description

Currently there is not really a great separation of the application, deployment, and customization, which makes it hard to manage those aspects well.

Though customization is possible with the custom/ directory, it could be improved. I would like to manage where my customization and options in a more directive way.

Managing the specific version of the Library application is difficult depending on how I deploy it. I'd like to be able to be more explicit about what version of the Library code I am using.

I am also bit confused on how I would locally test my own library without using the library codebase directly.

Feature

Redesign Library to be a dependency of a Node project, such that using it would be something like:

const library = require('library');
library.config({ customizations: 'path/to/customizations' });
library.start();

Or, you could design it as a command line tool with a configuration focus with a file, such as .library.json. It could assume the current directory is the customization library.

Or both, where the core application is a dependency of a command line tool.

Then deployment can be handled in many different ways and most appropriate for each user.

I don't think the project is that far off from this approach, but would definitely require a bit of effort. If you all are interested in exploring it, I could try to draft a pull request.

Additional Information

Projects that I think do similar things well:

@zzolo zzolo added the enhancement New feature or request label May 26, 2020
@afischer
Copy link
Member

Hey @zzolo, thanks for the suggestions — really like some of these ideas and customization patterns and it's definitely worth having a larger conversation about extensibility and customization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants