formidablelabs / formidable-react-component-boilerplate Goto Github PK

I don't think it currently works for analogous reasons to FormidableLabs/radium#282

/cc @boygirl

Some discussion has happened around this already, but the gist is that we have builder and builder-react-component in dependencies. And most of our current repos, which are pre-Builder, have babel and webpack in their production dependencies. This not only makes installing our stuff extra slow, but I've found that we're more likely to experience version conflicts or the need to completely wipe node_modules just to upgrade or install a new dependency (some tools in the Karma and webpack ecosystem declare peerDependencies that end up getting mad that all our components have webpack as a production dep).

When transpiling with Babel, nearly all the projects I've surveyed do their build in version or prepublish. But that means they don't support git install URLs, because the build artifacts are only present in the NPM package. To support git URLs, we landed on a solution of conditionally building in postinstall. The problem is that even though the build is conditional, the build dependencies like Babel and Webpack are not: everyone installing through NPM has to bear the cost of installing those, too, no matter what. Not to mention that on principle, they just aren't true deps: they aren't require'd anywhere in the package. They're build dependencies!

I'd prefer to align ourselves with what everyone else is doing: building in version or prepublish. Here are a couple options:

1. Drop our postinstall method and just don't support git URLs. @coopy says they're an antipattern and that the NPM folks recommend publishing under a scoped package name if you need to depend on a fork. Another option would be to check lib into the repo in a branch of your fork, just for the purpose of being git installable.
2. Use a smarter postinstall that not only builds conditionally, but installs dev dependencies temporarily only when a build is needed. That way the common case of installing via NPM, which already has the build artifacts, never even pulls down the build deps. To test how this would work, I made a helper for exactly this purpose: postinstall-build

As for Bower, I don't know how it works or why our current method is required to support it, so I'll let someone else explain. But I also don't give a hoot about Bower.

• Hook up Coveralls account
• Add to Travis YML
• Track that coverage is generated by
  • Client
  • Server
  • Func

Basically like: https://github.com/FormidableLabs/full-stack-testing/blob/master/.travis.yml#L29-L33

  # Manually send coverage reports to coveralls.
  # - Aggregate client results
  # - Single server and func test results
  - ls coverage/client/*/lcov.info coverage/{server,func}/lcov.info | cat
  - cat coverage/client/*/lcov.info coverage/{server,func}/lcov.info | node_modules/.bin/coveralls || echo "Coveralls upload failed"

The current repo will fail to build for a npm install --production. In conjunction with #4 , we should correctly audit what should be in dependencies (e.g., add webpack) and devDependencies.

BUG: Karma 0.13 is broken for circular imports. This works: "karma": "^0.12.37",

• codymikol/karma-webpack#62
• karma-runner/karma#1497

Right now we are publishing the npm module with the demo but without webpack-dev-server

These have been nothing but a problem in most our component repos including Radium.

Task: Remove https://github.com/FormidableLabs/formidable-react-component-boilerplate/blob/master/package.json#L8-L10

When including a component built from this boilerplate in another component built from this boilerplate the following isn't working

import {VictoryThing} from "victory-thing";

Right now anyone using this boilerplate has to change the boilerplate-component to their component name in the src/components/boilerplate-component.jsx, src/index.js, webpack.config.js, and webpack.config.dev.js. Ideally this could be stored in a config file that is written by the generator so that none of this is necessary.

I see that this is made with a yeoman generator, not a builder-init template. Any reason to use a yo generator instead of a builder template?

Review https://github.com/FormidableLabs/converter-react/blob/master/webpack.config.js and our other webpack production configs and take care of various things:

• Production mode for React
• Add .jsx support.

React supports down to IE8 and our components should.

TASK: Make the demo compliant to IE8 with polyfills, etc. following https://facebook.github.io/react/docs/working-with-the-browser.html#browser-support-and-polyfills

See https://travis-ci.org/FormidableLabs/formidable-react-component-boilerplate/jobs/87699535

• /home/travis/build/FormidableLabs/formidable-react-component-boilerplate/node_modules/builder-react-component/node_modules/webpack-dev-server/node_modules/socket.io/node_modules/engine.io/node_modules/ws/node_modules/utf-8-validate/build
• /home/travis/build/FormidableLabs/formidable-react-component-boilerplate/node_modules/builder-react-component/node_modules/webpack-dev-server/node_modules/socket.io/node_modules/engine.io/node_modules/ws/node_modules/bufferutil

Looks like some problem with:

../node_modules/nan/nan_converters_43_inl.h:24:1: error: ‘return_t’ in ‘struct Nan::imp::ToFactory<v8::Int32>’ does not name a type

webpack hot server doesn't shutdown gracefully causing EADDRINUSE errors

Maybe, maybe not (?) (Would be nice to get base validation that you can import into node-land).

• Coverage.
• Travis CI.

IMPACT: Control comments like /*global document:false*/ don't work to make eslint happy.

This just randomly happened in build: https://travis-ci.org/FormidableLabs/formidable-react-component-boilerplate/builds/71981956

for a non code change. Nuking node_modules locally and re-installing reproduces the error. This means likely some underlying module is not properly implementing semver / has a new bug.

 $ eslint --ext .js,.jsx -c .eslintrc-react src demo/*.jsx

demo/app.jsx
  15:16  error  "document" is not defined  no-undef

✖ 1 problem (1 error, 0 warnings)

Gulp is a huge dependency that we don't need. Instead, just use package.json commands to do our core:

• Karma
• Webpack
• Lint

commands

• Source map build
• Hashed name

TODO when FormidableLabs/builder-react-component#4 is resolved.

• Tests in browser.
• Coverage.
• Travis CI.
• RAF Polyfill: http://paulirish.com/2011/requestanimationframe-for-smart-animating/, http://my.opera.com/emoller/blog/2011/12/20/requestanimationframe-for-smart-er-animating, https://github.com/FormidableLabs/formidable-react-component-boilerplate/blob/ecc1d199d19122ea574ecad935b16481e1b05478/test/helpers/raf-polyfill.js
• Function.prototype.bind https://github.com/FormidableLabs/formidable-react-component-boilerplate/blob/ecc1d199d19122ea574ecad935b16481e1b05478/test/helpers/phantomjs-shims.js

With a fresh Node v4 or v0.12 installation from nvm, but with npm@2 installed instead of npm@3, an npm install of a module that depends on a module using our new postinstall workflow will fail:

$ git clone [email protected]:FormidableLabs/victory-bar.git
$ cd victory-bar
$ npm install

...fails with this output:

<snip irrelevant peerDependencies complaints>

> [email protected] postinstall /Users/brianbeck/Projects/Formidable/victory-bar/node_modules/victory-animation
> npm run build-lib

|
> [email protected] build-lib /Users/brianbeck/Projects/Formidable/victory-bar/node_modules/victory-animation
> npm run clean-lib && babel --stage 0 src -d lib

\
> [email protected] clean-lib /Users/brianbeck/Projects/Formidable/victory-bar/node_modules/victory-animation
> rimraf lib

sh: rimraf: command not found

<snip npm's ridiculous error epilogue>

The gist is that postinstall is running either before the dependencies (like rimraf) are installed, or just without access to them somehow.

Replace existing publish scripts and README language.

• Follow Radium's "in source" + publishing strategy.
• Update package.json script
• Update docs.

w/ Rowdy + WebdriverIO

• Decide on automation ID strategy.
• Coverage.
• Travis CI.

https://github.com/iarna/in-publish

Problem: Already lose stack traces because part of a test bundle. Will get worse with coverage enabled.

Possible solutions:

• https://github.com/novocaine/sourcemapped-stacktrace (Remap error stacks manually).

currently package.json points to lib/index.js, but when installing generated packages via npm errors occur, and are resolved by changing lib/index.js to dist/package-name.js