Tracking: stabilization of "patch" feature

[dsherret]

// deno.json
{
  "patch": [
    "../some-package-or-workspace"
  ]
}

#25068

Questions:

• Is "patch" an ok name? Isn't it confusing with the idea of "patching a package" where you modify a package in the vendor or node_modules directory? What better alternatives are there?
  • Rename "patch" option in "deno.json" to "links" #29468
• Can this work with git repositories? How does that work?
• What about patching to a remote specifier?

To implement:

• Patching npm packages.
• Improving error messages to recommend using the patch feature (Local Module Imports & Invalid Relative Path Errors #26704)

[lucacasonato]

I think patch is a reasonable name.

[Hajime-san]

Hi, I created a minimal example for the current patch feature.
If you find any mistakes, please let me know.

• https://github.com/Hajime-san/example_deno_unstable_patch

[birkskyum]

does this do something similar to pnpm patch https://pnpm.io/cli/patch? because then patch is a great name.

[ohroy]

whats the right way to do in deno like pnpm patch? I need patch the npm package...

[yacinehmito]

Is "patch" an ok name? Isn't it confusing with the idea of "patching a package" where you modify a package in the vendor or node_modules directory? What better alternatives are there?

I don't link the "patch" name. This is confusing in exactly the way you wrote @dsherret.

The precedent set by pnpm patch and yarn patch is indeed that it allows importing from a local copy, but the ultimate purpose is to produce a patch file for the changes, which are then automatically applied on install.

The history is that:

• Originally, patch-package with npm was used to capture manual changes from node_modules into a patch file so that it could be reproduced on install
• Because pnpm was filling the node_modules with symlinks to a global cache, this workflow was not possible anymore. This forced the introduction of pnpm patch in order to copy the dependency in a place where local changes could be done without touching the global cache.
• For similar reasons, yarn picked the same solution. In this instance though, it was because of plug-n-play, not symlinks.

Having a "patch" feature in Deno that never leads to an actual patch but is only used to have a local copy of a dependency is confusing. The name only conjures the right meaning if one is aware of the precedent of pnpm and yarn.

[yacinehmito]

Ultimately, having an actual patch feature would be really useful. I actually found this issue because I was looking for one. We sometimes need to do small fixes of dependencies, but don't necessarily want to vendor or fork it. Use cases are typically not-yet-released bug/security fixes or types adjustments.

[dsherret]

See here for naming:

• Rename "patch" option in "deno.json" to "links" #29468

[temeddix]

It would be really nice if patch supports packages that aren't published on NPM or JSR, like dependency's path in Rust Cargo. Sometimes you need to clone the private package on the local machine and import it, where Deno workspace doesn't make sense.

[marvinhagemeister]

It would be really nice if patch supports packages that aren't published on NPM or JSR, like dependency's path in Rust Cargo. Sometimes you need to clone the private package on the local machine and import it, where Deno workspace doesn't make sense.

@temeddix Good news! What you're describing is already possible and is exactly how the patch functionality in Deno works. The package doesn't have to be published at all. It just needs to have the proper package metadata in deno.json or package.json respectively, so that Deno knows what package it's dealing with.

[temeddix]

Test Result

@marvinhagemeister Thank you very much for the fast reply :) I couldn't find this information about patch anywhere in the docs, so I was confused:

• https://docs.deno.com/runtime/fundamentals/configuration/

Now I can confirm that using patch in deno.json allows us to import another local package with deno.json in it. deno check works just fine.

my_project/
  my_lib/
    src/
      index.ts
      another.ts
      ...
    deno.json // has `@scope/my_lib` as `name`
  my_web_app/
    src/
      index.ts
      ...
    deno.json // has `../my_lib` in the `patch` field
    vite.config.ts

New Problem

However, there seems to be a problem when building the web app with Vite; There's an error saying:

[plugin:vite:import-analysis] Failed to resolve import "./another.ts" from "deno::TypeScript::@scope/my_lib::C:/Users/myname/Documents/GitHub/my_project/my_lib/src/index.ts". Does the file exist?

And this is my full vite.config.ts (in my_web_app directory), properly using @deno/vite-plugin:

import { defineConfig, type HmrOptions } from "vite";
import react, { type Options as ReactOptions } from "@vitejs/plugin-react";
import deno from "@deno/vite-plugin";
import tailwindcss from "@tailwindcss/vite";

const HOST = Deno.env.get("TAURI_DEV_HOST");
const REACT_OPTIONS: ReactOptions = { babel: { compact: true } };

// https://vitejs.dev/config/
// These Vite options are tailored for Tauri development
// and only applied in `tauri dev` or `tauri build`.
export default defineConfig({
  plugins: [deno(), react(REACT_OPTIONS), tailwindcss()],
  // Prevent Vite from obscuring Rust errors.
  clearScreen: false,
  // Tauri expects a fixed port, fail if that port is not available.
  server: {
    port: 1420,
    strictPort: true,
    host: HOST || false,
    hmr: HOST ? createHmrOptions(HOST) : undefined,
    watch: {
      // Tell Vite to ignore Rust crates.
      ignored: ["**/src-tauri/**"],
    },
  },
  resolve: {
    extensions: [".ts", ".js"],
  },
});

function createHmrOptions(host: string): HmrOptions {
  return {
    protocol: "ws",
    host,
    port: 1421,
  };
}

Is this an issue with vite-plugin?