kentcdodds / webpack-validator-deprecated Goto Github PK

From @sokra on gitter:

@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:

npm-debug.log.txt

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:

• Look in 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.
• Maybe also look if packages of the form ...-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.
• Additionally, maintain a mapping of webpack configs toplevel property names to required webpack-validator-plugin packages. If such a top level key is used, the user sees a warning/hint to npm install the matching package. Installing it will be the only required step for this package to be then actually used.
• For integration testing, 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'}
    ]
  },

We need Travis to npm run validate.

Blockers:

• #35 for node compat

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?

Starter issue

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 :)

🐛 The Problem

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:

• Claim this issue (claimed by @miguelc1221)
• Follow setup instructions in CONTRIBUTING.md. This course might also be helpful to answer some questions that might arise. :)
• When you're set up, start by adding the needed dependency: npm install --save path-parse
• Open the file 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).
• Commit and push changes to your branch. It doesn't have to be perfect, if tests don't pass, use the git flag --no-verify on your git commit and push to ask for help.
• You are done 👏. Comment below that your pull request is ready for review.

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

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' }
  }
}