webpack-dev-middleware
webpack-dev-middleware copied to clipboard
webpack
clarification if `context` is public or private API
Documentation Is:
- [ ] Missing
- [ ] Needed
- [ ] Confusing
- [x] Not Sure?
Please Explain in Detail...
When creating instance of middleware it provide object with methods that are documented as public API (like waitUntilValid, invalidate, close), but also it contains context which is not documented. It is used in "express-style" middleware internally, so it might be considered private API (or might be just not documented API that can be used publicly).
Your Proposal for Changes
Either explicitly clarify that context is considered private API and should not be relied on or add context related APIs to README (and potentially to @types/webpack-dev-middleware, but that's probably outside of the scope of this repo)
My motivation behind request for clarification:
In my proof of concept code I'm reaching to webpackDevMiddlewareInstance.context.watching to be able to suspend/resume webpack watching to control when webpack is "allowed" to recompile, but I'm not sure if I'm using private API (which can change any time) or not.
In my proof of concept code I'm reaching to webpackDevMiddlewareInstance.context.watching to be able to suspend/resume webpack watching to control when webpack is "allowed" to recompile, but I'm not sure if I'm using private API (which can change any time) or not.
Interesting use case, can you provide some real examples?
~~Honestly, I would have made it private. If you need something new for new ideas we can implement method for this.~~
I was wrong, it is public API, we need to document this
Interesting use case, can you provide some real examples?
This is for a feature I work on for gatsby, the code is not really ready/working yet, but the gist is that we have 2 quite separate services (we have more - but for this thing only 2 are relevant):
- one for frontend source code (that's our webpack related things)
- another one for data layer (which is separate from webpack)
Because those 2 are not interconnected right now they can run independently today and there is no need to coordinate them (we might sometimes get some unnecessary webpack recompilations, but right now they are at most "wasteful" and not breaking).
Feature I work on can be described as "data-driven code-splitting" and gist of it is that data can decide which stuff gets bundled (some information in https://github.com/gatsbyjs/gatsby/issues/18689 ). The problem I'm facing now is that this feature introduce interdependencies between previously 2 isolated systems. If just gatsby internals were able to trigger changes that cause webpack recompilation I would be fine - but because user can invalidate (as in edit some frontend code) while other work is happening we could emit hot-update in rather unfortunate timing leaving user with temporarily weird/broken/inconsistent state (it will fix itself eventually on its own - but "damage" can be done already in browser, causing runtime errors there etc, providing just subpar DX). So idea here is to suspend/pause webpack when there is other work happening and resume when "idle" which should result in emitting updates at time points when we know everything else is processed which should (in my head at least right now) prevent broken states in browser.
Yes this whas been documented now and part of @types packaging so this is great!
