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

Support watching & live-reload of locally linked dependencies (e.g. in monorepos) #819

Closed
schickling opened this issue Sep 15, 2020 · 4 comments

Comments

@schickling
Copy link
Contributor

Is your feature request related to a problem? Please describe.

It's a common scenario for most medium/large sized applications to be structured in a monorepo setup consisting on multiple packages with some kind of internal dependency structure (e.g. to factor out common components between two packages or when working with a design system).

Currently just files within the actual Vite app are watched for changes which triggers a HMR live-reload event. Changes in any of the "local dependencies" (e.g. a shared React component in another linked package) won't be detected and therefore not result in a live-reload event.

Describe the solution you'd like

It would be great if Vite would also listen to file changes in locally linked dependencies. This will enable developers to freely structure their application code while still benefiting from Vite's great HMR live-reload functionality.

Based on my current understanding Vite should most likely listen to whatever the dependency package has provided as main in its package.json file (e.g. ./dist/index.js). This will probably also require the user to make sure the dependency package itself is always automatically re-built so Vite can pick up the file changes (e.g. by running tsc --watch in the local dependency package).

In terms of API, maybe Vite could automatically watch for local dependency file changes when optimizeDeps.link is configured.

Describe alternatives you've considered

Adding an additional config option (separate from `optimizeDeps.link) to list out which files Vite should also watch.

Additional context

A further consideration would be if this would also require respective Vite plugins (such vite-plugin-react) to support this functionality.

@andrew0
Copy link
Contributor

andrew0 commented Sep 21, 2020

You should already be able to accomplish this, I believe. For example, if you have a monorepo with this directory structure:

my-monorepo/
    packages/
        my-application/
            src/index.ts
            package.json
            vite.config.js
        my-shared-components/
            src/index.ts
            package.json
    package.json

then you could set your vite.config.js file to

const path = require('path')

module.exports = {
  root: './src',
  optimizeDeps: {
    link: ['my-shared-components'],
  },
  alias: {
    'my-shared-components': '/@linked/my-shared-components/index.ts',
    '/@linked/my-shared-components/': path.dirname(require.resolve('my-shared-components/src/index.ts'))
  }
}

@schickling
Copy link
Contributor Author

schickling commented Sep 22, 2020

Thanks a lot for your detailed comment @andrew0. I've given your suggestion above a try but unfortunately the live-reload functionality (incl. React Fast Refresh) didn't work. Is there anything additionally that needs to be configured? (cc @underfin)

Update: I've now migrated my project to make use of TypeScript Project References and got things to work. Weirdly though it seems to work also without the TS project references functionality enabled, so in the migration process I must have changed something else that now makes your solution above work.

@andrew0
Copy link
Contributor

andrew0 commented Sep 22, 2020

I'm glad you were able to get it working. I set up a more complete example of the config I was suggesting here: https://github.com/andrew0/vite-react-ts-monorepo

This could probably be made easier to configure, as a lot of people have requested something like this, i.e. #330, #725, #786. There also isn't a way to use Vite to compile your component as a separate package afaik, so you would probably want to setup rollup or something for the library components.

@schickling
Copy link
Contributor Author

Thanks again @andrew0! Closing this issue in favor of #725.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants