4 ms·

As mentioned elsewhere, you cannot reliably use a Makefile on Windows. A Makefile also is not aware of things like Node execution paths, the way `yarn exec` is.

As mentioned elsewhere, you cannot reliably use a Makefile on Windows. A Makefile also is not aware of things like Node execution paths, the way `yarn exec` is. You're then pushing more stuff down to the writer of the package.json file, who is more likely to make mistakes in retail then you as a platform designer are likely to make in wholesale. There are good reasons for things to converge the way they have. [EDIT: removed uncharitable reading]

verdverm 4y ago
I offered an alternative for the frustrated and did not make any such "just use X" claim Converge is a weird word to use, given the OP is about a project that creates divergence, now having to add support for other parts of the ecosystem
- eropple 4y ago
  Sorry. That was uncharitable of me. You did not make a "just use X" claim. But your suggestion does elide the significant difficulties in doing as you suggest. It's an alternative that will lead to more frustration due to the tons of design decisions wrapped up in package.scripts. And asserting that because you can do this, package.json "doesn't need this section tbh" is misleading and a recipe for further frustration for people who listen to your advice. And yes, Deno not literally being Node is in fact its problem. I've shipped stuff using Deno--and I don't hate it, and I did use Makefiles--but yeah, that's the actual problem here. Node conventions are the ones everyone expects and every tool expects, and Deno does not have a unique selling point to it that makes using it more reasonable than just using Node.
  - verdverm 4y ago
    yup, I've personally stopped worrying about Windows support since WSL-2. It makes things much simpler for most people / projects. The idea that dependencies can run any script at install time has always seemed problematic to me. Node seems to have many less than ideal design decisions that we are now stuck with

verdverm 4y ago

I offered an alternative for the frustrated and did not make any such "just use X" claim Converge is a weird word to use, given the OP is about a project that creates divergence, now having to add support for other parts of the ecosystem

eropple 4y ago
Sorry. That was uncharitable of me. You did not make a "just use X" claim. But your suggestion does elide the significant difficulties in doing as you suggest. It's an alternative that will lead to more frustration due to the tons of design decisions wrapped up in package.scripts. And asserting that because you can do this, package.json "doesn't need this section tbh" is misleading and a recipe for further frustration for people who listen to your advice. And yes, Deno not literally being Node is in fact its problem. I've shipped stuff using Deno--and I don't hate it, and I did use Makefiles--but yeah, that's the actual problem here. Node conventions are the ones everyone expects and every tool expects, and Deno does not have a unique selling point to it that makes using it more reasonable than just using Node.
- verdverm 4y ago
  yup, I've personally stopped worrying about Windows support since WSL-2. It makes things much simpler for most people / projects. The idea that dependencies can run any script at install time has always seemed problematic to me. Node seems to have many less than ideal design decisions that we are now stuck with