1. do something with files specified in main that are not compiled
2. don’t treat as assets assets-matching bower components (bootstrap/docs/assets/boostrap.js)

Using the watcher, after a number of saves over a period of time the compiler appears to stop actually compiling, though the console shows that it is still building (correct timestamp, etc.). Not sure if this is related to compulsive / rapid cmd+s's or what; this only started happening after upgrading to the latest version.

After using brunch for almost a year, the brunch watch function suddenly stopped detecting my file changes today. If I run brunch watch, I get the normal info: compiled X files... message without errors, but after updating one of the files, nothing happens. If I stop brunch watch and then run it again, the changes I made before are compiled fine.

My setup:

• I run VirtualBox on a Windows host machine with help of Vagrant
• I use brunch 1.7.18 on Ubuntu 12.04.5

I've tried to update all NPM dependencies, and also reloaded and even rebuilt my vagrant box. Nothing seems to work.

How can I debug this issue?

Right now, when you create something with a template, you just use a snapshot of that template right now.

However, templates change all the time. html5 boilerplate gets updated, chaplin gets updated... This means that everything that's in your template, but not a JS dependency, does not get updated and therefore gets outdated quickly.

brunch obviously has mechanisms for updating the JS dependencies. To me, it only makes sense that whatever your template depends on would get updated too.

I have mailed @paulmillr about this and he agrees that this should be raised as an issue and hopefully something nice can be found to fix this problem.

Because everything is pretty much on github anyway, I think that git submodules should be involved, and the template should just use the upstream repository (perhaps with symlinks -- although I don't know how well they work on windows). That way, you can literally just update all the submodules and be synced with upstream.

It seems a bit fragile to have to rely on the order of declaration in package.json to determine the order that plugins are invoked in, given that npm --save reorders the dependencies alphabetically. I'm basing this on brunch-guide, and a cursory glance over the source code.

It would be nice if this could be overridden in config.

On another note, I'd quite like to be able to add locally-defined plugins without having them be a package in node_modules.

There doesn't seem to be an entry in the changelog for that .. Jade-angularjs-brunch won't work anymore since the update (undefined's not a function).

• Brunch: v1.7.14
• Node: v0.10.28
• OS: Ubuntu 12.04.4 LTS

When attempting to build using v1.7.14 on Ubuntu, builds fail silently (exit code 0) about 50% of the time (after only 4-5 brunch:watch log events) with the final log line showing info: compiled in NaNms. No error is logged, and nothing in the debug output shows what might be causing the issue. The sporadic behavior makes me thing there's a race condition somewhere. My current hunch is that something's changed with fs events, possibly in chokidar. The fact that I can build normally using v1.7.14 on OS X reinforces this—it's something particular to the Linux platform. In any case, the fact that it's not reporting the error makes the problem difficult to figure out.

We've done a careful regression test, and the only change for us that could be causing this is the v1.7.14 upgrade. After reverting to v1.7.13, builds are working normally for us everywhere. If we learn anything more about a possible underlying cause, I'll update this ticket.

Recently I've found great testing library that seems to be even better than jasmine: visionmedia/mocha.

It has several advantages:

• node.js support out-of-box (no more jasmine-node spikes)
• active development (some issues with pull requests stuck in jasmine for almost year)
• @visionmedia as a maintainer -- it means that library would be soon widely used, even more than Jasmine

As long as 0.9 isn't out, the switch would have no effect on our users. Jasmine support would be added as a separate plugin with new plugin system.

@omarkhan i'm especially interested in your opinion about mocha.

I had an idea when thinking about general brunch optimization and the issues with sass being so slow. Brunch could cache compiled, pre-concatenated output to disk (perhaps in a .brunch-cache directory). It would also need to keep a reference of the compilation time (fs.utimes may be sufficient) and the dependency list. On the next instantiation of brunch, before bothering to compile again, it checks to see whether it is necessary to do so.

Users could opt-out of all this in config. Also, potentially this behavior doesn't even kick in unless overall compilation time passes some threshold, like 5s maybe. Or maybe that time limit is actually applied in a granular way, like any source file that takes >2s to compile gets its compiled output cached to disk.

I'm pretty sure it would be a massive benefit to a project I have which includes some slow-compiling sass and less that hardly ever gets edited.

Thoughts?

filesets:
  anyFilesetKey:
    files: # string, regex, glob, or array of any of those
    javascripts: # nearly the same as config.files.javascripts
      joinTo: # if string, join all in set to this file
        # if object similar to current, except allow more
        # flexibility as above in files property
      separate: # write a separate compiled file for each match
      order: # allow regex and glob in array
    stylesheets: # same mods as above
    templates: # same mods as above
    compile: # boolean, default true, if false treat as assets
    pluginsOn: # specify which plugins should be applied to this set
    pluginsOff: # use all plugins except these
    config: # override any other config values for this fileset

To supersede config.files and config.conventions in a backward compatible way by translating them into matching fileset-formatted config objects using fileset keys vendor, app, and assets. Vendor fileset will turn off wrappers in config override and assets fileset will set compile: false.

This would allow enough flexibility to do things like multi-project compilation in a single brunch process (override paths.public per fileset) and building of backend node apps.

Hi, Source maps, wow, amazing. Congrats!!! Now back to subject:

1. gifs from app/assets copied as empty files. And a random error:

stream.js:81 throw er; // Unhandled stream error in pipe. ^ Error: OK, open '..../file.gif'

1. //@ sourceMappingURL=app.js.map string always attached to js file (even the mapping is disabled
2. vendor libraries start to crash (tested with http://github.com/razorjack/quicksand 1.2.2 and 1.3) (Uncaught TypeError: undefined is not a function )

and 2 suggestions:

1. a switch to chose between generating sourcesContent and making a link to app and vendor folders
2. disable vendor folder mapping Thank you very much Paul

https://github.com/brunch/brunch/issues/1890

It seems that anymatch 3.1.3 no longer automatically strips trailing slashes from paths before matching. This PR handles the stripping of the trailing slash before the match operation occurs.

Brunch won't work with new versions of anymatch without these changes, and the current package.json will not prevent new projects from pulling anymatch 3.1.3+. Thus nothing will work for new users until this is fixed.

Also, without this patch, npm update will break existing projects. This break may be silent as the index.html and other assets may already be built. They will NOT be correctly rebuilt without this patch. Furthermore, any CI/CD that depends on spinning this up from scratch will fail.

This patch seems to play nice with anymatch 3.1.1 and 3.1.2.

Description

The assets directory is not being handled correctly in a new project.

Expected behavior

The index.html file should be built to the public/ directory.

Actual behavior

The index.html file is built to the public/assets/ directory.

Environment

1. Brunch Version: 4.0.1
2. Node.js Version: 19.2.0
3. NPM Version: 8.19.3
4. Operating system: Debian GNU/Linux 11 Kernel 5.10.0-19-amd64

package.json contents

{
  "name": "brunch-app",
  "description": "Brunch.io application",
  "private": true,
  "author": "Brunch",
  "version": "0.0.1",
  "repository": "",
  "scripts": {
    "start": "brunch watch --server",
    "build": "brunch build --production"
  },
  "dependencies": {},
  "devDependencies": {
    "auto-reload-brunch": "^2",
    "brunch": "^4",
    "clean-css-brunch": "^3",
    "terser-brunch": "^4"
  }
}

brunch config contents

none

Hey,

Recently, some of the dependencies of brunch plugins we use were converted to ES modules. That means that to update these, the plugins needed to also be converted to ES modules. However, brunch did not work with ES modules.

I took a crack at it, and was able to convert brunch to work with both commonjs and es modules. So far I have converted two of our plugins to ESM, while leaving the remaining as commonjs with no issues. The two that I have moved to ESM are imagemin-brunch and replacer-brunch. (we have our own forks of these plugins, as it was faster to manage and patch bugs ourselves, but they are largely unchanged from the current versions).

Is this something that you would be interested in a PR?

If this is not something that is currently in the future scope of brunch, please feel free to just close this issue. Just through I would share as it seems the move to ESM is progressing.

Obviously, this is not as good as native ESM support, and more of stop gap to get ES modules working with brunch today. Converting brunch to an ES module would require a lot more work.

The code in this gist shows the method changed in the plugins.js file, the patch is denoted with enclosing comment blocks. https://gist.github.com/Jesspu/4bf38ea7db5b1e394449855967978a6c

Also, here is an example of what a brunch plugin looks like when converted to ESM (there may be a better way to to do this, but it has worked). https://gist.github.com/Jesspu/f30930cc4c492ff71565ca207214c7ca

I love brunch, and really appreciate all the work that has been put into it.

while having in code something like

import { useState } from 'preact/hooks'

brunch finds and merges node_modules/preact/hooks/dist/hooks.js to vendor.js but at runtime we've:

vendor.js:62 Uncaught Error: Cannot find module 'preact/hooks' from 'components/app.js'

looking at vendor.js we can see that problem may be caused by non-existent alias preact/hooks => node_modules/preact/hooks/dist/hooks.js

Description

When trying to run a custom server, it is not started.

Expected behavior

The custom server should obviously be started

Actual behavior

The command has no effect.

On previous version of Brunch, the server is correctly started, as the log shows it:

With Brunch 3:

npx brunch watch --server
11:17:49 - info: app started on http://localhost:3333/

With Brunch 2:

npx brunch watch --server
[Wed Dec 25 11:59:50 2019] PHP 7.4.1 Development Server (http://localhost:8000) started
11:59:50 - info: custom server started, initializing watcher

Environment

1. Brunch: latest (just installed)
2. Node.js: 12.13.1
3. NPM: 6.12.1
4. Operating system: Linux Fecora 31
5. Code editor: Atom

Brunch config contents

  server: {
    command: "php -S localhost:8000 -t public/"
  },

The code for now:

// function processFileParallel(file, isStatic) {
//   const WorkerPool = require('../workers/pool');
//   if (WorkerPool.instance) {
//     return WorkerPool.instance.schedule([file, isStatic]);
//   }
//   return processFile(file, isStatic);
// }


// const sysPath = require('path');
// const {EventEmitter} = require('events');
// let threads;
// try {
//   threads = require('worker_threads');
// } finally {}
// exports.enabled = true;

// // 1. no workers
// //   main => processFile(file) =>
// // 2. workers
// //   main => processFile(file) =>
// //     pool.determineWorker(file) =>
// //     worker.postMessage(file) =>
// //     parentPort.postMessage(processed)
// // TODO:
// // this.workers = await WorkerPool.create(application.stripOpts(options));
// class WorkerPool extends EventEmitter {
//   // static instance;
//   /**
//    * @returns {Promise}
//    */
//   static schedule(args) {
//     if (!WorkerPool.instance) {
//       throw new Error('No worker pool');
//     }
//     return WorkerPool.instance.schedule(args);
//   }

//   static create(options) {
//     return new Promise(resolve => {
//       const pool = new WorkerPool(options);
//       pool.once('ready', () => {
//         resolve(pool);
//       });
//     })
//   }

//   constructor(options) {
//     super();

//     WorkerPool.instance = this;

//     if (!threads) {
//       throw new Error('Workers are not supported');
//     }
//     const { Worker } = threads;

//     const data = {workerData: {options}};

//     this.counter = 0;
//     this.workers = [];
//     const count = 6 || require('os').cpus().length;
//     this.workersToInit = count - 1;

//     const file = sysPath.join(__dirname, 'listen.js');
//     for (let i = 0; i < count - 1; i++) {
//       this.workers.push(new Worker(file, data));
//     }
//     for (let worker of this.workers) {
//       worker.on('message', msg => this.handleWorkerMessage(msg));
//       worker.on('error', err => { throw err; });
//       worker.on('exit', () => {
//         this.workers.splice(this.workers.indexOf(worker), 1);
//       });
//     }
//   }

//   handleWorkerMessage(msg) {
//     if (msg === 'ready') {
//       this.workersToInit--;
//       if (this.workersToInit === 0) {
//         this.emit('ready');
//       }
//       return;
//     }
//     this.emit(msg.id, msg.result);
//   }

//   schedule(args) {
//     const counter = this.counter++;
//     const worker = this.workers[counter % this.workers.length];
//     const id = counter.toString();
//     worker.postMessage({type: 'compile', id, args});
//     return new Promise(resolve => {
//       this.once(id, resolve);
//     });
//   }

//   async dispose() {
//     await Promise.all(this.workers.map(t => t.terminate()));
//   }
// }
// WorkerPool.instance = undefined;

// if (threads && !threads.isMainThread) {
//   async function initWorker() {
//     const {isMainThread, parentPort, workerData} = require('worker_threads');
//     const application = require('../utils/config');
//     const pipeline = require('../fs_utils/pipeline');
//     const {options} = workerData;
//     options.fromWorker = true;
//     const [cfg, {plugins}] = await application.loadConfigAndPlugins(options);
//     pipeline.setPlugins(plugins, cfg.npm.compilers);

//     parentPort.on('message', async ({type, id, args}) => {
//       if (type === 'compile') {
//         const result = await pipeline.processFile(args[0], args[1]);
//         parentPort.postMessage({type, id, result});
//       }
//     });
//     parentPort.postMessage('ready');
//   }
//   initWorker();
// }

// module.exports = WorkerPool;