auto-detect package manager in the plugin manager

[KonnorRogers]

This is a 🙋 feature or enhancement.

Summary

Auto-detect how to install dependencies of plugins to improve the story of using any package manager

Context

Related to #609

This doesn't fix it. But this allows you to opt-out of yarn and use whatever package manager you want. We could also just bail if we can't find a yarn.lock or maybe check an ENV var like NO_YARN_INSTALL or something?

[render]

Your Render PR Server URL is https://bridgetown-beta-pr-821.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-ckuv02booi7s739u7i50.

[render]

Your Render PR Server URL is https://bridgetown-api-pr-821.onrender.com.

Follow its progress at https://dashboard.render.com/static/srv-ckuv02jooi7s739u7ib0.

[sandstrom]

Just to chime in, my suggestion would be that Bridgetown should be less concerned about the JS ecosystem and package managers.

Instead, it should provide generic primitives (hooks, etc) that any package manager can use.

I've explained my thinking in these two posts:

• feat: allow package manager selection upon install  #609 (comment)
• feat: allow package manager selection upon install  #609 (comment)

[jaredcwhite]

@sandstrom Yeah I think we could easily extract all this stuff out to a more third-party-configurable module of some sort rather than buried in a core class.

[jaredcwhite]

I want to get this merged in the meantime though. I think @KonnorRogers we just need the linting fixed and then we're good to go!

[sandstrom]

I want to get this merged in the meantime though.

I understand, sounds good!

Yeah I think we could easily extract all this stuff out to a more third-party-configurable module of some sort rather than buried in a core class.

The whole ecosystem for JS/node moves fast, and trying to keep up is impossible.

Apart from the comments cited above, Middleman is another good example.

https://middlemanapp.com/advanced/external-pipeline/#webpack-example

They have the concept of an 'external pipeline' and try not to worry too much about JS/CSS/etc.

Bridgetown can still provide some helpful documentation on how to set it up, and even have the 'start new project' CLI tool generate some boilerplate code that set things up with webpack or esbuild.

But I think the framework should avoid trying to write a wrapper API around all the potential functionality that may go into an asset pipeline, and instead leave it to node-land tools.

[KonnorRogers]

@jaredcwhite fixed

[jaredcwhite]

@KonnorRogers Fantastic! I hope to cut another point release soon, so this will be a welcome improvement.

@sandstrom I think that's generally our position, but it's also easier to maintain tooling over time that's part of the framework's "runtime" than something that's part of a starter kit or whatever. That's why we don't simply generate a single esbuild config file and then wipe our hands forevermore, but instead the main portion of the config is part of a file "owned" by the framework that can get auto-updated. As someone who starts and operates dozens of Bridgetown sites, I take comfort knowing the esbuild config can always be easily brought up-to-date across all of them.