4 ms·

Because scaffolding by itself is an anti-pattern and you shouldn’t do it. The proper way to factor code is libraries/packages, not automated copy pasta.

wruza 4y ago
I tried many times to do what you suggest, and every time it was even harder than the original issue. Maintaining separate packages is tedious (don't forget to commit/push/republish/upgrade after testing) and error-prone version/feature/branch-wise if you can't stop and pay full attention to it every time you change or need it. Not worth it in my book.
sholladay 4y ago
Perhaps, if you’re just creating a new application every couple of years. For library authors like myself, a scaffolding tool is exactly what I need to quickly make the ecosystem of small, reusable libraries that you speak of. Do you expect Sindre Sorhus to manually copy the MIT license to each new project? What about the CI config? The .gitignore? Okay, you might say, Sindre is an exceptional case. But on any new project, you might forget to include the correct set of files or screw up how they are set up by not filling in or updating a copyright notice, project version number, repo link, etc. Sure, you can cut down on the number of files you start your projects with and the fill-in-the-blank values they might need, but that only gets you so far and it reduces the initial usability of your project. A scaffolding tool helps maintain consistently high quality across projects. For example, my Yeoman generator automatically fetches the latest version of my favorite CLI helpers and testing framework and other dependencies, so I never accidentally start a project with an outdated, potentially insecure codebase. https://github.com/sholladay/generator-seth https://github.com/sholladay/generator-seth Not everyone needs something this fancy! Another commenter mentioned editor snippets, which is probably what I would use if I couldn’t have Yeoman. But when you make new projects on a regular basis, scaffolding is 100% the way to go.
- partdavid 4y ago
  Like I implied in my reply to GP, this is to cover for deficiencies in the language, tools and environments. If you can't incorporate this common logic by reference, then it's a deficiency of the tool(s). There's no first principles reason why you can't name a common config for ignoring git files, and incorporate it by reference--either git does not have this affordance or you haven't found it. There's no reason you can't apply principles of software reuse to CI configs for similar pipelines: Screwdriver does it, for example. If other CI tools don't, that's a deficiency. Licenses, frankly, are the same; they need to be incorporated as text in releases and distributions, but they could exist as references in whatever you consider your "original source" (and often actually do).[1] Of course, you don't always get to choose or modify everything about your environment, like how git works, how your CI is configured, etc. But it's not a bad thing to admit that scaffolding is at best a papering-over of deficiencies in these tools, and not a desirable thing in itself. I'm not familiar with Yeoman, but like other necessary but dirty things we do, we should at least try to encapsulate it and do some implementation hiding. You wouldn't generate language bindings from protobuf and then manually modify them--and the same kind of discipline should hold for these scaffoldings. You should be able to repeatedly regenerate all their artifacts (even if they get checked in) with confidence--and once you've done that, you have effectively removed the "scaffolding" and replaced it with a build tool. ---- [1] As a bit of a tangent, there's an even worse sin lurking here, which is that you have the same fact but need to capture it twice (or more) in different places: in package metadata, however you do that in your language; possibly in project metadata (if however you host your project doesn't discover it); and in the text of the license that must be distributed. If you don't rely on a single source of truth for this, you're asking not just for an ergonomic problem with updating your scaffolding, but an actual, material inconsistency, like when the COPYING file contains a different version of a license than the one that's referred to in your .gemspec. I point this out as a conceptual detail, not because I think it's an actual frequent problem.
  - yellowapple 4y ago
    > you can't incorporate this common logic by reference, then it's a deficiency of the tool(s). If that's the case, then I know of zero languages/ecosystems with tools that are not deficient in this manner.
partdavid 4y ago
I agree with you entirely, but I have to do so admitting the reality that not every environment or language is so capable. Don't get me wrong, I still think it sucks, because it breaks robust mechanisms of reuse and updating dependencies in favor of very fragile ones. I'm fighting the fight right now to at least capture these dependencies in the form of tooling rather than scaffolding. But when the language is inflexible and really demands deduplication rather than boilerplate, it becomes really difficult to make the case.

wruza 4y ago

I tried many times to do what you suggest, and every time it was even harder than the original issue. Maintaining separate packages is tedious (don't forget to commit/push/republish/upgrade after testing) and error-prone version/feature/branch-wise if you can't stop and pay full attention to it every time you change or need it. Not worth it in my book.

sholladay 4y ago

Perhaps, if you’re just creating a new application every couple of years. For library authors like myself, a scaffolding tool is exactly what I need to quickly make the ecosystem of small, reusable libraries that you speak of. Do you expect Sindre Sorhus to manually copy the MIT license to each new project? What about the CI config? The .gitignore? Okay, you might say, Sindre is an exceptional case. But on any new project, you might forget to include the correct set of files or screw up how they are set up by not filling in or updating a copyright notice, project version number, repo link, etc. Sure, you can cut down on the number of files you start your projects with and the fill-in-the-blank values they might need, but that only gets you so far and it reduces the initial usability of your project. A scaffolding tool helps maintain consistently high quality across projects. For example, my Yeoman generator automatically fetches the latest version of my favorite CLI helpers and testing framework and other dependencies, so I never accidentally start a project with an outdated, potentially insecure codebase. https://github.com/sholladay/generator-seth https://github.com/sholladay/generator-seth Not everyone needs something this fancy! Another commenter mentioned editor snippets, which is probably what I would use if I couldn’t have Yeoman. But when you make new projects on a regular basis, scaffolding is 100% the way to go.

partdavid 4y ago
Like I implied in my reply to GP, this is to cover for deficiencies in the language, tools and environments. If you can't incorporate this common logic by reference, then it's a deficiency of the tool(s). There's no first principles reason why you can't name a common config for ignoring git files, and incorporate it by reference--either git does not have this affordance or you haven't found it. There's no reason you can't apply principles of software reuse to CI configs for similar pipelines: Screwdriver does it, for example. If other CI tools don't, that's a deficiency. Licenses, frankly, are the same; they need to be incorporated as text in releases and distributions, but they could exist as references in whatever you consider your "original source" (and often actually do).[1] Of course, you don't always get to choose or modify everything about your environment, like how git works, how your CI is configured, etc. But it's not a bad thing to admit that scaffolding is at best a papering-over of deficiencies in these tools, and not a desirable thing in itself. I'm not familiar with Yeoman, but like other necessary but dirty things we do, we should at least try to encapsulate it and do some implementation hiding. You wouldn't generate language bindings from protobuf and then manually modify them--and the same kind of discipline should hold for these scaffoldings. You should be able to repeatedly regenerate all their artifacts (even if they get checked in) with confidence--and once you've done that, you have effectively removed the "scaffolding" and replaced it with a build tool. ---- [1] As a bit of a tangent, there's an even worse sin lurking here, which is that you have the same fact but need to capture it twice (or more) in different places: in package metadata, however you do that in your language; possibly in project metadata (if however you host your project doesn't discover it); and in the text of the license that must be distributed. If you don't rely on a single source of truth for this, you're asking not just for an ergonomic problem with updating your scaffolding, but an actual, material inconsistency, like when the COPYING file contains a different version of a license than the one that's referred to in your .gemspec. I point this out as a conceptual detail, not because I think it's an actual frequent problem.
- yellowapple 4y ago
  > you can't incorporate this common logic by reference, then it's a deficiency of the tool(s). If that's the case, then I know of zero languages/ecosystems with tools that are not deficient in this manner.

partdavid 4y ago

I agree with you entirely, but I have to do so admitting the reality that not every environment or language is so capable. Don't get me wrong, I still think it sucks, because it breaks robust mechanisms of reuse and updating dependencies in favor of very fragile ones. I'm fighting the fight right now to at least capture these dependencies in the form of tooling rather than scaffolding. But when the language is inflexible and really demands deduplication rather than boilerplate, it becomes really difficult to make the case.