feature(notes): added latest sep 7 meeting notes #13
Conversation
reference correct details
|
|
||
| * Don't want linting too strict, just enough to provide, autoformatting, and eliminate the number of round of reviews for PR's. | ||
|
|
||
| * The topic of Cont. Deployment came up for our documentation. We veiw some other pages and it apeard Codeship is a popular option as well as Travis but requires more work. An issue will be created in the docs repo. |
There was a problem hiding this comment.
Maybe I should setup proselint on here. 🤔
fixed indentation on view
| @@ -0,0 +1,80 @@ | |||
| ## August 31 ([discuss](https://github.com/webpack/meeting-notes/pull/13)) | |||
Update correct date and comments from Johannes on mentioning deprecation warnings.
| * additionally noted it would fall after optimization and before id creation (in the compilation step) | ||
| * This would also allow ts-loader and awesome-typescript-loader to execute typechecking in the resolve promise. (allowing tools like HappyPack to execute loaders parallel/multithreaded) | ||
| * Johannes mentions that it would be important that we get feedback from loader authors to see if this would help solve some of their issues (including HappyPack). | ||
| * Tobias described, (once implementing this feature [based upon the comments in the linked issue]) that a `disk-cache-loader` would look similar to having the following. |
There was a problem hiding this comment.
If it is of interest at all, I have a local prototype of something very similar to a disk-cache-loader. A comment from my source that describes what I was trying to do:
// If we have a persisted cache for this loader run,
// and that hash hasn't changed since last time (note hash includes file content, full loader request, version, and context)
// and none of its dependencies have changed (pulled from previous `module.fileDependencies`),
// then we can return the cached result & source map from the LRU-ed disk cacheIt still is quite rough, and I'm very aware that "misbehaving" plugins and loaders could break it (for our use case I'm ok to whitelist the cache for specific loaders). But I'm glad to try and get it to a share-able state in the future if the core team thinks that is helpful.
There was a problem hiding this comment.
One potential issue is with plugins that use an external config; e.g. eslint, babel (with .babelrc), ts (tsconfig.json is pretty much required). If the config changes, the output will most likely change too, but a naive approach would only notice it if it's part of the query.
Other loaders have the (much more convenient) option of reading their config from the webpack config object itself, like postcss-loader. As the config option may be a function, it can be harder to cache (in fact I use that property to use a different postcss syntax plugin per file type).
Perhaps a caching API could be provided, where the plugin itself can declare the state it is going to use to execute its load?
This would still leave funny cases such as browserslist files.
There was a problem hiding this comment.
Even though plugins don't have a dedicated API for it, they can still append config files to the compiler's list of fileDependencies which will cause the watcher to track when that config file changes. Plus this is even easier for loaders since there is dedicated addDependency API.
Sure, there still is trickiness boiling that config object down and persisting the state in some hash (libs like this can help?) . And having dedicated webpack APIs to modify/append a compilation's hash or individual module hashes would be helpful. But I think that is straight-forward.
(IMHO, the hard part is teaching and encouraging loader/plugin authors to remember to track extra things like config files, a version number to change the hash as internal code changes, etc).
There was a problem hiding this comment.
Maybe you could give feedback on this proposal?
@webpack/collab-team
@webpack/contributor-team
Alright 👀 appreciated for the review of the notes. Thank you