Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring in new fs sandboxing system #357

Open
3 tasks
yocontra opened this issue Mar 20, 2014 · 8 comments
Open
3 tasks

Bring in new fs sandboxing system #357

yocontra opened this issue Mar 20, 2014 · 8 comments

Comments

@yocontra
Copy link
Member

  • Update plugin guidelines and documentation to explain this
  • Open issues on all plugins that need this added linking to the new docs
  • Add this to a few prominent modules (sass, less, stylus, browserify, require.js)

To describe the problem, look at browserify. It likes to read all of it's own dependencies in. We prefer to do the IO so we can pass virtual files to these modules. Currently this isn't possible without writing to a tmp folder and then giving the tmp folder to browserify so it can load the modifications that a plugin up the pipeline made. Instead we can trick browserify into thinking the set of virtual files (purely in memory) are the real fs by wrapping it in a contextify sandbox where fs = a set of virtual files. This will be a module that plugin authors use under the hood to help deal with these modules.

@phated
Copy link
Member

phated commented Aug 26, 2014

Is the webpack memory-fs module at all useful for this?

@yocontra
Copy link
Member Author

Looks good - there is no stream support though. I can send a PR when I have a minute

@yocontra
Copy link
Member Author

If anyone is interested you can monitor progress here https://github.com/wearefractal/vinyl-fs-tree

@ilanbiala
Copy link

@contra any changes happening for this? I saw vinyl-fs-tree hasn't been touched much.

@yocontra
Copy link
Member Author

@ilanbiala It got put on the backburner, might get moved to 4.1 since its just a tool to make plugins easier to write

@ilanbiala
Copy link

Ok, sounds good.

@spelufo
Copy link

spelufo commented May 18, 2015

I've been trying to figure out how watching in gulp works, and my understanding so far is that every time a file that matches the glob changes, you orchestrator.prototype.start the task passed as argument. So if that task returns gulp.src('glob').pipe()....dest(), a new stream that emits vinyl-fs objects is created, and all the files matching the src glob are emited and read, not only those that changed. Is this right? And what is being proposed here is to cache the files, right?

Wouldn't it be better if gulp.watch returned a readable stream that emits the vfs objects of the files that change? Then it would be interchangable with gulp.src, I think.

@yocontra
Copy link
Member Author

@spelufo streams/tasks that never end is an anti-pattern

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants