running kyt dev, I made a change where I referred to a nonexistent export (pseudocode below the stack trace) and the process died with this message:

webpack building...
UNHANDLED EXCEPTION TypeError: logger.warn is not a function
    at Compiler.webpackCompiler.plugin.stats (/path/to/project/node_modules/kyt/utils/webpackCompiler.js:26:14)
    at Compiler.applyPlugins (/path/to/project/node_modules/tapable/lib/Tapable.js:25:14)
    at Watching._done (/path/to/project/node_modules/webpack/lib/Compiler.js:93:17)
    at Watching.<anonymous> (/path/to/project/node_modules/webpack/lib/Compiler.js:76:18)
    at Compiler.emitRecords (/path/to/project/node_modules/webpack/lib/Compiler.js:319:37)
    at Watching.<anonymous> (/path/to/project/node_modules/webpack/lib/Compiler.js:59:19)
    at /path/to/project/node_modules/webpack/lib/Compiler.js:312:11
    at next (/path/to/project/node_modules/tapable/lib/Tapable.js:81:11)
    at /path/to/project/node_modules/assets-webpack-plugin/index.js:82:9
    at /path/to/project/node_modules/assets-webpack-plugin/lib/output/createQueuedWriter.js:15:7

the change was something like this:

// MyComponent.js
+ import { nonexistentExport} from './MyOtherComponent'
...

// MyOtherComponent.js
export { notTheThingIImported }

• Add support For Stylelint
• Add support for copying over initial lint configs

The Travis CI should run lint and test on PRs, and master branch

When we open source we should look into greenkeeper for our updates.

From what I can tell, when kyt setup runs, it copies dependencies but doesn't move everything. This includes the node_modules directories inside of current dependencies, and any files put their by npm link. This causes the test command to fail.

The command actions rely on a userRootPath variable which is usually derived with process.cwd(). This works fine when the user fires off kyt commands from the root of their project but will break if they are further down the directory tree.

We could use something like the following with process.cwd(): https://github.com/jden/find-root . Or just do it ourselves

Felipe reported that they do not.

• Overview & Philosophy
• Setup
• Requirements
• kyt.config options
• Current webpack support list
• webpack config overrides
• babel override example
• CLI - list of tasks and individual definitions
• Prototyping
• Linting
• Testing
• kyt starters - list
• Contributors: dev instructions
• How to build a starter
• Tools List
• FAQ

Starter kyts should configure the version of kyt that they depend on. I think it should go in the package.json and should be checked on setup. If the local kyt version is outside of the specified version then the user should get a warning. The starter kyt package.json configuration could look something like the following:

...
"kyt": {
  "version": "<=0.5.0"
},
...

Similar to #34 it would be useful to be able to optionally disable Server HMR (and only utilize Client HMR) especially when working/focusing on UI code. The Server reloading slows down the feedback loop unnecessarily.

In https://github.com/nytm/wf-kyt/blob/master/config/webpack.base.js#L58
Check to see if NODE_ENV is set and respect the user setting if it is. Otherwise use options.environment.

Right now we're loading the babel presets via the babel CLI. Since were using the webpack loader plugin we should do all preset stuff right from there so it's easier to extend. This is related to a current bug in project vi, tests aren't running because the babel transpile is failing.

Would it make sense to add a command to the global CLI: kyt init which would:

1. Add the kyt commands to package.json scripts
2. Create a src/client/index.js and src/server/index.js (if they don't already exist)
3. Setup the kyt proto boilerplate

For the second item, not sure what the overlap would be with kyt setup.

Thoughts?

Would be nice to also show gzip size along with the assets output:

641.23 KB    (178  KB gzip)   build/client/main-618bbd3a04be91bfc336.js
164.22 KB    (23.5 KB gzip)   build/client/main-3e90752ad5a140255589.css

Can use gzip-size

This newly released Webpack Dashboard could be a good tool for debug or some other mode in kyt. If anything we should check out how they gather and output stats.

https://formidable.com/blog/2016/08/15/introducing-webpack-dashboard/

Not sure what the best way to do this is but if someone uses an environmental kyt config and changed the serverURL then the serverURL displayed during start is incorrect.

See webpack/webpack#2223

Seems to only happen when you shut down Docker. If the fix is to disable the cacheDirectory, I think it has to be done in Kyt? Alternatively, we can probably send it somewhere else, like /tmp, but I don't think that's necessary.

https://github.com/nytm/wf-kyt/blob/495ec6a7ab56fde37aaca1e10254f57b8b553eb6/config/webpack.base.js#L29

The ASSETS_PATH env variable seems to be determined by where kyt dev starts up the client assets server (localhost:3001). This should be configurable so that an app build using kyt can specify where to get its client assets (likely served behind a CDN, with a different protocol/hostname/port).

On build, if the user did not specify a node environment, then we should set it to "production" before exercising webpack.

I think we have to do this so that the dev server handles better when a user doesn't intend to use hot loading. Should we make it optional in the kyt.config.js and default to false?

hotLoader: true

• Remove old files from build/test before running the test command.
• Catch babel errors and report them to the user

Does kyt work on Windows machines? I suspect not, and we should fix that.

To avoid eslintrc naming issues, we should use a flexible naming convention that matches eslint.

https://github.com/nytm/wf-kyt/blob/master/cli/actions/lint.js#L27

Build a generator for pulling down and installing already-made boilerplates for kyt.

The way kyt handles linter configurations isn't ideal. Currently, on setup, we drop the linter rc's into the user's root directory so the user can extend them and use them in editor plugins. Since the linters are no longer packaged, kyt has no way to update those files.

To work around this, I propose we separately package the linter configurations inside of kyt and push them up to npm. That way, on setup, we can continue giving user's extensible linter rc's, but also gain the ability to update rules and dependencies in future releases.

Thoughts?

I'm not a huge fan of aliasing, but it might be helpful to alias the src directory. If we add an alias then we'll probably have to add an eslint plugin so that it doesn't complain about resolving paths.

https://github.com/twolfson/single-child/blob/master/lib/single-child.js#L163

This is causing kyt test to pass in drone, even though tests are not passing.

There's no tests currently, it would be good to test the kyt CLI and some of the contracts with userland (e.g. throwing an error in kyt.config.js will correctly bubble up the error, etc.)

@coolov rightly reported that debug doesn't help much. We should surface Webpack stats and, as @tizmagik suggested, json when debug:true.

• Edit user's package.json to add commands
• Add ava config to user's package.json
• kyt update
• postintstall script to init
• proto command for simple prototyping
• Fix RHL (Jeremy teaches us how this works first)
• Smart Errors

It's popular and I think it's a good base opinion for kyt.

• Eslint override in kyt.config.js
• cdn assets config in kyt.config.js
• Code Comments
• Help Command
• Readme Docs
• change basePath to userRootPath
• command dedupe
• no post install inside kyt
• remove postversion command?
• error handling
• delete unnecessary dependencies
• Versioning / update strategy
• add .gitignore file
• add base kyt.config on setup
• backup prototype.js file when kyt proto runs.

Right now, kyt.config.js can only be written in node v6 supported ES6 (e.g. can't import modules). It would be nice to allow full ES6+ support in the config.

• Make sure installation instructions are updated.
• Make sure all links work when the repo is moved

When @jprobinson tried deploying the new games front-end on a Linux-based GKE instance, it mostly seemed to work: http://104.197.1.89. But while the <script srcs and <link hrefs were all correctly addressed and returning the data in their requests, the Content-Type: text/html header being returned with each response keeps the browser from interpreting them properly. Express or some other layer will apparently need to set these explicitly for compatibility outside an OS X deployment environment.

I don't have specific steps for recreating this but occasionally when I'm developing (with kyt dev) the server fails to restart, saying the port is already in use:

👍  Client build successful
webpack built 7a148d7c5e66a4dae11c in 2544ms
👍  Server build successful
👍  Development server restarted
events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: listen EADDRINUSE :::3000

killing the process seems to release the port again.

(glancing thru other issues - maybe related to #16?)

On kyt setup if the user already has a src directory, we back it up before copying in a new one. Maybe we should try to detect a user src directory at the beginning of setup and when found prompt the user with a confirmation to continue?

A very common pattern is to serve up static assets from a directory like src/public, for things like favicons, etc. This is separate from the current assets config option (for CDN). This public folder would need to be copied over to /build for production deployments.

Ran a snyk scan and found some vulnerabilities

✗ High severity vulnerability found on [email protected]
- desc: Regular Expression Denial of Service
- info: https://snyk.io/vuln/npm:negotiator:20160616
- from: newsreader@null > [email protected] > [email protected] > [email protected]
Upgrade direct dependency [email protected] to [email protected] (triggers upgrades to [email protected] > [email protected])

✗ High severity vulnerability found on [email protected]
- desc: Regular Expression Denial of Service
- info: https://snyk.io/vuln/npm:negotiator:20160616
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
No direct dependency upgrade can address this issue.
Run `snyk wizard` to explore remediation options.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

Tested 967 dependencies for known vulnerabilities, found 2 vulnerabilities, 6 vulnerable paths.

Run `snyk wizard` to address these issues.
Olov-Sundstrom-MBP:newsreader 206124$ snyk test
✗ High severity vulnerability found on [email protected]
- desc: Regular Expression Denial of Service
- info: https://snyk.io/vuln/npm:negotiator:20160616
- from: newsreader@null > [email protected] > [email protected] > [email protected]
Upgrade direct dependency [email protected] to [email protected] (triggers upgrades to [email protected] > [email protected])

✗ High severity vulnerability found on [email protected]
- desc: Regular Expression Denial of Service
- info: https://snyk.io/vuln/npm:negotiator:20160616
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
No direct dependency upgrade can address this issue.
Run `snyk wizard` to explore remediation options.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

✗ High severity vulnerability found on [email protected]
- desc: ReDoS via long string of semicolons
- info: https://snyk.io/vuln/npm:tough-cookie:20160722
- from: newsreader@null > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
Your dependencies are out of date, otherwise you would be using a newer tough-cookie than [email protected].
Try deleting node_modules, reinstalling and running `snyk test` again.
If the problem persists, one of your dependencies may be bundling outdated modules.

I am looking for a way to run --debug=true with docker for project-vi.

Here is how to run the debugger that I would like to run:
https://medium.com/@paul_irish/debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27#.elnqyj305

After firing dev, both Scott and I ran into a silent failure because a server port was in use. I tried wrapping some of the functionality in dev.js in try-catches but I couldn't catch it.

Fix me!

It's common to use different settings in different environments. Should we add an optional command line argument to build to tell kyt which config to use on startup? Something like the following:

kyt build -c kyt.stage.config.js

My guess is that this use case will come up very soon as Adam sets up our environments.

Your JS looks good ✨

• Make the version for some package.json dependencies static and delete unnecessary dependencies
• Cleanup starter-kyts
• logo
• readme
• lint kyt code
• delete unnecessary dependencies
• Finish up Docs
• Testing

• Investigate transpiling node code requirements

The hot loader doesn't work when kyt is globally installed or npm linked. An error appears in the browser console and the page is forced to reload. Fix it.

Figure out how to do it and document it.