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

Build system #8

Closed
addyosmani opened this issue Dec 26, 2013 · 10 comments
Closed

Build system #8

addyosmani opened this issue Dec 26, 2013 · 10 comments
Labels

Comments

@addyosmani
Copy link
Member

Ideally we want a setup that:

  • Supports authoring in markdown (multi-file)
  • Can be converted to multiple formats at build time easily (production-ready HTML, epub, PDF, etc.)
  • Can support multiple-languages. Consider a nice to have, but not critical for the initial version of the setup.
  • Does not require a large number of third-party binaries in order to work. I've had a lot of experience with these causing build problems on platform-X on other books, avoiding this would be nice if possible.
  • For any images, store the original source but builds should use optimized versions.
@addyosmani
Copy link
Member Author

Added to master:

  • Build system using Grunt
  • Markdown to HTML via grunt-markdown
  • Markdown to PDF via grunt-markdown-pdf

Considering whether or not to switch to https://github.com/sakunyo/grunt-pandoc instead. This would avoid the need to use separate tasks for each markdown -> X process but may be slower. Any opinions or alternative suggestions?

@michealbenedict
Copy link
Contributor

If it helps, we use grunt-pandoc to generate documentation internally just so we can avoid the overhead of managing separate tasks. We have automated this process with CI and I am yet to notice any slowdown that is impactful.

@addyosmani
Copy link
Member Author

@rowoot thanks for sharing your insights. I think we might just switch to using grunt-pandoc for now and review whether it introduces any bottlenecks further down the line. It'll definitely make it easier to introduce more export formats.

@michealbenedict
Copy link
Contributor

@addyosmani Happy to submit PR with the change. Is it fine?

@addyosmani
Copy link
Member Author

Absolutely! That would be awesome. Thank you :)

@KraigWalker
Copy link

Don't know if you've heard of Assemble.io - think of it as a Jekyll style system except made with Grunt and Node.js rather than Ruby and Rails. It's used for generating static sites, and could probably still work alongside other grunt plugins for cross media publishing.

@michealbenedict
Copy link
Contributor

@KraigWalker thanks for the heads up, I can look into it.

@dashed
Copy link

dashed commented Jan 5, 2014

Shameless plug, I have a grunt-pandoc plugin of my own: https://github.com/Dashed/grunt-pandoc

I think it's a little generalized config-wise. I probably made significant changes locally -- mostly to adhere to grunt plugin spec. Let me know if there's any interest.

EDIT: See #8 (comment)

@dashed
Copy link

dashed commented Jan 21, 2014

I moved on from grunt to gulp as a flexible and easier way to manage my pandoc based projects. My setup can be found at pandoc-seed-project. I largely recommend this over my project: https://github.com/Dashed/grunt-pandoc

@addyosmani
Copy link
Member Author

Thanks! We'll check it out.

On Tuesday, 21 January 2014 19:20:28, Alberto Leal notifications@github.com
wrote:

I moved on from grunt to gulp as a flexible and easier way to manage my
pandoc based projects. My setup can be found at pandoc-seed-projecthttps://github.com/Dashed/pandoc-seed-project.
I largely recommend this over my project:
https://github.com/Dashed/grunt-pandoc


Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-32952670
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants