faucet-pipeline / faucet-pipeline-core

A framework-independent asset pipeline that takes the pain out of preprocessing JavaScript, CSS and associated files

faucet-pipeline-core

See faucet-pipeline.org for documentation.

License

faucet-pipeline is licensed under the Apache 2.0 License.

Contributing

• ensure Node is installed
• npm install downloads dependencies
• npm test runs the test suite and checks code for stylistic consistency

Releases

NB: version numbers are incremented in accordance with semantic versioning

1. update version number in package.json

2. update CHANGELOG.md

3. commit as "v#.#.#"

    $ git commit -m "v`node -p -e 'require("./package.json").version'`"
   

4. ./release publishes the new version

faucet-pipeline-core's Issues

realpath for testing

@mkhl noticed that various plugins use corutils' realpath, which is not available by default on macOS and various Linux distributions (cf. .travis.yml)

unfortunately, realpath adds another 46 packages (>1 MB) as dependencies, which seems silly:

let realpath = require("fs.realpath");

let filepath = sys.argv[2];
filepath = path.resolve(filepath);
filepath = realpath.realpathSync(filepath);
console.log(filepath);

thus we might want to offer a simplistic realpath implementation of our own - not quite sure how to do that safely though

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

• engines was only updated if it defined a single version, not a range.
• .nvmrc was updated to Node.js 10
• .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

An in-range update of browserslist is breaking the build 🚨

Version 4.0.1 of browserslist was just published.

Branch	Build failing 🚨
Dependency	browserslist
Current Version	4.0.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

browserslist is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Config File Details

configure (learn more about this file):

I would expect to get some details about the path and the name of the config file

Replace live-server with five-server?

I noticed that aiur replaces live-server with five-server: faucet-pipeline/aiur@b646258

An in-range update of browserslist is breaking the build 🚨

The dependency browserslist was updated from 4.6.4 to 4.6.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

browserslist is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

An in-range update of eslint-config-fnd is breaking the build 🚨

The devDependency eslint-config-fnd was updated from 1.7.0 to 1.8.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-config-fnd is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Missing manifest file on first run

When using the following config faucet throws

$ faucet --no-fingerprint --watch
monitoring file system at /Users/rglaser/workspace/innoq/innoq.com-cms/app/assets
Generated an empty bundle
{ Error: ENOENT: no such file or directory, open '/Users/rglaser/workspace/innoq/innoq.com-cms/public/assets/manifests/static.json'
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '/Users/rglaser/workspace/innoq/innoq.com-cms/public/assets/manifests/static.json' }

Every consecutive run after that won't emit this warning.

faucet.config.js:

const sassConfig = {
    manifest: {
        file: "public/assets/manifests/stylesheet.json",
        baseURI: (bundlePath, baseName) => `/assets/stylesheets/${baseName}`
    },
    assets: [
        "public/assets/manifests/static.json"
    ],
    prefixes: {
        browsers: [ "last 2 versions" ]
    },
    bundles: [{
        entryPoint: "app/assets/stylesheets/frontend/application.scss",
        target: "public/assets/stylesheets/frontend/application.css"
    }]
};

const staticConfig = {
    manifest: {
        file: "public/assets/manifests/static.json",
        baseURI: (bundlePath, baseName) => `/assets/static/${baseName}`
    },
    bundles: [{
        source: "app/assets/images",
        target: "public/assets/static"
    }]
}

module.exports = {
    sass: sassConfig,
    static: staticConfig
}

ESM compatibility

recent versions of Node (since v13?) refuse to load faucet.config.js for ESM projects, i.e. such with "type": "module" in package.json:

Warning: require() of ES modules is not supported.
require() of …/faucet.config.js from …/node_modules/faucet-pipeline-core/lib/config.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename faucet.config.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from package.json.

renaming the config file (i.e. faucet -c faucet.config.cjs) is a viable workaround, but not very satisfying

`resolveModulePath` fails on legacy Node

