Plop 4 Planning

[crutchcorn]

• Drop Node 12, 14, 16 support due to EOL
• Update dependencies
  • Rewrite to new Inquirer packages (Rewrite to use new Inquirer Packages #382)
• Remove promisify dependency
• Support TS usage OOTB (Support TypeScript usage without compile step #297)

[moltar]

Would a full TS rewrite be on the table? ;)

I think with the help of AI this should be relatively not so painful.

[crutchcorn]

I don't think a TS rewrite is something we really want to introduce TBH. We've had this discussion a lot in the past and just don't see the wins for Plop in particular, especially because it would require us to add a build step which is a bit of a headache for bin packages like Plop.

[moltar]

don't see the wins

I think it's just a much better DX, tbh.

Can unlock other developers to help out.

I'm generally not happy contributing to JS projects 😁 Haven't been writing raw JS in years.

Plop in particular

I think plop package can be modularized even further. Existing code could be split up between node-plop and plop-cli.

And at this point, plop package itself could remain pure JS, which would literally just do a require of the plop-cli as the entrypoint and contain no logic.

add a build step which is a bit of a headache for bin packages like Plop.

Doing this with tsup is extremely easy and causes no pain.

---

I feel like I am going offtopic here with the theme of this issue. Let me know if you want to continue in another issue. But if this is a hard no go, then we can just hide this comment as "offtopic".

[crutchcorn]

I've decided not to migrate to the new inquirer packages for Plop 4

Here's why:

1. The API doesn't seem conducive to the all-in-one Plop philosophy that we're aiming for
2. There's still a large ecosystem of inquirer packages that many/most Plop packages rely on
3. The install size is not large enough to change the ecosystem yet

vs

[crutchcorn]

As for the suggestion to rewrite in TypeScript @moltar:

I think it's just a much better DX, tbh.

Sure, it is; but let's consider the level of effort in doing so. Not only would we have to tackle packaging (more on that soon), but we'd have to migrate our tests and all of our code to get the most for our buck in DX:

That includes 5453 lines of JavaScript. Compare the level of effort in maintaining TypeScript typings (~400 LOC) and updating dependencies. I managed to cut a v4 release in ~1 hour with our existing code, and have reasonable confidence it will work as-intended because we not only have extensive integration tests on node-plop but E2E tests on plop.

I think plop package can be modularized even further. Existing code could be split up between node-plop and plop-cli.

Sure, it could be split up more, but truthfully it goes a bit against the spirit of Plop. This codebase reflects the API of Plop: Straightforward without too much concern for treeshaking or overengineering.

In this spirit, we even dropped support for treeskaing Plop despite @evelynhathaway getting it working in #217 working. While reducing bundle size by ~40MB would've been great, the specifics of getting it working required not only a build step but:

• Drastically complex WebPack plugins
• Potential instability by hacking around require behavior
• Drastically more complex upgrade potential (especially with ESM changing this code from require would've been something of a nightmare)

My concern is that, while TypeScript is awesome - it's not a zero-sum game. Especially since TypeScript doesn't use SemVer properly, I've experienced various applications where typings are hard to maintain due to breaking changes between minor versions. We've even experienced this with Plop ala: #373

Doing this with tsup is extremely easy and causes no pain.

This is gonna have to be an agree to disagree here. I've ran into a lot of issues even with TSUp. While it's a huge improvement in many ways, we'll still have to introduce a more complex CI/CD step which has a huge headache as well.

We've been experiencing this in a different project I maintain:

https://github.com/tanstack/form
https://github.com/tanstack/store

Which led to repeatedly broken releases of store for a little while during CI fixes.

This all isn't to say that it'd be impossible to migrate Plop to TypeScript, but more that I'm unclear what benefits it brings us, especially compared to the complexity

[crutchcorn]

Closing, as Plop 4.0 is released!

https://github.com/plopjs/plop/releases/tag/plop%404.0.0