You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on implementing a deployment/upgrade workflow as a plugin.
Workspaces are wonderful for development, but in some cases, it is still necessary to distribute individual packages. Also, many use cases don't have internet access so can't fetch packages npm repositories on the production servers (ie. like fetching upgrades).
The "Zero-Install" feature is great for the initial deployment, but currently doesn't have a way to upgrade individual packages in the future.
The goal of this plugin is to provide a deploy package command (as a plugin) which will:
run user defined pre-deploy script (testing, etc.)
use yarn version to bump the version of the deploy package and all its dependencies which have beet updated since last deployment (based on git tags)
run pack on the package named in the deploy command and all its dependencies (so now you have all packages properly packaged)
extract that package (the package named in the deploy command) to a folder
run yarn install in that folder to install all dependencies and create a zero-install .pnp.js file
optionally tar and compress the folder before distribution
run user defined post-deploy script (to allow further deployment like rsync to production server, etc.)
This method allows both distributing the entire project initially as zero-install and also upgrading individual packages in the future.
Because many times deployments are within firewalled private networks, it is also import to be able to upgrade from the package files directly instead of fetching them from a repo. This should be completely transparent to the actual project (ie. should not require changing any dependency in the project.json file). So this plugin also aims to provide resolver/fetcher plugins that can "intercept" requests to package repositories and redirect them to a local cache.
To accommodate the requirements for the resolver/fetcher plugins, a proposal to modify plugin architecture has been submitted as issue #845 which allows plugins to be chained and run sequentially. This allows checking a local cache before querying an npm repo, and may also have some interesting applications regarding redundancy and fallback schemes.
The text was updated successfully, but these errors were encountered:
I am working on implementing a deployment/upgrade workflow as a plugin.
Workspaces are wonderful for development, but in some cases, it is still necessary to distribute individual packages. Also, many use cases don't have internet access so can't fetch packages npm repositories on the production servers (ie. like fetching upgrades).
The "Zero-Install" feature is great for the initial deployment, but currently doesn't have a way to upgrade individual packages in the future.
The goal of this plugin is to provide a
deploy package
command (as a plugin) which will:yarn version
to bump the version of the deploy package and all its dependencies which have beet updated since last deployment (based on git tags)pack
on the package named in the deploy command and all its dependencies (so now you have all packages properly packaged)yarn install
in that folder to install all dependencies and create a zero-install .pnp.js fileThis method allows both distributing the entire project initially as zero-install and also upgrading individual packages in the future.
Because many times deployments are within firewalled private networks, it is also import to be able to upgrade from the package files directly instead of fetching them from a repo. This should be completely transparent to the actual project (ie. should not require changing any dependency in the project.json file). So this plugin also aims to provide resolver/fetcher plugins that can "intercept" requests to package repositories and redirect them to a local cache.
To accommodate the requirements for the resolver/fetcher plugins, a proposal to modify plugin architecture has been submitted as issue #845 which allows plugins to be chained and run sequentially. This allows checking a local cache before querying an npm repo, and may also have some interesting applications regarding redundancy and fallback schemes.
The text was updated successfully, but these errors were encountered: