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

Multiple watch folders? #348

Closed
norbert-codes opened this issue Sep 2, 2017 · 3 comments
Closed

Multiple watch folders? #348

norbert-codes opened this issue Sep 2, 2017 · 3 comments

Comments

@norbert-codes
Copy link

How is it possible to specify more than one (by default /src) watch folder for the dev server (npm start)?

The reason is that I'm developing an app, which has some npm dependencies, which I'm also developing, and they are scoped/private packages, so will reside in something like /node_modules/@scope/, so watching this folder and linking those dependencies there would be awesome.
Is it possible somehow? (Of course /src needs to be watched too.)

npm link would solve the issue ofc., but has a long and troubled history with webpack, because of symlinks, so my current solution is that I copy the dependencies on change with wml to the apps node_modules folder, but it won't cause a live reload on the dev server.

Thanks for the answer!

@lukeed
Copy link
Member

lukeed commented Sep 26, 2017

I don't think it's possible to watch multiple "src"-type directories in Webpack -- at least, not without running multiple compilers.

You can continue to play with symlinks, as you've suggested, or you can play with the watchOptions. Our included config ignores all node_modules by default for apparent reasons.

Going to close, but I hope that helped in some way 😬 Sorry for the delay -- this was just brought to my attention. 🌴

@lukeed lukeed closed this as completed Sep 26, 2017
@norbert-codes
Copy link
Author

norbert-codes commented Sep 26, 2017

Sorry for the delay -- this was just brought to my attention. 🌴

Thanks anyway! 🎉

In the meanwhile started to experiment with a yarn-workspaces based monorepo, and it seems to solve a lot of problems with symlinks so far.

@lukeed
Copy link
Member

lukeed commented Sep 26, 2017

Cool! I'll look into it sometime.

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

No branches or pull requests

2 participants