Reduce the number of commands

[chenglou]

@sdawson don't start this yet, we'll determine the folder structure first.

There are way too many for the scope of the tasks we can accomplish. I had a local branch that had 3 commands and it fit most use cases really well. For example, a "not watching" option wouldn't be necessary.

[petehunt]

How about we do these?

npm start runs a react-page dev server npm run lint runs jsxhint npm test

and we would have prepublish scripts that do the jsx build.

[chenglou]

In that branch I had, npm start runs beefy like the old version. So far it's been fine and the boilerplate's hidden. I really love the auto refreshing. I'm not sure about depending on react-page so quickly, tbh I haven't tracked its progress since a while. But since we're also targeting react-library toward those who develop stuff bigger than small components (are we still?), I'm open to this once I finish the basic functionalities.

npm test, of course.

npm run lint, I'm not so sure. I kinda want to group it inside npm test. One thing I haven't said is that, once we get the component site rolling, it'd be neat if we indicate that the single npm test is actually the "minimum entry bar" for accepting a user component. See it as a Component Store where you know what you're evaluated on lol. If the lint doesn't pass, I'd rather consider this as an error. I guess you could say this promotes better sharing, blabla. What do you think?

The third and last command I had was actually browserify .... Beefy covers this, but at the end you'll still have to bundle your stuff at the top. Or, if we really consider this repo as being focused on rapidly testing and sharing components, I'm willing to drop this. Since you can use whatever you want at the end, maybe even react-page separately. In the future, I'll swallow my shame and do what beefy does and use the live reload script directly... This way, browserify and npm start would totally overlap and we'll have one less command.

[petehunt]

I think the auto-refreshing is kind of cool but not a deal breaker. I've been developing a few things with it and you definitely notice the JS bundle and load time. react-page has a crazy fast bundler and uses server rendering so the dev experience is much better. We can stick with beefy for now but I think we should revisit this.

Since I think we should revisit this in the future, instead of the standard entrypoint.js which calls renderComponent(), how about it just exports a React component class that whatever system we use to run it will instantiate?

As long as we include linting that's fine with me -- but we really should have a way to only run lint or only run a single test so devs don't have to wait as long to iterate.

I am kinda torn on browserify but I don't think we need it. You can just run browserify on your package yourself.

[chenglou]

Ok you just made me change my opinion lol. Yeah beefy is slow and kills the feeling. I'll check react-page once I'm done! About entrypoint.js, that's what I actually did. As for linking, maybe...? If your react-library component gets so big that tinting and testing (watched of course) takes a significant amount of time then... About browserify: ok.

[petehunt]

I think that we should have the mentality that full apps are just big React components, so I think it's important that we get this right. This doesn't mean npm test shouldn't do it -- we could just give people instructions in the README for how to run jasmine or mocha or whatever manually.

[chenglou]

Alright makes sense.