A way to mark certain dependencies as client-side

[LeaVerou]

As discussed in this Slack thread:

There is already ample precedent on marking dependencies differently based on the context they are needed in, with devDependencies being the most popular (but there is also optionalDependencies, peerDependencies, peerDependenciesMeta, bundledDependencies, bundleDependencies, etc, though I’m not sure what's their standardization status. However, we have nothing to distinguish server runtime deps from client runtime deps.

Why does this matter?

• Because often hosts will not deploy node_modules at all (e.g. Netlify and Vercel both do this).
• Because in the absence of it, tooling (e.g. Next.js) assumes that every dependency is a client-side dependency, and will attempt to bundle them.

Yes, most people these days use bundlers, but many do so begrudgingly, because the alternative is simply not viable. Something like this is a step towards not needing third-party tools for basic dependency management. Browsers support ESM naturally. Import maps allow mapping specifiers to URLs (with clunky ergonomics today, but hopefully this will be fixed). The last piece of the puzzle is knowing which dependencies to deploy, which is currently impossible. Import maps could even be generated automatically from this subtree.

I’m not sure what the right syntax would be. The path of least resistance seems to be a separate clientDependencies field, modeled after devDependencies. But it seems there is a combinatorial explosion of dependency categories (e.g. @ljharb wants optionalDevDependencies) which begs the question whether the right data structure is different, one where dependencies are declared once and assigned metadata:

{
	"dependencies": {
		"foo": "^17.2.1",
		"bar": {
			"version": "^1.0.1",
			"devOnly": true,
			"client": true
		}
}

Some things to note:

• This should not be a per-project setting, but a per-package setting. Many (most?) projects run server-side code, built-time code, AND client-side code.
• A package being used client-side is not mutually exclusive with other uses. For a trivial example: utility libraries (e.g. lodash) may be used across server, client, AND build tools. This is not even particularly complex. Suppose you have a serverless function to access an API, a build process, and UI components, you now have all three. And that's a pretty basic web app.
• This should be decided by the package consumer, not the package author. Perhaps client-side dependencies that are not also dependencies should not even be installed when installing a package. Again devDependencies is good precedent here.

[styfle]

Because often hosts will not deploy node_modules at all (e.g. Netlify and Vercel both do this).

Vercel deploys node_modules. What makes you think it doesn't?

The last piece of the puzzle is knowing which dependencies to deploy, which is currently impossible.

Its not impossible. There are tools such as https://github.com/vercel/nft which is what Vercel uses.

[ljharb]

What does "clientside" mean, exactly? jsdom runs in node. There's very little code that actually can only ever run in the browser, or on a server.

People often ask for a way, like the now-deprecated preferGlobal, indicate that their package is a dev dependency. However, NO dev dep is always a dev dep - anything that works with it might have it as a runtime dep or a peer dep. In other words, "client" isn't something that a package can ever declare correctly, only an application - the top-level/end consumer - can. Having a deps category that is app-only (and not allowed/respected in published packages) might be a solution, but it'd be a weird and unprecedented one.

[LeaVerou]

Because often hosts will not deploy node_modules at all (e.g. Netlify and Vercel both do this).

Vercel deploys node_modules. What makes you think it doesn't?

We may be using "deploys" differently. You can go to myurl/node_modules/some_module/dist/some_file.js and have it resolve?

However, NO dev dep is always a dev dep - anything that works with it might have it as a runtime dep or a peer dep. In other words, "client" isn't something that a package can ever declare correctly, only an application - the top-level/end consumer - can. Having a deps category that is app-only (and not allowed/respected in published packages) might be a solution, but it'd be a weird and unprecedented one.

Yes? Again, devDependencies is a good precedent here, and that's exactly how it works (so not unprecedented at all).

[styfle]

You can go to myurl/node_modules/some_module/dist/some_file.js and have it resolve?

Ah I see what you mean. You would need to move those files into the public directory. Thats a safety mechanism since source files are considered private, so you have to be explicit which files are public.

For the backend using an import will automatically bundle appropriate node_modules.