This feature is still incubating, and we'll likely be improving it based on your feedback.
This plugin will add support to Yarn for the exec: protocol. This protocol is special in that it'll instruct Yarn to execute the specified Node script and use its output as package content (thus treating the script as a kind of package factory).
Typical Yarn fetchers download packages from the internet - this works fine if the project you want to use got packaged beforehand, but fails short as soon as you need to bundle it yourself. Yarn's builtin mechanism allows you to run the prepare script on compatible git repositories and use the result as final package, but even that isn't always enough - you may need to clone a specific branch, go into a specific directory, run a specific build script ... all things that makes it hard for us to support every single use case.
The exec: protocol represents a way to define yourself how the specified package should be fetched. In a sense, it can be seen as a more high-level version of the Fetcher API that Yarn provides.
Documentation
The JavaScript file targeted by the exec: protocol will be invoked inside a temporary directory at fetch-time with a preconfigured runtime environment. The script is then expected to populate a special directory defined in the environment, and exit once the generation has finished.
Generator scripts & require
Because the generator will be called in a very special context (before any package has been installed on the disk), it won't be able to call the require function (not even with relative paths). Should you need very complex generators, just bundle them up beforehand in a single script using tools such as Webpack or Rollup.
Because of this restriction, and because generators will pretty much always need to use the Node builtin modules, those are made available in the global scope - in a very similar way to what the Node REPL already does. As a result, no need to manually require the fs module: it's available through the global fs variable!
Runtime environment
In order to let the script knows about the various predefined folders involved in the generation process, Yarn will inject a special execEnv global variable available to the script. This object's interface is defined as such:
Property
Type
Description
tempDir
string
The absolute path of the empty temporary directory. It is created before the script is invoked.
buildDir
string
The absolute path of the empty build directory that will be compressed into an archive and stored within the cache. It is created before the script is invoked.
locator
string
The stringified Locator identifying the generator package.
You're free to do whatever you want inside execEnv.tempDir but, at the end of the execution, Yarn will expect execEnv.buildDir to contain the files that can be compressed into an archive and stored within the cache.
@yarnpkg/plugin-exec
This plugin will add support to Yarn for the
exec:
protocol. This protocol is special in that it'll instruct Yarn to execute the specified Node script and use its output as package content (thus treating the script as a kind of package factory).Install
yarn plugin import exec
Usage
package.json
{ "dependencies": { "pkg": "exec:./gen-pkg.js" } }
gen-pkg.js
const {buildDir} = execEnv;
fs.writeFileSync(path.join(buildDir,
package.json
), JSON.stringify({ name:pkg
, version:<span class="hljs-number">1.0</span><span class="hljs-number">.0</span>
, }));fs.writeFileSync(path.join(buildDir,
<span class="hljs-keyword">index</span>.js
),module.exports = ${<span class="hljs-type">Date</span>.now()};\n
);Rationale
Typical Yarn fetchers download packages from the internet - this works fine if the project you want to use got packaged beforehand, but fails short as soon as you need to bundle it yourself. Yarn's builtin mechanism allows you to run the
prepare
script on compatible git repositories and use the result as final package, but even that isn't always enough - you may need to clone a specific branch, go into a specific directory, run a specific build script ... all things that makes it hard for us to support every single use case.The
exec:
protocol represents a way to define yourself how the specified package should be fetched. In a sense, it can be seen as a more high-level version of the Fetcher API that Yarn provides.Documentation
The JavaScript file targeted by the
exec:
protocol will be invoked inside a temporary directory at fetch-time with a preconfigured runtime environment. The script is then expected to populate a special directory defined in the environment, and exit once the generation has finished.Generator scripts &
require
Because the generator will be called in a very special context (before any package has been installed on the disk), it won't be able to call the
require
function (not even with relative paths). Should you need very complex generators, just bundle them up beforehand in a single script using tools such as Webpack or Rollup.Because of this restriction, and because generators will pretty much always need to use the Node builtin modules, those are made available in the global scope - in a very similar way to what the Node REPL already does. As a result, no need to manually require the
fs
module: it's available through the globalfs
variable!Runtime environment
In order to let the script knows about the various predefined folders involved in the generation process, Yarn will inject a special
execEnv
global variable available to the script. This object's interface is defined as such:tempDir
string
buildDir
string
locator
string
Locator
identifying the generator package.You're free to do whatever you want inside
execEnv.tempDir
but, at the end of the execution, Yarn will expectexecEnv.buildDir
to contain the files that can be compressed into an archive and stored within the cache.Example
Generate an hello world package:
fs.writeFileSync(path.join(execEnv.buildDir, 'package.json'), JSON.stringify({ name: 'hello-world', version: '1.0.0', }));
fs.writeFileSync(path.join(execEnv.buildDir, 'index.js'),
<span class="hljs-keyword">module</span>.exports = 'hello world!';
);Clone a monorepo and build a specific package:
const pathToRepo = path.join(execEnv.tempDir, 'repo'); const pathToArchive = path.join(execEnv.tempDir, 'archive.tgz'); const pathToSubpackage = path.join(pathToRepo, 'packages/foobar');
// Clone the repository child_process.execFileSync(
<span class="hljs-params">git</span>
, [<span class="hljs-params">clone</span>
,<span class="hljs-params">git</span>@<span class="hljs-params">github</span>.<span class="hljs-params">com</span>:<span class="hljs-params">foo</span><span class="hljs-operator">/</span><span class="hljs-params">bar</span>
, pathToRepo]);// Install the dependencies child_process.execFileSync(
<span class="hljs-params">yarn</span>
, [<span class="hljs-params">install</span>
], {cwd: pathToRepo});// Pack a specific workspace child_process.execFileSync(
<span class="hljs-params">yarn</span>
, [<span class="hljs-params">pack</span>
,--<span class="hljs-params">out</span>
, pathToArchive], {cwd: pathToSubpackage});// Send the package content into the build directory child_process.execFileSync(
<span class="hljs-params">tar</span>
, [-<span class="hljs-params">x</span>
,-<span class="hljs-params">z</span>
,--<span class="hljs-params">strip</span>-<span class="hljs-params">components</span>=1
,-<span class="hljs-params">f</span>
, pathToArchive,-C
, execEnv.buildDir]);