![Helping people make the world a better place through quality software](https://raw.githubusercontent.com/kentcdodds/kentcdodds/main/image.png)
kentcdodds / webpack-validator-deprecated Goto Github PK
View Code? Open in Web Editor NEWUse this to save yourself some time when working on a webpack configuration.
License: MIT License
Use this to save yourself some time when working on a webpack configuration.
License: MIT License
@kentcdodds Looks good. The entry validator should not check for file existance, as the string is resolved, which means you can omit extension, add query parameters, add loaders, use modules paths. This is disallowed when checking of file existance.
Basically doing this validation thing is going to be really hard because Webpack is amazingly flexible.
I have setup the project according to the Contributing guideline
No matter which npm script I run I get errors.
npm run validate
generates the following npm-debug.log:
I really have no idea how to fix this. Sorry for the inconvenience :-(
Let's focus discussion about a monorepo approach started in #40 here.
https://github.com/kittens/lerna is the tool used by Babel to deploy / organize their repo. Should we use it? I think automatic releases are not possible with this tool, but I wonder how they'd be possible at all. The commit message doesn't tell us which package was changed, so it won't be possible to automatically derive the changelog from the commits.
An approach discussed in #17 for solving the architectural question of how to integrate support for custom / not-webpack-core validators looks as follows:
package.json
for packages named webpack-validator-plugin-...
. These plugins are then automatically used without the user needing to set them up, thereby reducing tooling fatigue....-loader
that export something under ...-loader/validate
. This allows webpack plugin maintainers to supply a validation function for their plugin without having to create a new project.webpack-validator-plugin-...
packages could import a set of webpack config test cases from somewhere (new package?) to verify their behaviour.Any thoughts on this? Will probably have some time on the weekend to tackle this.
Cheers, Jonathan
validating that extensions
match the regexp test
resolve: {
extensions: ['.js','.html']
},
module: {
loaders: [
{ test: /\.html$/, loader: 'raw-loader'}
]
},
I think the biggest thing you want to check if is people are using unsupported field names. This is true both at the root level and inside nested objects.
So the more of those validate functions i'm writing the more i'm asking myself if this approach is optimal. We are in fact doing 95% schema validation, a task which a library like joi (or maybe the one you wrote, Kent, api-check ?) solves perfectly, but we are writing this very imperatively and with ad hoc, non-normalized error messages.
In fact i am thinking of experimentally starting an alternative approach in another repo, maybe just called webpack-joi-schema
and see how far this would replicate the use case of our approach here. The main goal would be finding out where the limits of using a schema validation library would be and maybe check out if the burden of all those manual tests could be "extracted" onto the shoulders of a mature, more generic library -- thereby substantially reducing the error surface.
Same behavior as in configuration-validator
I have a config listing vendors, similar to the example shown on the page: https://webpack.github.io/docs/code-splitting.html with simply the name of the npm modules listed like here:
entry: {
vendor: ["jquery", "underscore", ...],
},..
However, I get a validation error, that entry: no file exists at .........../jquery
for example. Indeed, it doesn't consider that jquery is a npm module and look simply at the root of my project whether it exists a jquery.js file.
Is that pending on purpose?
Could we assign the issues to individual, if they want to work on it and add a assigned
flag, so that, whoever is free, can take up any unassigned
issue.
Thoughts? / @kentcdodds @nyrosmith
loaders
vs loader
and when to use them
Implement validation for stuff configured in resolve
.
Node 0.10 doesn't support the dot reference.
Looks like our first task after this gets merged is to update anywhere that we say: import foo from '.' to say: import foo from './index' because Node 0.10 doesn't support the dot reference.
Or maybe there's a babel plugin we could use (which would be sick). I wonder if there's a babel preset for Node 0.10. That would be a amazing...
Ideally this should be fixed before #30 can be merged.
I think more labels could give us a better overview of the issues state. I propose "CLI" and "On Hold" as new labels.
Also everyone that picks an issue should assign himself or if insufficient rights he adds a comment that he picks it. This avoids unnecessary work as it happend to me yesterday.
Any thoughts?
We would like to take the opportunity to invite someone who did not yet contribute to webpack-validator to work on this issue. Follow @YourFirstPR on Twitter for more of these issues across many open source projects :)
We want to support node v0.10, where path.parse
from the node standard library isn't yet available. So path.parse should be replaced by using the npm module path-parse.
Steps:
npm install --save path-parse
tests/passing-configs/index.js
, replace path.parse
with the function from the path-parse
package (you'll need to install it by running npm install --save-dev path-parse
and then import it at the top of the file).--no-verify
on your git commit
and push to ask for help.In Webpack config:
entry: [
'webpack-hot-middleware/client',
path.join(__dirname, 'index');
],
Validation result:
entry: no file exists at /Users/tema/Dropbox/Projects/_Repos/react-styleguidist/webpack-hot-middleware/client - no file exists at /Users/tema/Dropbox/Projects/_Repos/react-styleguidist/src/index
We just need an enum of acceptable devtool
options
The user should be able to disable validators, for example if they throw false positives and thus cause breakage in CI pipelines, or if the user is knowingly using some edge case for which we emit warnings.
For this we need basic configurability, from the cli side per command line flags or dotfile, or programmatically via an options object passed to the validate function.
A minimal implementation could look like disabledValidators: ['module.loaders', 'resolve']
.
Thoughts?
We had to remove npm-run-all bc of cross platform issues
This bug is fixed and I think it would be a good idea to update the deps & bring npm-run-all back
npm install -g webpack-validator
webpack-validator webpack.config.js
Valid!
Right now we are only console.logging warnings. For CI build processes it would be beneficial if the user could opt in to have webpack-validator throw errors on problems. This way cryptic errors from webpack malconfiguration would be replaced with DX-friendlier errors in CI logs.
The could be implemented by supplying a 'throwErrors': true configuration option to either the CLI interface or to our default export validate function.
Thoughts?
I need help writing validators. Please see CONTRIBUTING.md file to find out how. Also check out configuration-validator documentation to see what a validator looks like.
I really need feedback on the API. Everything's in beta right now so we can mess around with the API as much as we want (rename things, restructure things, etc. etc.).
This tracks the progress of the implementations of all internal validators, meaning those that validate the official webpack configuration properties.
Let's check an item if we have a basic, tested implementation in place.
Important
cache
context
debug
devtool
entry
module
(done in #9)output
resolve
(done in #48)resolveLoader
target
plugins
( #51 )externals
( #52 )node
( #53 )Secondary
amd
bail
devServer
loader
profile
recordsInputPath
recordsOutputPath
recordsPath
stats
(doc)hey, @kentcdodds. This project sounds like an awesome idea.
I recently built a library that helps with property validation in javascript objects. (https://github.com/nettofarah/property-validator)
Maybe we could use it validate the webpack config options?
Here's an idea of how it could look like:
import { validate, assert, optional, presence, isArray } from 'property-validator'
const validationResult = validate(webpackConfig, [
presence('entry'),
optional(isArray('resolve.root')),
isArray('resolve.alias')
...
])
or use assert
this would raise a ValidationError (my preferred option)
assert(webpackConfig, [ ... ])
validation functions are all stateless and are super easy to extend.
All you need to do is to create a function with this signature:
function(paramName) {
return function(params) {
return { valid: true, message: 'bla' }
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.