gaearon / library-boilerplate

An opinionated boilerplate for React libraries including ESLint, Mocha, Babel, Webpack and an example powered by Webpack Dev Server and React Hot Loader

library-boilerplate

An opinionated setup I plan to use for my libraries.

It has CommonJS and UMD builds via Babel and Webpack, ESLint, and Mocha.
It also has React-friendly examples folder with library code mapped to the sources.

If you use this, make sure to grep for “library-boilerplate” and replace every occurrence. See package.json in the root and the example folder for the list of the available commands.

Note that this is an opinionated boilerplate. You might want to:

• Set stage to 2 in .babelrc so you don’t depend on language features that might be gone tomorrow;
• Remove loose: ["all"] from .babelrc so the behavior is spec-compliant.

You have been warned.

library-boilerplate's Issues

Consider using an ESLint template

Hello @gaearon! First, I should say thank you for all the amazing stuff you've been putting out lately! Also, since I am a Changelog listener I heard about your new position so congrats on that too. London is a great city.

tl;dr - you should consider using an eslint configuration instead of introducing your own into the world. I am partial to https://github.com/walmartlabs/eslint-config-defaults since I am the maintainer but there are many other excellent ones out there.

---

Why do I care? - Over the past two years I have been working in a small group overseeing the development of a number of very large web applications. As the projects grow, engineers from all different background began to contribute. Jr. folks right out of college, Java lifers who are trying to learn FP concepts while adapting to new semantics, ops folks etc. In the end what I've come to understand is that being a beginner is really freaking hard. Especially in client side JS.

So, with that in mind I'm trying in a large number of small ways to make good tools and resources available to people who need them most. I think ESLint is one of those exceptional tools but it's config is not easy to read, not easy to manage and is kinda a pain in the butt to get set up. This is especially true as of 1.x since all rules are now off by default. eslint-config-defaults and other sharable configs are an attempt to make it quick and easy to get good tools up and running and I'd like to ask if you'd consider pulling one into your project in an attempt to spread the good word.

babel-eslint is outdated and fails to run with latest npm/node

I had to update babel-eslint to 4.1.7 to make npm run lint working.

Setting NODE_ENV cross platform....

I was going to recommend Envify to set Environment variables in the npm scripts, but found a solution:

remy/nodemon#184 (comment)

Works in Windows!

Debugging mocha tests written in ES6

I tried out the setup for mocha + ES6 tests in this repo on El Capitan and running my ES6 mocha tests works just fine. However I'm having trouble debugging ES6 tests with node-inspector and Chrome. I use mocha's --debug-brk option to launch the test to be debugged and then set a breakpoint in the ES6 file. However, Chrome does not pick up the breakpoint.

I thought that babel-register adds and inline sourcemap to the transpiled file and that Chrome debugger would pick that up. But it does not.

Any pointers on how to get debugging for ES6 mocha tests up and running?

Consider adding editorconfig file

http://editorconfig.org/

Why name the script `build` instead of `compile`?

Hey friends! Just a little question/curiosity.

In a lot of babel/coffee modules I see, people name a "build" script in their package.json, just like this boilerplate does, but I've got an issue with that and I'm wondering if I'm just being dense:

npm build is a built-in npm command that builds the package for npm link & npm install. Just calling npm build and expecting it to fall through to the package's "build" script (like one would npm test) creates the false impression that things were just compiled, because that command will almost always run silently and exit code 0.

Because of the potential confusion when mistyping npm build instead of npm run build (and for the fact those two things do different things when npm start|test and npm run start|test do the same thing), it seems to me to be prudent to establish the convention of naming the build script "compile" or some other thing instead, so that npm compile fails loudly when mistyped.

Thoughts?

npm run test fails on Windows

I had to change the script as following "test": "set NODE_ENV=test && mocha".

RFC: Add support for `eslint-plugin-compat`

This eslint plugin lints against APIs that are only supported by target browsers 🎉 Would a PR for this be welcome?

Here's a demo of it in action