cloverfield-tools/cloverfield

What tech should we use?

Closed this issue · 13 comments

ericelliott commented

ES 2015 (was ES6)

Since this is a next-gen tool, I think it makes sense to write it with next-gen JavaScript. We'll use ES6 + babel. To contribute, you'll want to make sure you're set up to compile ES6 on Node:

$ npm install -g babel

We'll use ESLint for our modern linting needs. =)

Libs

What else should we consider?

emenoh commented

I don't have any an opinion on libraries but here's my list of needs.

  • Directory watch for changes to do stuff. Vanilla use case is reloading url, more complicated is compiling stuff and then reloading url... etc.
  • CSS preprocessing/linting
  • JS lint (you've got ESLint mentioned)
  • Assuming ES6 it doesn't need a module loader/compiler but package manager and dependency manager is still useful
  • Testing
  • Mock data (use with testing)
  • Environment (dev vs. stage vs prod)
  • A route abstraction would be nice, not implementation specific
  • i18n support for multiple languages, pluralisms, word folding (synonyms, etc)
  • DB/Schema abstraction might be nice
  • Search abstraction might be nice
  • Deploy/bundling
  • Security tool (included in linter?)

oh and Underscore.js

emenoh commented

More

  • Mobile gestures like Hammer.js
  • Probably some kind of animation library like Greensock or Famo.us
  • Probably some kind of DOM/Shadow DOM/Virtual DOM or at least an abstraction that will hook in to it, so something like a chained selector library e.g. Jqueryish
ericelliott commented

Great checklist, thanks!

mattdesl commented

My thoughts working with many modules:

  • node / npm / modularization are the biggest selling points of modern JS
  • module creation/maintenance really could benefit from tooling and automation
  • Gulp/Grunt is often overkill for many projects and modules. Including them in a scaffolding tool adds complexity, larger API surface area, and goes against separation of concerns & modularity. Same goes for monolithic Karma/Mocha/etc tools.

Here's what I want in tooling. This is more specific to modules than "big apps" so it may be outside the scope of Cloverfield.

  • a way to stub out a new module (I'm currently using this)
  • less prompts, more command line flags. The prompts should be stuff like "module description" rather than "Which of these obscure and application-specific dependencies do you want to install?" (which of course the answer is almost always "None")
  • a way to "snapshot" a folder or GitHub repo of templates and alias it to a certain name. So I can snapshot mattdesl/tape-file-stub test and then stub test to generate a test file. Or stub threejs-module for a new module that is slightly more specific to ThreeJS. These are personalized to my style rather than using some random syntax/indentation/structure, and I don't need to read a novel to figure out how to build a new generator/template
  • take inspiration from these maintenence-modules and work with the "Unix philosophy" in mind rather than trying to cover all possible features under a single roof

EDIT: BTW, I went a little off-topic there.

Back to the original question. Is this "tech used in Cloverfield" or "tech exposed by Cloverfield"?

If we're talking tech exposed; I think if you start listing things out then you will inevitably end up as "another Yeoman" after a few months. Oh, it uses Browserify instead of Webpack... or Psshh RxJS was so last month, it's all about Bacon.js now!

ericelliott commented

less prompts, more command line flags. The prompts should be stuff like "module description" rather than "Which of these obscure and application-specific dependencies do you want to install?" (which of course the answer is almost always "None")

Yeah, I think the right approach is to offer both. If we have enough info to run a valid action, just run it without the options. If there are required fields missing, prompt for those required fields interactively. For every option available, make sure there's a CLI command to invoke them.

That way, if you forget the requirements for a command, you can just try to run it without, and you'll be reminded what the options are and prompted for the required options. I've seen something that works a lot like that, and it presented the smoothest CLI I've ever worked with. =)

a way to "snapshot" a folder or GitHub repo of templates and alias it to a certain name

Great idea! =)

There are some great resources in that maintenance-modules list. Thanks for the link!

ericelliott commented

@mattdesl posted in the task running thread:

standard for config-less style linting
testling or smokestack for running TAP in a browser

I like the idea of config-less style linting, but that "standard" is really promoting an alternative, semi-colon free style which is far from idiomatic, and lacks some of the checks I'd normally want to enforce, so while I love the idea of a standard config-free lint, that's not the one I'd pick. I'm currently experimenting with an eslint config that I'll offer as an option. If people want "standard", they can manually install it.

I'm not going to shove semi-colon free style down people's throats, considering that it has been a hotly debated topic.

I'm definitely down with promoting a semi-colon free ESLint config, so maybe the only choice people will have to make is "with semicolons" or "without semicolons". We can start by defaulting to "with" and change the default to "without" after we've really put the lint tool through its paces and see how well it holds up in the wild under production stress tests.

I'm definitely down with testling or smokestack for unit tests in the browser, but for GUI web-apps that lots of people produce, we also need real functional tests that we can run on platforms like Sauce Labs.

Testing is such a deep topic we have a thread dedicated to it

kitten commented

My ideas to what I'd like to see in a next-gen scaffolding generator:

  • Immutable.js (It's just SO good)
  • Jest for Testing
  • Optionally SASS (Preferably Bourbon instead of Compass)
  • Gulp (Modularised gulpfile to keep it simple)
  • React.js + Flux architecture (controversial, isn't it?)
  • Browserify or Webpack
  • +1 ESLint, Babel
joeybaker commented

I'd shy away from forcing specific tech that doesn't have to do with "code standards". IMHO good tech to standardize on:

  • linter
  • test runners
  • changelog generator
  • release manager

FWIW, here's my current setup: https://github.com/joeybaker/generator-iojs

Notable things that I think are important for js projects:

  • auto-creates a package.json
  • auto-creates and keeps your .npmignore file up-to-date
  • auto-creates a CONTRIBUTING.md
  • auto-creates a LICENSE
  • auto-creates a README.md with a template that you can fill in, and has a table of contents that will be kept up-to-date on git commit
  • auto-creates a .travis.yml for easy CI
  • tests are auto setup and can test both server and browser code
  • auto-runs tests and linters before a git push, to ensure you can never push bad code
  • auto-runs the Node Security Project advisory list against installed node modules before a git push to make sure your project is always secure
  • adds a release script to automate the headache of releasing a new version. It auto-generates a changelog, runs the tests, bumps the version, pushes to github, and publishes to npm.
ericelliott commented

@joeybaker Awesome contribution, thank you!

joeybaker commented

@ericelliott my pleasure! FWIW, I really like what my template gives me, I just dislike using yeoman. I'd be happy to help here if the goal is to have a yeoman-- :)

ericelliott commented

@philplckthun

We almost certainly will have generators for dealing with tests, styles, and compiling for cross-browser and Node isomorphic code from ES6.

We probably don't need a generator specifically for Immutable.js or Flux, but we're already hard at work on a boilerplate for an isomorphic app using Express and React.

It will not use Flux for data. Instead, it will use object-list which in turn will depend on Immutable.js and RxJS for under-the-hood implementation.

The advantage of using object-list is that you'll be able to back it using an in-memory Array-based db (currently working), a Siren-Resource endpoint (in progress), MongoDB, Redis, etc...

In other words, a single interface to work with all kinds of data sources, that you can plug directly into React. It's immutable, and whenever possible will rely on lazy evaluation for maximally efficient object queries.

One of the inspirations for object-list was Meteor's "database everywhere" mantra for isomorphic data management. We believe we can take that a step further: "data everywhere", and that data can come from anywhere, too. Server Sent Event streams, browser events, Socket connections, JSON API's, etc...

Why not manage it all with a single, very capable API? One that's lean and modular enough to send the minimum code necessary for your app to work in the browser (mobile-friendly).

Anyway, the details of all that are way beyond the scope of this project.

Cloverfield is just a simple scaffolding / CLI utility belt for JS projects. It doesn't need to worry about any of that stuff. ;)

bengarnett commented

Only addition i didn't see above is proxying (local dev pointed at mocks or external server api)

lewiscowper commented

I think an important tool to take into consideration is semantic-release by @boennemann.