yarn build --watch is broken
See original GitHub issueit looks like somewhere along the line, someone broke the tsc --build --watch
setup we had. yarn build --watch
no longer works. this breaks the development workflow for the LSP server and other parts of the ecosystem, because the file watcher is no longer. It took me a few hours to realise that this was the issue with developing the LSP server, because as you can see the vscode launch task is now broken
for a long time we’ve had two scripts, as documented in CONTRIBUTING.md:
yarn build
builds the typescript project references. this should be reduced to esm/modern only as we introduce viteyarn build-bundles
builds with vite, esbuild or webpack, with bundlers.
many scripts depend on being able to pass parameters to tsc --build
such as tsc --build --watch
or tsc --build --clean
.
My proposal:
@graphiql/react
should be added to the list of project references- the
yarn build-bundles
script should be added to graphiql-react workspace for the vite build. see graphiql or vscode-graphql for an example. - the
yarn build
command should work as before, so that the other commands and tooling that depends on it can count on that, so that we can useyarn build --watch
oryarn build --clean
again, which is documented in CONTRIBUTING.md. Currently, if a user tried to contribute to the repository, the CONTRIBUTING.md would not reflect this at all! - the result would be that the vscode debugger runs properly, and actually watches and rebuilds on changes again!
Issue Analytics
- State:
- Created a year ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
yarn run watch not working + yarn run dev very slow · Issue #439
When running yarn run watch in my main laravel folder (where the package.json is located), after compiling it does not notice any file...
Read more >Issue running yarn watch with webpack - Stack Overflow
I ran into an issue running yarn watch . Here is my code in webpage.config.js: const path = require('path'); // include the js...
Read more >Yarn develop --watch-admin is not working - General
I am developing a local plugin and in this process I need to run yarn build & yarn develop to even see the...
Read more >Error Codes | Yarn - Package Manager
A package build failed. This problem typically doesn't come from Yarn itself, and simply means that a package described as having build directives...
Read more >[5.4] npm run watch not working - Laracasts
Have you tried the usual? Upgrade node. A lot of the times hot reloading doesn't work because you haven't got an updated node...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think I can do this as a small PR later today to address this as a transitional solution, and pull it into my current working branch for the LSP server and
vscode-graphql
big picture wise, we can look at alternative, incremental, cross-monorepo tooling that truly replaces what tsc project references incremental watcher provides. I haven’t found anything in vite/rollup or esbuild or other ecosystems to match, but there are promising contenders I keep revisiting! I was hoping to open a discussion about this. we have a PR open to migrate graphiql’s bundling to vite that potentially invites this transition itself!
this looks like a promising path away from typescript project references, perhaps:
https://vitejs.dev/guide/dep-pre-bundling.html#automatic-dependency-discovery
Personally I think SWC is the most promising compiler, and vite/rollup the most promising bundler ecosystem, so I would love to look at something like this:
https://github.com/natrim/vite-plugin-swc-only
I recommend that you move to
yarn build:watch
/yarn build:clean
style of commands; these are less likely to break in this manner, but more importantly should you change your build tooling from tsc to an alternative, the commands devs type would not change even if the new tooling expects different flags.