Demo: Add Ability to Configure Rules

[xjamundx]

Currently there is no way to configure rules in the demo.

I'd like to add the ability to read .eslintrc files directly and for them to update the rule-set as well as the ability to configure rules.

There are several possible UI treatments, I'd love feedback on the best way before I move forward.

My current thought is to just have a file-upload box that will update the configuration.

And instead of a checkbox everything will become an input box. This is buggy, but easier than the alternative which is schema checking.

[ilyavolodin]

Umm... That would make uploading .eslintrc a primary use case of the demo. And playing with different rules distant and very inconvenient second. I think if you already have .eslintrc file, you probably have eslint installed and can test out your changes locally. I think primary use case for the demo is exploring eslint and finding out more about rules.
Something like this is what I was thinking of: https://github.com/joshfire/jsonform
Or this: https://www.npmjs.com/package/json-schema-form-js

[xjamundx]

I think we can accommodate both use cases :)
On Mon, Sep 7, 2015 at 8:01 AM Ilya Volodin [email protected]
wrote:

Umm... That would make uploading .eslintrc a primary use case of the demo.
And playing with different rules distant and very inconvenient second. I
think if you already have .eslintrc file, you probably have eslint
installed and can test out your changes locally. I think primary use case
for the demo is exploring eslint and finding out more about rules.
Something like this is what I was thinking of:
https://github.com/joshfire/jsonform

—
Reply to this email directly or view it on GitHub
#139 (comment)
.

[ilyavolodin]

Sorry, I was talking mostly about your suggestion about input boxes for rules. I don't think that will cut it.

[xjamundx]

working on something like this....when you click on the arrow you will be able to configure the rule....hmm the arrows are probably flipped. anyway. i'll show you when it's bit further along :)

[ilyavolodin]

Sounds good. I tried playing with the libraries I linked above, but couldn't make them accept our json schema, would be interested to see what you did.

[xjamundx]

@ilyavolodin I'm considering a full react-based re-write. any interest?

[ilyavolodin]

@xjamundx We were just talking about this yesterday on Gitter with @kaicataldo Yes, that's my plan as well. I was planning on starting it this weekend and then @kaicataldo will jump in to help. Neither of us dealt with React yet, so we wanted to use this as a learning exercise.

[xjamundx]

Okay let me know if you get stuck on anything. I'd prefer if this things:

1. Was built on webpack instead of require.js + browserify
2. Had its own build system (/ possibly separately deployable)
3. Worked with plugins :)

[kaicataldo]

Excited to learn about React :) And any help/insight is very welcome on my end!

[ilyavolodin]

@xjamundx In ideal scenario, I would prefer that too, but since eslint is compiled in one repository and demo is in another, I don't think webpack would work in that case. Also, having it's own build system - yes, but we don't want to require a built with every eslint release. Right now release management is more or less just copy files over, and check them into website repository. Adding a build step might make it a lot harder.

[mysticatea]

Everyone is thinking the same thing :D
I was also thinking it.
Though I'm very busy recently....

[nzakas]

Yes, please do not require a build step during the release. I'm not a huge fan of React due to all the hoops you have to jump through to get it deployed. I also think it's overkill for this particular use case, but as long as the release won't require anything more than copying files and you document absolutely everything about building and deploying, I'll keep my mouth shut.

My other concern is that this will require us to check in both the source files (JSX) and the built files. Needing to keep those in sync seems like a recipe for trouble.

[pedrottimark]

Using React.createElement instead of JSX notation might solve the double-check-in problem?

http://facebook.github.io/react/blog/2015/12/18/react-components-elements-and-instances.html

[ilyavolodin]

@pedrottimark no build step means you can't use ES6 either. And it's tough to find examples of React code without ES6 and JSX. I don't think there's a huge issue with keeping compiled and source in-sync. We'll add compile script as part of the client-side build, so whenever you make changes to the source, you compile and check-in both compiled and source. I'm also planning to do the same thing with Bootstrap as well.
I think we can avoid any build steps on check-in by using dependency loader (RequireJS or whatever else is available). This way, all we have to do is just drop compiled version of ESLint into the website repository and require it in.
@nzakas In general, I agree with you, React brings in a huge bucket of dependencies and steps, but I think we need something to structure the code of the demo. I know you view demo is just a way for people to have a quick look at what's available, but I really think we should provide a full picture. That means ability to configure rules beyond on/off. Maybe even load plugins somehow (that's a stretch goal, not planning on it for now). And in all honesty, React is a go-to framework for frontend now, especially among ESLint users (I think). So it would be easier to get outside contributions with known framework.

[btmills]

I threw up a quick demo comparing ES5 vs ES6 React at btmills/es5-react-demo. Realistically, the demo shouldn't* need to many unique components. I think it would be a reasonable choice to start without any sort of build step and see how far that gets before adding one.

*Famous last words.

[nzakas]

@ilyavolodin I'd just like to point out that there are many ways to create structure in a project, and React is just one of them. :) I really don't feel like arguing, I just feel like this conversation escalated way too quickly to, "and we'll rewrite the whole thing in React!" without any real discussion of the pros and cons. I've seen this happen way too frequently with projects and I'm not a fan of that sort of reactive approach (no pun intended) to improving something.

For instance, even though I think React is silly for this demo, why not try some React on just one part of the page first before rewriting the whole thing? I mean, we're still going to use the rich text editor to get all the hooks and such, so it's not even like everything would be in React. Why not just try it on the part that shows the error messages first to get a handle on whether or not ES5 without JSX gets the job done and whether we can live without a build system?

[hzoo]

If we don't want to setup a build system we can include babel-browser (or babel-standalone) which will do it on the fly which is fine for a demo.

<script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.23/browser.min.js"></script>`
<script type="text/babel" src="src/file.js"></script>

Otherwise webpack, etc

[nzakas]

I had another idea last night while I was thinking about this. Let's say, for fun, that we want the demo to become a more formal web application that has a build step and then a deployment step. That would mean, necessarily, that we should also have tests for the code (because it's now more complicated) that we should run on pull requests and deploy. I think at that point, we need to completely separate the demo from this site. Here's what I envision that could look like:

1. We setup demo.eslint.org as the new home for the demo (I think we can get rid of the Espree demo and just point people to astexplorer.net).
2. We create a demo.eslint.org repo to manage the project but do not use GitHub pages to publish it (so we don't have to worry about double checkins, this would just be for source control).
3. We can use one of the DigitalOcean VMs to host demo.eslint.org.
4. We can use Jenkins to build and deploy to the VM

So basically, it becomes a full-fledged web application and then we can pretty much do anything we want.

[xjamundx]

Yes basically that was what I was trying to suggest originally. I'd already built a totally separate webpack version at one point and had to revert to require.js-ness. I think just making it its own thing would be super nice and I'm happy to help however!

[ilyavolodin]

@nzakas Now who is jumping too far?:-) I'm not opposed to the idea, but I would want to see if we can get the demo to work in the current repository without build/deploy steps first. Or with only client-side build step.

[kaicataldo]

I really like that idea. I was particularly excited about using the project as a way to start learning React, but whatever is best for the project and the users is obviously more important and I'm happy to help however I can!

[nzakas]

@ilyavolodin I'm just hopping on the crazy train. :) If we're going to treat it like its own application, then let's take it all the way and make it it's own application. I'm not saying I love the idea, but I'd much rather do that than try to hack it into how we've been doing it so far. Doing this halfway is much more perilous that doing it all the way.

I'd personally prefer a more incremental approach, but if that's not where everyone is headed, then I'd just like to do this the right way instead of risking the part that currently works great for our needs.

[ilyavolodin]

I created a WIP PR #235 for no-build-required approach for rewriting the demo. @nzakas I think that would work pretty well with our existing release scripts, since it doesn't need any type of build or deployment. Let me know if this is reasonable approach, or we still want to turn it into a full fledged application and deploy it separately to DigitalOcean.

@kaicataldo Feel free to jump in with PRs to my branch.