• Node v6.x

  should balk at non-relative paths in config:
  Error: could not resolve "src/index.js"

  https://travis-ci.org/faucet-pipeline/faucet-pipeline-js/jobs/339617784

  this is because we expect this exception to be raised, but instead we get this exception - which in turn is because in legacy mode resolveModulePath works exclusively for package paths, not falling back to relative paths (arguably that's how it should work, but it's inconsistent with non-legacy mode's require.resolve(…, { paths: … }))

  it's actually more complicated than that: faucet-pipeline/faucet-pipeline-js@dd518ba (not sure about precedence either) - the fix would be to change this line to

  process.env.NODE_PATH = `${rootDir}:${rootDir}/node_modules`;

  (modulo precedence) which would change semantics for legacy versions though (see above)

• Node v8.x

  should support Node resolution algorithm for entry point:
  Error: could not resolve "dummy/src/index.js"

  https://travis-ci.org/faucet-pipeline/faucet-pipeline-js/jobs/339617785

  turns out this is a bug in Node: nodejs/node#18686

Catch ENOSPC when watching, give hint, then crash

When ENOSPC is raised when we start watching, we are probably on Linux and exceed the number of files we can watch. In this case, we recommend using the watchDirs option to reduce the number of watched files. We should give this hint and then crash.

testing harness

perhaps using spec.sh?

`require.resolve` doesn't work for folders in `node_modules`

... this may occur when copying an entire folder in faucet-pipeline-static:

{
    source: "leaflet/dist/images",
    target: "./dist/images",
}
´``

faucet complains:

ERROR: could not resolve "leaflet/dist/images"

This works:

```javascript
{
    source: "./node_modules/leaflet/dist/images",
    target: "./dist/images",
}

The underlying problem is that require.resolves tries to look for an index.js when a directory is specified:

$ node
> require.resolve("leaflet/dist/images")
Thrown:
{ Error: Cannot find module 'leaflet/dist/images'
Require stack:
- <repl>
    at repl:1
    at Script.runInThisContext (vm.js:122:20)
    at REPLServer.defaultEval (repl.js:332:29) code: 'MODULE_NOT_FOUND', requireStack: [ '<repl>' ] }
$ touch node_modules/leaflet/dist/images/index.js
$ node
> require.resolve("leaflet/dist/images")
'/home/lars/tmp/node_modules/leaflet/dist/images/index.js'

Bug: `faucet` CLI defaults to no fingerprinting

Because @FND refused to set a default value for minimist, it defaults to false. The default in index.js is therefore futile.

An in-range update of browserslist is breaking the build 🚨

The dependency browserslist was updated from 4.5.5 to 4.5.6.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

browserslist is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

• ❌ continuous-integration/travis-ci/push: The Travis CI build could not complete due to an error (Details).

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

Source map Support

Please add source map support where possible (sass, javascript, typescript should support it).
Thanks

`faucet --init`

To make it easier to get started, we offer an init process that creates the config file.

replace Travis CI

because le sigh

GitHub Actions seems like the obvious candidate (while we're at it, we might as well look into status checks)

(this applies to all faucet repos)

More customization for the manifest output

In the upcoming version, we will only produce a single manifest file. The manifest file can be customized a little, but the "key" side of the manifest is pretty much fixed. For people coming from Rails, the long paths mean that it no longer is a drop in replacement. So we will discuss how to enable people to customize it.

presets for common use cases

It would be nice if getting started was a simple two-step process:

$ npm install faucet-pipeline faucet-pipeline-js faucet-pipeline-sass
$ faucet --presets=js,sass,manifest --fingerprint

Thus --presets would replace faucet.config.js for common use cases, reducing infrastructure, moving parts, maintenance burden, cognitive load etc.

However, presets would not allow for any customization; if that's required, faucet.config.js should be used.

In the example above, the presets would result in the following configuration:

{
    sass: [{
        source: "./src/index.sass",
        target: "./dist/bundle.css"
    }],
    js: [{
        source: "./src/index.js",
        target: "./dist/bundle.js"
    }],
    manifest: {
        file: "./dist/manifest.json",
        baseURI: 🤔 // not sure how this would work
    }
}

simplify plugin registration

see #59 (comment)

    plugins: {
        foo: {
            plugin: "/path/to/foo",
            bucket: "scripts"
        }
    }

this is unnecessarily awkward for end users, so plugins should (optionally) determine bucket and possibly configuration key themselves:

    plugins: ["/path/to/foo"]

    plugins: {
        foo: "/path/to/foo"
    }

drop Node 6 compatibility after 04/2019

The v6 release line now moves in to "Active LTS" and will remain so until April 2018. After that time it will move in to "Maintenance" until end of life in April 2019.

https://nodejs.org/en/blog/release/v6.9.0/

This would alllow us to

• replace our own promisify with Node 8's util.promisify
• consider using async/await 😍