Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate deno vendor and replace with "vendor": true? #20584

Closed
dsherret opened this issue Sep 20, 2023 · 11 comments · Fixed by #22183
Closed

Deprecate deno vendor and replace with "vendor": true? #20584

dsherret opened this issue Sep 20, 2023 · 11 comments · Fixed by #22183
Labels
breaking change a change or feature that breaks existing semantics suggestion suggestions for new features (yet to be agreed)
Milestone

Comments

@dsherret
Copy link
Member

dsherret commented Sep 20, 2023

Deno 1.37 (and actually some earlier versions) has the ability to vendor by specifying the following in a deno.json:

{
  "vendor": true
}

After running your program or caching (ex. deno cache mod.ts), a ./vendor folder will be automatically populated with the remote dependencies.

This is considerably easier to use than deno vendor and we should consider deprecating deno vendor in favour of this feature and move the existing deno vendor out into a separate tool.

@dsherret dsherret added suggestion suggestions for new features (yet to be agreed) breaking change a change or feature that breaks existing semantics labels Sep 20, 2023
@Leokuma
Copy link

Leokuma commented Oct 21, 2023

Wouldn't that make it mandatory to have a deno.json in order to be able to use that feature? Maybe a flag could be added to deno cache like deno cache --vendor or something. Quick vendoring is useful for debugging and patching deps, and some build routines and pipelines might not need a deno.json.

@dsherret
Copy link
Member Author

That flag exists today. Read more here: https://deno.com/blog/v1.37#vendor-as-cache-override-unstable

@Leokuma
Copy link

Leokuma commented Oct 21, 2023

Oops I missed that. Thanks!

@iuioiua
Copy link
Contributor

iuioiua commented Jan 29, 2024

What's the current stance on this?

@dsherret
Copy link
Member Author

To deprecate deno vendor in favour of "vendor": true and then move deno vendor out of the CLI to a separate library.

@sigmaSd

This comment was marked as off-topic.

@dsherret
Copy link
Member Author

@sigmaSd I think you're looking for --cached-only and not --no-remote? The --no-remote flag means "no remote specifiers are allowed". See #22186

@sigmaSd

This comment was marked as off-topic.

@lino-levan
Copy link
Contributor

Currently, the JSR doesn't support raw URL imports. The solution to this would either be rewriting the module to avoid them or to vendor the module. Unfortunately, we are unable to import from the vendor folder using vendor: true in the deno.json. deno vendor works just fine but if it gets deprecated it's unclear what next steps would be for module authors.

@bartlomieju
Copy link
Member

We'll deprecate deno vendor subcommand in 1.42 and move it to a JSR package.

@bartlomieju bartlomieju added this to the 1.42 milestone Mar 21, 2024
@dsherret dsherret modified the milestones: 1.42, 1.43 Mar 27, 2024
@bartlomieju bartlomieju modified the milestones: 1.43, 1.44 Apr 22, 2024
@iugo
Copy link
Contributor

iugo commented Jul 5, 2024

Currently, the JSR doesn't support raw URL imports. The solution to this would either be rewriting the module to avoid them or to vendor the module. Unfortunately, we are unable to import from the vendor folder using vendor: true in the deno.json. deno vendor works just fine but if it gets deprecated it's unclear what next steps would be for module authors.

Currently, deno cache can put jsr packages under vendor/. deno v1.44.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change a change or feature that breaks existing semantics suggestion suggestions for new features (yet to be agreed)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants