Giter Club home page Giter Club logo

Comments (6)

AaronO avatar AaronO commented on May 21, 2024

All files listed in either .gitignore or .ignore will be ignored.

We could also add .bookignore to that list. That would specifically be for GitBooks. What do you think ?

from gitbook.

TheThirdOne avatar TheThirdOne commented on May 21, 2024

I think .bookignore should be added simply to have a GitBook specific file, but I also think a command line option for ignoring certain files would be helpful if that isn't too hard to implement.

from gitbook.

AaronO avatar AaronO commented on May 21, 2024

I don't want to make the command line tool too cumbersome to use.

In my opinion a good convention is far superior to configuration.

I would rather have people use a .bookignore than remember that they have to add --ignore=folder1/,some_other_file etc ... (I also think that the later is uglier and more error prone, thus less desirable).

Do you have a strong and unique use case where a command line flag that would be better that a .bookignore file ?

from gitbook.

AaronO avatar AaronO commented on May 21, 2024

Basically all GitBooks should have the same build commands. With a good convention it's easier for new comers to pick up a new book, since they're already familiar with GtiBooks conventions and standards and don't need to learn the project's specific standards.

We need to do a good job at keeping and enforcing these conventions, because that's what makes GitBook "beautiful" and "elegant" ;)

P.S: I just wanted to help you understand where I'm coming from on this matter.

from gitbook.

TheThirdOne avatar TheThirdOne commented on May 21, 2024

I definitely see where you are coming from, and agree a .bookignore should be the preferred method for projects, but the dependency of a file shouldn't be a requirement. I don't see the point in restricting the command line interface for the purpose of simply maintaining good convention.

from gitbook.

AaronO avatar AaronO commented on May 21, 2024

The command line isn't restricted.

In this specific case, I believe that in most scenarios people would rather persist the ignore options than have to remember to include them at each build/serve/whatever ...

Not persisting those options, is also a bad practice. Because then collaborators can't contribute to your book without knowing the specific folders you ignore when running the gitbook command.

I can't think of a single compelling use case, where providing that info as a command line flag is superior (in terms of simplicity and general usefulness), that maintaining a .bookignore file.

Users are already used to .gitignore, .npmignore and others. So I think they would rather opt for the .bookignore option. And thus an --ignore flag would go underused on top of leaving the door open to bad practices.

I don't think we should add any features without a compelling use case behind them.

I'm sorry for being strict on this matter. But I really would like to avoid feature creep, and instead preserve strong conventions and best practices.

from gitbook.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.