gaearon / library-boilerplate Goto Github PK

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

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?

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?

http://editorconfig.org/

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.

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!

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

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