-
Notifications
You must be signed in to change notification settings - Fork 26
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
Using Harmonic programmatically #96
Comments
Sounds good to me. The API would be useful for unit tests as well. |
Yep! I'll create a branch for that. |
…ith 6to5 Closes #86 Closes #87 Paving the way for #96 (allow APIs to receive a sitePath argument) TODO check if build's copySrc is copying files which have been negated by globs before being re-included TODO check why build task takes so long to finish when passing an absolute sitePath argument and CWD != sitePath (the `harmonic build` in the unit test takes about 11 seconds to finish in Windows)
How should the API look like? Rough idea I had: var harmonic = require('harmonic');
// Factory pattern (like express), to cover use cases that manipulate multiple Harmonic sites.
// The factory constructor takes a sitePath argument that is saved in the instance,
// to avoid repeating it in every .init()/.config()/.build()/.run() call.
var mySite = harmonic('path/to/my/site');
// all async methods return promises
var promise = mySite.init();
promise.then(function() {
return mySite.build();
}).then(function() {
console.log('all done!');
}, function(err) {
console.log('Something went wrong', err);
}); I believe we should give this some priority, so we can write tests for the API instead of using child processes. This way we can throw more meaningful errors without as much effort, and the tests will run much faster which is great for the incremental build workflow ( |
IMO we should make an API asap, expose it to users to experiment and gather feedback, then release Harmonic 1.0.0. From then on, we can follow semantic versioning. What do you think @jaydson? |
Totally agree. |
I believe it doesn't matter much who does it, as long as we agree on an API design. |
I believe we can assign issues to ourselves when we start working on them, so others will know there's someone working on it. |
That's a good approach. |
@jaydson yes, we can use GitHub's issue assignment for that purpose. |
Yep, sounds good 👍 |
WIP > 432977c Basic example using it: var Harmonic = require('harmonic');
var mysite = new Harmonic('./path');
mysite.init()
.then(function(data) {
console.log(data);
});
mysite.newPost()
.then(function(data) {
console.log(data);
});
mysite.build()
.then(function(data) {
console.log(data);
}); One of the benefits of a promise-based API: we can use async/await. (async function(){
let mysite = new Harmonic('path');
await mysite.init();
await mysite.newPost();
await mysite.build();
}()); |
Nice! 👍 |
While at it, perhaps we should do some major refactoring/code organization? Maybe |
Yes, i was thinking exactly the same. |
We can turn Harmonic into a module that can be loaded locally, so other modules can use it programmatically.
Example:
I think that feature will be helpful in some way.
The text was updated successfully, but these errors were encountered: