Clean up autogen script
WasabiFan opened this issue · 1 comments
WasabiFan commented
The autogen script has grown to a difficult-to-maintain size as we have added new features and fixed hacky implementations. If we get a chance, I'd like to make the following changes:
- Separate the helper logic from the core code (separate file / module)
- Better-handle whitespace to maintain indentation of end tag
- Fix possible off-by-one error if the OS EOL marker isn't the one which is used in the file
- Use separate regexes for the language-specific bits and for the rest of an autogen line
- Move liquid extension methods into their own file
- Structure the recursive file management code so that it is clearer to understand
- Don't split by spaces to allow for more complex expressions in autogen definition
- Add command-line args for directories
- Investigate better options for acquiring custom liquid parser
- We use a custom version that allows for newlines in liquid tags. This modded version of the module isn't on npm (it's not particularly useful or different from the original), so the package.json file just points to a clone endpoint on GitHub. It clones then runs the scripts that build the CoffeScript for use. Obviously, having a better system that doesn't require recompilation every time you
npm install
autogen is preferred. - There also might be some relative-path hacks in the build scripts that will break when installing using npm v3.
- We use a custom version that allows for newlines in liquid tags. This modded version of the module isn't on npm (it's not particularly useful or different from the original), so the package.json file just points to a clone endpoint on GitHub. It clones then runs the scripts that build the CoffeScript for use. Obviously, having a better system that doesn't require recompilation every time you
- Generally clean up the code so that so many comments aren't needed to be able to understand it
rhempel commented
It's always fun to go back to code you wrote 6 months ago and not be able to figure out what it's doing, never mind how it's doing it. If you're writing idiomatic code, the how is often pretty clear - it's the big picture docs that get difficult to manage.
There's a magic zone between 100 and 1000 lines of code where it's hard to get the balance of docs right.