gem-hunter
主要言語: JavaScript
Synchronously resolve plugins / transforms / presets just like Babel and Browserify does it, using CommonJS `require` builtin. For example, useful for loading complex configs from `package.json` file.
Synchronously resolve plugins / transforms / presets just like Babel and Browserify does it, using CommonJS
requirebuiltin. For example, useful for loading complex configs frompackage.jsonfile.
You might also be interested in always-done.
Install with npm
$ npm install resolve-plugins-sync --save
or install using yarn
$ yarn add resolve-plugins-sync
For more use-cases see the tests
const resolvePluginsSync = require('resolve-plugins-sync') // fake const baz = require('tool-plugin-baz') const qux = require('tool-plugin-qux') const result = resolvePluginsSync([ 'foo', ['bar', { some: 'options here' }], [baz, { a: 'b' }], qux ], { prefix: 'tool-plugin-' })
Because we need. Because many famous tools do exact same thing. They use same kind
of resolution of their presets, plugins, transforms and whatever you wanna call it.
This one is pretty configurable and small. Most of this resolution can be seen in the
users package.jsons configs.
For example browserify.transform field in package.json
{
"browserify": {
"transform": [
"babel",
["uglifyify", {
"compress": true
}]
]
}
}And because both babel and browserify uses same resolution things may gone more wild.
Let's take this example
{
"browserify": {
"transform": [
["babel", {
"presets": [
["es2015", {
"modules": false
}]
],
"plugins": [
["react", { "some": "more options" }]
"add-module-exports"
]
}],
["uglifyify", {
"compress": true
}]
]
}
}And so on, and so on... infinite nesting. That's just freaking crazy, right?
That's all about what this package does - you give it an array and it does such thing - in case with Browserify if they use this package they should pass browserify.transform as first argument.
It's so customizable that it match to all their needs - both for Babel plugins/presets/transforms and Browserify transforms. The browserify transforms are a bit different by all others. They accept filename, options signature. And so, because they don't accept options as first argument, like Babel's transforms or like Rollup's plugins, we need a bit configuration to make things work for Browserify.
That's why this package has opts object through which you can pass opts.first to set first argument for the plugin/transform function. Another thing that you can do is to pass opts.args if you want more control over the passed arguments to the plugin/transform function.
How we resolve plugins? Resolving algorithm has 4 steps. You should know that in the following paragraphs item means each element in the passed array to resolvePluginsSync().
1) If item is string, it tries to require it from
locally installed dependencies, calls it and you can pass
a opts.prefix which will be prepended to the item string.
Think for it like rollup-plugin-, babel-plugin-, gulp-
and etc. You may want to see the comments for resolveFromString inside the source code.
2) If item is function, it will call it and if you
want to pass arguments to it you can pass opts.args array
or opts.first. If opts.args is passed it calls that
item function with .apply. If opts.first is passed
it will pass it as first argument to that function.
3) If item is object, nothing happens, it just returns it
in the result array.
4) If item is array, then there are few possible
scenarios (see comments for resolveFromArray inside the source code):
Babel/Browserify-style resolve of a
pluginsarray and optionaloptsoptions object, where each "plugin" (item in the array) can be
Params
array {Array|String}: of "plugins/transforms/presets" or single string, which is arrayified so returned result is always an arrayopts {Object}: optional custom configurationopts.prefix {String}: useful like babel-plugin- or rollup-plugin-opts.context {Any}: custom context to be passed to plugin function, using the .apply methodopts.first {Any}: pass first argument for plugin function, if it is given, then it will pass plugin options as 2nd argument, that's useful for browserify-like transforms where first argument is filename, second is transform optionsopts.args {Array}: pass custom arguments to the resolved plugin function, if given - respected more than opts.firstreturns {Array}: result resolved plugins, always an arrayExample
const resolve = require('resolve-plugins-sync') // fake const baz = require('tool-plugin-baz') const qux = require('tool-plugin-qux') resolve([ 'foo', ['bar', { some: 'options here' }], [baz, { a: 'b' }], qux ], { prefix: 'tool-plugin-' })
Pull requests and stars are always welcome. For bugs and feature requests, please create an issue.
Please read the contributing guidelines for advice on opening issues, pull requests, and coding standards.
If you need some help and can spent some cash, feel free to contact me at CodeMentor.io too.
In short: If you want to contribute to that project, please follow these things
npm run commit to commit changes instead of git commit, because it is interactive and user-friendly. It uses commitizen behind the scenes, which follows Conventional Changelog idealogy.npm run release, which is standard-version and follows Conventional Changelog idealogy.Thanks a lot! :)
Documentation and that readme is generated using verb-generate-readme, which is a verb generator, so you need to install both of them and then run verb command like that
$ npm install verbose/verb#dev verb-generate-readme --global && verb
Please don't edit the README directly. Any changes to the readme must be made in .verb.md.
Clone repository and run the following in that cloned directory
$ npm install && npm test
Charlike Mike Reagent
Copyright © 2016-2017, Charlike Mike Reagent. MIT
This file was generated by verb-generate-readme, v0.6.0, on October 10, 2017.
Project scaffolded using charlike cli.