Those of you upgrading npm to its latest version, npm@5.2.0, might notice that it installs a new binary alongside the usual npm: npx.

npx is a tool intended to help round out the experience of using packages from the npm registry — the same way npm makes it super easy to install and manage dependencies hosted on the registry, npx makes it easy to use CLI tools and other executables hosted on the registry. It greatly simplifies a number of things that, until now, required a bit of ceremony to do with plain npm:

Using locally-installed tools without npm run-script

For the past couple of years, the npm ecosystem has been moving more and more towards installing tools as project-local devDependencies, instead of requiring users to install them globally. This means that tools like mocha, grunt, and bower, which were once primarily installed globally on a system, can now have their versions managed on a per-project basis. It also means that all you need to do to get an npm-based project up and running is to make sure you have node+npm on your system, clone the git repo, and do npm it to run install and test. Since npm run-script adds local binaries to path, this works just fine!

The downside is that this gives you no fast/convenient way to invoke local binaries interactively. There’s several ways to do this, and they all have some annoyance to them: you can add those tools to your scripts, but then you need to remember to pass arguments through using --, you can do shell tricks like alias npmx=PATH=$(npm bin):$PATH, or you can just path manually to them with ./node_modules/.bin/mocha. These all work, but none are quite ideal.

npx gives you what I think is the best solution: $ npx mocha is all you need to do to use your local installation. If you go an extra step and configure the shell auto-fallback (more on this below), then $ mocha inside a project directory will do the trick for you!

For bonus points, npx has basically no overhead if invoking an already-installed binary — it’s clever enough to load the code for the tool directly into the current running node process! This is about as fast as this sort of thing gets, and makes it a perfectly acceptable tool for scripting.

Executing one-off commands

Have you ever run into a situation where you want to try some CLI tool, but it’s annoying to have to install a global just to run it once? npx is great for that, too. Calling npx <command> when <command> isn’t already in your $PATH will automatically install a package with that name from the npm registry for you, and invoke it. When it’s done, the installed package won’t be anywhere in your globals, so you won’t have to worry about pollution in the long-term.

This feature is ideal for things like generators, too. Tools like yeoman or create-react-app only ever get called once in a blue moon. By the time you run them again, they’ll already be far out of date, so you end up having to run an install every time you want to use them anyway.

As a tool maintainer, I like this feature a lot because it means I can just put $ npx my-tool into the README.md instructions, instead of trying to get people over the hurdle of actually installing it. To be frank, saying “oh just copy-paste this one commands, it’s zero commitment” is more palatable to users who are unsure about whether to use a tool or not.

Here’s some other fun packages that you might want to try using with npx: happy-birthday, benny-hill, workin-hard, cowsay, yo, create-react-app, npm-check. There’s even an entire awesome-npx repo! Go ahead! A command to get a full-fledged local REST server running is small enough to fit in a tweet.

Run commands with different Node.js versions

As it turns out, there’s this cool package by Aria Stewart called node on the npm registry. This means that you can very easily try out node commands using different node versions, without having to use a version manager like nvm, nave, or n. All you need is a stock npm@5.2.0 installation!

The -p option for npx allows you to specify packages to install and add to the running $PATH, so it means you can do fun things such as: $ npx -p node@6 npm it to install and test your current npm package as if you were running node@6 globally. I use this all the time myself — and even recently had to use it a lot with one project, due to one of my testing libraries breaking under node@8. It’s been a real life-saver, and I’ve found it much easier to use for this sort of use-case than version managers, which I always somehow find a way to break or misconfigure.

Developing npm run-scripts interactively

A lot of npm users these days take advantage of the really cool run-script feature. Not only do they arrange your $PATH such that local binaries are accessible, but they also add a whole slew of environment variables that you can access in those scripts! You can see what these extra variables are with $ npm run env | grep npm_.

This can make it tricky to develop and test out run scripts — and it means that even with tricks like $(npm bin)/some-bin, you still won’t have access to those magical env vars while working interactively.

But wait! npx has yet another trick up its sleeve: when you use the -c option, the script written inside the string argument will have full access to the same env variables as a regular run script! You can even use pipes and multiple commands with a single npx invocation!

Share gist-based scripts with friends and loved ones!

It’s become pretty common to use gist.github.com to share all sorts of utility scripts, instead of setting up entire git repos, releasing new tools, etc.

With npx, you can take it a step further: since npx accepts any specifier that npm itself does, you can create a gist that people can invoke directly, with a single command!

Try it out yourself with https://gist.github.com/zkat/4bc19503fe9e9309e2bfaa2c58074d32!

Note: Stay safe out there! Always make sure to read through gists when executing them like this, much like you would when running .sh scripts!

Bonus Round: shell auto-fallback

This awesome feature, added by Félix Saparelli, means that for many of these use cases, you never even need to call npx directly! The main difference between regular npx usage and the fallback is that the fallback doesn’t install new packages unless you use the pkg@version syntax: a safety net against potentially-dangerous typosquatting.

Setting up the auto-fallback is straightforward: look in the npx documentation for the command to use for your current shell, add it to .bashrc / .zshrc / .fishrc, then restart your shell (or use source or some other mechanism to refresh the shell).

Now, you can do things like $ standard@8 --version to try out different versions of things, and if you’re inside an npm project, $ mocha will automatically fall back to the locally-installed version of mocha, provided it’s not already installed globally.

Do It Live!

You can get npx now by installing npm@5.2.0 or later — or, if you don’t want to use npm, you can install the standalone version of npx! It’s totally compatible with other package managers, since any npm usage is only done for internal operations. Oh, and it’s available in 10 different languages, thanks to contributions by a bunch of early adopters from all over the world, with --help and all system messages translated and automatically available based on system locale! There’s also an awesome-npx repo with examples of things that work great with npx!

Do you have a favorite feature? Have you already been using it? If you have something cool to show off that I didn’t list here, share it in the comments! I’d love to hear what other people are up to!

p.s. people keep asking this so I’m just gonna pop it in here: In these gifs, I’m using Hyper with the monokai theme running oh-my-zsh’s spaceship theme, plus the FiraCode font.

But not every non-binary person, regardless of their birth assignment, is comfortable using that “woman” label on themselves.

When I say “exclusion” below, I mean “fully exclusive” (meaning, no outsiders allowed), or “allies welcome” (meaning, ‘not for you’, but you won’t be turned away). It’s about who the group is for, and who gets a voice, not necessarily about who’s allowed in the door.

So let’s talk a bit about women’s spaces and the rules of exclusion they develop to create value for themselves, what they usually intend, and explore ways in which some spaces might become more inclusive of “enbies” and/or folks of various trans categories.

A Hierarchy of Exclusivity

Recently, while speaking with a group of non-binary folks, a discussion came up about how many of us are uncomfortable in “women’s spaces”. We talked about what these spaces usually intend, how they word things, and how they could align what they want with what they say, in order to get more of us to feel comfortable.

Feminism, for a long time, has carried the standard of addressing gendered oppression in our society. It has also historically been led largely by cis women (which I believe to be true, regardless of the fact of all the trans women that have been there for a very long time and adding incredible value to the discourse). These days, though, feminism has expanded beyond “women’s rights” and into the territory of the general fight for gender equality, as well as incorporating the concept of intersectionality from the womanist/woc parts of it. That’s important to note — because the issues that concern us are no longer discussed in terms of clear-cut gender identities.

One of my friends came up with a hierarchy for what “women’s spaces” want when they say “This space is for women”, and the rest of us hashed it out a bit more, and it looks something like this:

1. TERFSpace: When explicitly stated, this tends to be fairly rare in practice, but is worth mentioning because many people assume a space to actually be this, if things are worded wrong. Most of the time, though, it’s a result of naïveté on the part of organizers about trans and other identities. “TERF” stands for “trans exclusionary radical feminist”, and is a label applied to feminists who believe that only cis women are “really” women. These spaces do exist, but my experience has been that most women’s spaces actually care about welcoming and including trans women in their ranks. When looking out for them, one might look for mentions of “biological women”, “real women”, or “socialized women”, which are all dogwhistles for TERFs. Some “women’s colleges” might be the most prominent examples of this. Smith College existed in this space until recently, for example.
2. JustUsGirls: You could see this as the next step after the above. Organizers have learned about trans folks, care about trans issues, and explicitly want to be inclusive. They still label their spaces as “women’s spaces”, they still regularly say things like “hi ladies”, “hey gals”, and such which are strongly identified with “woman”, but they make damn sure that their trans (binary) sisters feel welcome in that space. I would say that the majority of “women’s spaces” I’ve ever been in fall into this category — not because they’re being exclusive of non-binary folks, but because they want a space like they’re used to having (and find camaraderie among other (though often femme) women), but don’t wanna be big jerks about it. There’s hints of non-binary inclusion in these, but they come with a caveat that the “woman” label must be a thing you use. You can usually spot these places by looking for things like “for women, including trans women” or “for women, or anyone who identifies as such in a significant way” or even “for women (or people who identify as such some or all of the time!)”. An example of this sort of space is the Women in Tech Chat (aka “WITChat”), which accepts non-binary people who do not identify as women, but is fundamentally a space designed for connection under the “women” label — it’s not a space that will necessarily fulfill non-binary folks’ needs. Smith College also famously transitioned (pun intended) from a TERFSpace to this sort of space after updating their admission policy.
3. NoBoyzAllowed: Some spaces decide that “women” isn’t quite what they’re looking for (I’ll talk about this more below), and they decide that the rubric they really want is anyone except people who identify as men. This is a type of feminist space that achieves a large chunk of the sense of support and protection from men, but makes damn sure that folks who don’t lie on either side can join in — because they are still harmed by patriarchy in similar ways to binary women. A shorthand I’ve seen (and used) is to simply call these spaces as “not-men spaces”, or in longer (and clearer?) form: “women and non-binary individuals”. One example of this space might be the 🔒not-men channel in WeAllJS, or the same in lgbtq.technology, which are explicitly framed as spaces for anyone who does not identify as a man, and were created with non-binary folks in mind from the get-go. Additionally, Bryn Mawr’s admissions policy, although it’s a #2 on this scale if you’re AMAB.
4. NoCisGuys: Finally there can be spaces that decide that the rule should be “people who have lived gendered oppression in a significant way”, at least according to the concept that cis men tend to enjoy the most privilege (and perhaps inflict the most violence) in the gender spectrum. I don’t see a lot of these spaces explicitly described, but I’ve seen some #2 and #3 spaces be implicitly expected to be like this. This is a tricky one: trans men are men, even though they have very likely lived gendered oppression, and have a fantastic, unique perspective on sexism. Labeling spaces like this one wrong (specially using any wording that implies it’s a “women’s space”), turns into a rather uncomfortable case of possible trans exclusion. If this is the sort of space you want, don’t call it a women’s space anywhere. Sticking with the “women’s colleges” theme, Mt Holyoke College’s admissions policy works like this, though the wording could use some work.
5. Whatever: mostly included for the sake of completion, this sort of space, whether it’s directed mainly at inviting women and non-binary people or otherwise, has no actual restrictions on attendance/speaking/participation, etc. They can still possibly be labeled “women’s spaces” or “for women and non-binary people”, but they often explicitly say “allies are welcome”.

Picking One and Making it Clear

I believe all of the above, except #1, can be useful for different kinds of communities. There is nothing fundamentally wrong with wanting any of #2, #3, or #4. The problem comes, though, when you intend to do one, but you communicate another through your community rules, descriptions, and general messaging. This happens a lot! Usually when leadership doesn’t include folks who exist beyond the binary, or at least not far enough from “women” where it would matter.

So just make it clear: If you want a space that explicitly excludes nonbinary people who are not women, because you want to celebrate womanhood in particular, use “for women, or anyone who identifies as such in a significant way” — that’ll cover you for both trans women, and for non-binary women. I, for example, would feel welcome in a space labeled as such.

If what you want is a space away from patriarchy in general, then don’t call it a “women’s space”. Don’t call it a “women’s conference”. Don’t call it “Women in Technology”. Yes. I know that word carries a lot of weight for you. Yes, I know you’re not trying to be exclusionary here. Yes, I know it’s a convenient shorthand. But that’s not good enough. Don’t do it. You are actually making a lot of non-binary people who very explicitly aren’t comfortable with the term “woman” (even if they share literally all the concerns that the space was made for, including being femme (“feminine” but not necessarily “woman”), being AFAB, etc). Words matter, and they’re particularly strong in the queer/trans/non-binary community. The blunt truth is this: you have to let go of the label for the sake of the group you’re trying to serve. It’s okay to say “women and non-binary people”. But you have to say both of those word. Every. Time. It’s not good enough to say “woman is a shorthand”. It’s not. I promise you that’s not how it reads to many, many non-binary people I know. That’s just a pill you’ll have to swallow.

And finally, the same thing applies to any space that you want as #4: For the love of everything that is good, don’t call that a women’s space. Trans men are not women. Don’t even say “used to be women”, because that is very much not the case for many trans men. Use other words: “anyone who has lived gendered oppression in a significant way”, or “anyone with a strong voice regarding feminist issues”. Or, frankly, don’t even bother with excluding cis men: just call the space feminist and open to any and all genders, and be done with it.

Conclusion

Labels are tremendously important to the queer community in particular. We’re sensitive to them. We use them to filter out things that might actually be dangerous to us. It’s your responsibility, as community organizers, to put serious effort into the structure of your community, the words you use, the rules you place on it, and the resources you provide. And besides reading medium thinkpieces like these, which might help a little, there’s no replacement for simply taking people who are not like you, who exist on these intersections, and bringing them into leadership. Most non-binary individuals that have some kind of footing in the community would be able to help you do any of the above without even having to refer to external sources. We know what our needs are.

✨Internet Kat✨ on Twitter

Hi all! I'm happy to announce @wealljs, an inclusive JavaScript community! Sign up for the slack at https://t.co/Zta734AKAJ!

I didn’t write a lot about it back then. Mostly ’cause I’d been focusing on seeding the pre-launch community, writing the initial policies, such as the Code of Conduct and Enforcement policy, getting the website working, and putting together a Slack App to manage admin tasks, invites, etc. Shortly after, I drafted the earlier versions of the Signup Policy.

That seems fine — turns out in the past month, WeAllJS has hit a whopping 370 members on Slack, which isn’t too bad for a brand new Slack focused around a single topic! We’ve already learned a few lessons, grown more policies, and developed a distinct community identity with useful resources for its members.

What’s So Special About This Place?

Most online communities I’m in tend to fall into two categories:

• exclusive communities intended to serve some slice of intersections, serving as backchannels or support groups, bastions of safety from the larger tech community.
• everyone-jump-in communities centering around particular technologies which tend to deprioritize inclusive community building and supporting the underrepresented in favor of being open forums for specific topics.

WeAllJS is different: It’s based on the premise that it’s possible to build an inclusive space where everyone can benefit from open access to resources (including jobs!), but where voices that are usually drowned out by the usual tech scene can be raised up and heard without fearing harm.

It’s often said in my community-building circles that you get to pick one or the other: Openness or Safety.

I believe WeAllJS can pull off both at the same time.

Well, sort of…

There is No Such Thing as a Safe Space

We talk a lot about “safe” spaces and the benefits that they bring. I completely agree that having spaces to withdraw to that are more isolated from particular categories of aggressions and harm. But from a community organizer/manager point of view? If there’s anything that I’ve learned is this:

You cannot guarantee your members’ safety.

You can do all the policy work you want. You can have all the application processes, filtering practices, Codes of Conduct, enforcement policies. But it won’t guarantee anyone’s safety. Because in the end, someone will say something or do something. And the damage will be done.

And the targets will not feel safe anymore.

And the more people you keep out, the fewer resources your members have access to.

In Defense of Supportive Spaces

WeAllJS adopted the label of a “supportive space” to describe what it does. We know we can’t guarantee the safety of anyone who joins, and that something will always happen, no matter how hard we try.

So instead, we’ll do something that we can commit to: We’ll support you.

Supporting means that when something happens, it’s the person who was harmed who takes priority. It means that we need to be proactive in structuring the community in such a way that the possibility of harm is reduced. It means everyone should know what happens, what to expect, and that they won’t need to fight for the smallest shred of justice. They won’t have to justify the pain before anyone is willing to take action.

Supporting means that you’ll help lift the weight off their shoulders without pushing them to the sidelines.

Structuring Supportive Spaces

Supportive spaces aren’t just about setting a bunch of rules (we do that), or having diverse organizers/admins (we do that, too): They’re about having a structure for your community that clarifies social expectations and balances access to resources with connection and community.

WeAllJS, being primarily a Slack-based community, uses a particular strategy for balancing these two: Resource Channels and Identity Channels.

The idea to structure a community in this way originated in the lgbtq.technology community, which started making such a distinction at some point, and implemented specific policies around them to better strike the balance between resource access and reduced exposure to harm.

Resource Channels

The premise behind resource channels is that there are some things within a community that are much better when everyone is able to share them. In the case of WeAllJS, these channels are public, managed by admins, and fit specifically into some narrow categories, such as “platforms/technologies”, “jobs and career advice”, “local community”, and a few miscellaneous channels for specific purposes like meta-conversation about the Slack.

Resource channels have an expectation of low-intensity conversation, of being spaces that are limited to those specific topics and generally to keeping connection between people careful and polite: as one might do at a professional meetup in meatspace at a work-related venue. We know how to behave in these spaces. We’re still friendly, we can still bond, but everyone is there because they see the space as a resource. The experience at WeAllJS so far is that this pretty naturally stays within a respectful, polite range of conversation.

Identity Channels

Identity channels exist on practically the other end of that spectrum: They’re private channels centered around specific parts of personal identity, different intersections. These spaces are created so we can bond with people who are like us, who we’re more familiar and more comfortable with. Spaces where we don’t have to watch out for particular microaggressions. Where can expose a side of ourselves that it simply isn’t comfortable (or safe!) to openly expose when others are looking. These are the spaces where we can have Those Conversations. They’re our backchannels. Our whisper networks. Our circles of friends and kindred spirits.

Examples of these channels are: lgbtq, poc, mental-health, not-men, not-women, persons with disabilities.

These channels are arguably just as important as resource channels for creating a healthy, bustling community. Identity channels work out to be incubators for particular intersections of your community. It turns out that when you go somewhere, look around, and realize you’re literally the only one there that’s anything like you… well, you know it’s not a place for you. And it’s probably not. Because no one will be there to understand when something affects you in a way that the others aren’t affected. You feel alone.

But when you look around and there’s a few of you, and you have a space where you won’t lose them in a much larger crowd — a place where you can make sure to only hear each other’s voices — you don’t feel alone anymore. You have a place to withdraw to. You have people that you need to ask questions of that you know will understand your needs related to that intersection better than others. People that you don’t need to educate.

And then, energized, you can go back into the bigger crowd. It’s much easier to be vulnerable when there’s a safety net right there for you. And it’s much easier to feel like you belong in the larger space when your little corner of your own is a part of it.

A Month of Results

No joke, I’m really happy this group exists. I feel like I belong and have support much more now and it is lovely to have folks to talk to about my nerdy hobbies and to exchange knowledge with. WeAllJS is amazing. — @matsie

i like how active and respectful this community is —Elaine

yeah our community seems really mature and developed because we have actually the highest concentration of dads — @mysterysal

(quoted with permission)

It’s pretty great so far! The Slack has been seeing a lot more activity in the past two weeks as a core of participants get more comfortable participating, as channel cultures start forming. It’s amazing to sit in our #watercooler channel and see a huge variety of folks contributing. Not-men, queer folks, black folks, and cis white dudes, all in the same regular conversations.

Identity channel membership:

• mental-health: 23
• not-men: 63
• not-women: 15
• neurodiversity: 20
• poc: 23
• black-folks: 8
• latinx: 11
• people-with-disabilities: 11
• lgbtq: 52

Note that there is a lot of overlap between members in these channels, and not everyone in the slack who falls into the general scope of an identity channel joins it. These numbers are less useful at looking at the overall balance in the community, and more at seeing the various groups that are being served by identity-based spaces — as well as just general representation in the Slack.

The community is also fairly spread out geographically. Bay Area techies turn out to not be a majority: there’s significant representation of Latin Americans, Europeans, and even a bit of of East and South Asia. One of the larger location-based channels in the Slack is even dedicated to people who are “out there” — that is, fairly far from significant tech centers in their respective countries.

The Slack also recently adopted a Docent System for helping encourage conversation and have dedicated individuals to act as points of contact. And, most importantly: to watch out for voices that might be otherwise drowned out, and make sure they get heard in the conversation. The process is still in its early testing stages, and only a few channels have active docents so far (#npm, #backend, #rails, and #arthack). They’ve definitely already nudged those channels into more regular activity!

And all of this isn’t happening entirely without Code of Conduct violations. The Enforcement policy has been put into action more times than I can count, but most people don’t even notice. Let’s take a quick look at that policy:

1. Tell someone “hey, that’s not ok”.

2. That person should apologize immediately and correct the behavior.

3. If this doesn’t happen, isn’t safe to do, or is not satisfactory, message admins.

4. Admins will take appropriate action in a timely manner, prioritizing those who were hurt.

— WeAllJS Enforcement Policy

Almost the entirety of CoC “violations” have stopped at #2 in that list. Because our enforcement process is not zero-tolerance (and in fact, operates in distinct stages of seriousness), people who are called out for various issues simply apologize, edit the relevant message, and move on.

Perhaps, to me, the biggest sign that “The System Works!™” is this: it is not a common sight for a cisgender heterosexual white man to be asked directly, in a public channel, to refrain from using some ableist term (read: “crazy”/”lame”/other terms which are widely-accepted in common parlance). And they just go “oh sure, sorry about that!” and everyone moves on. This might seem like an obvious conclusion to you, dear reader, but it’s mindblowing to someone who has had to field numerous CoC violations as an admin in other communities for years.

Reactions like that means that no one involved feels particularly threatened: The person who Said That Word knows that they won’t get banned or publicly shamed for messing up or saying the wrong thing, because we just don’t do that — because our enforcement policy says we won’t. And the Person Who Was Hurt knows that they can speak up, and that admins will have their backs. They know that the worst-case scenario as far as they’re concerned means they have to escalate to #3 in the tl;dr, and admins will make sure things are handled from there. They won’t have to justify it to us. They won’t have to fight tooth and nail for what feels to them like basic respect. When you take a trust-but-verify approach to these things, temperatures stay low, and everyone is simply better able to handle what can very easily become a deeply uncomfortable conflict.

And so, We All Grow Together.

I’m Done, I Swear

This first post about this stuff was a little long. Thanks for hanging in there! I can only hope that writing about this, sharing experiences, and showing what really really worked and what really really didn’t will be useful to others and to this very community.

Let’s see where it all goes from here, dads! Wanna join us and help us make a difference? Head over to wealljs.org and sign up! I look forward to seeing you!

P.S. dad jokes have become a thing. Especially in the queer corners of the slack. I’m not even sorry.

✨Internet Kat✨ on Twitter

This is a good description of one of the corners of @wealljs. Dad jokes turned into a thing. (cr: @ShutoTakahiro)

I’ve tried to collapse them into a set of choices that you can make between fairly-equivalent tools, and you can figure out the details based on your specific project needs.

Note that depending on your other tools (servers, front-end frameworks, etc), a lot of these choices will be made for you. This post is for clarification, and doesn’t cover those cases, which you’ll have to suss out on your own.

1. pick a task runner

These are for abstracting away common development tasks, like running tests or a dev server. tool <commandname> to do each thing, i.e. gulp test.

Choices: Grunt, gulp, make, and npm scripts.

They are all the same thing — ops tools for composing together large, complicated build tasks. The first 2 (grunt, gulp) are nice because they have big ecosystems of common tasks, so you simply import them, and add some configuration, and they take care of the details. The others require no extra dependencies, but don’t scale very well as things get more complex (if that’s where you’re headed).

Edit: A previous version of this referred to broccoli as a task runner — this is not quite right. It works more like a bundler in practice (see below).

2. pick a bundler

(front-end only)

If you’re doing front-end, you usually want a tool that can get all your javascript files, collect them, minify them, and spit them out as a single app.js that you then put in a <script> tag.

Choices: Webpack, browserify, broccoli.

They only differ in some details in their approach. Pick whichever you find yourself more confident with after looking at their docs. Most of the time, there will be no real difference in the end. npm cannot do this very easily at all, unless you write a manual concatenation bash script. Please don’t do that, and ignore the jerks who try and convince you that’ll ever be maintainable.

3. pick a compiler tool

(optional)

Compilers let you write javascript in one style (such as ES6/ES2015 or CoffeeScript), and convert them to es3 or es5 so it works with most platforms, or even minify or otherwise transform it.

Choices: babel, UglifyJS or plugins to your bundler (babel can also be, and often is, a plugin)

If you’re just gonna write and output straight-up es5 or es3 (“regular” javascript), you do not need this.

That said, the functionality in compiler tools is almost always absorbed into the build pipeline for bundlers, so most of the time these will just be plugins you add to those.

4. pick a test runner

There’s a bunch of test runners, they all work somewhat differently, but they all basically do the same thing: run your project’s tests.

Choices: karma, testee, tap, mocha, jasmine, etc.

Your choice here should depend on what you want your tests to look like, and what just happens to be more convenient for you. Running tests on a browser can be tricky, but the first two items on the list above specialize in running your test code in actual browsers, automatically.

Some clarification: You might see karma or testee talking about being able to run tests with mocha and jasmine. That just means they can use a subset of those tools (which are actually larger frameworks) to run your tests, but they essentially wrap them, and act as their own, separate tools.

5. pick a linter

(optional)

Linters are like a simplified mini-test-suite that usually runs before your actual tests, or in your browser. Linters just read through your javascript to find common errors, like misspelled variables, syntax errors, or formatting problems. They’re often used to make sure everyone on your project is coding in the same general style, and catch simple programmer errors.

Choices: standard, eslint

standard is nice because you’ll never have arguments about how to configure your linter. eslint is nice because you get to spend weeks arguing about every single little detail about your team’s coding style. :trollface:

Edit: my snark above should tell you everything you need to know about how I feel about the details of this one in particular. Linters are handy. Don’t waste more time on them than they save you.

6. use npm scripts to wrap all of the above

Invoke all the above tools through npm scripts, so you have a single, straightforward command into all this stuff that works across the ecosystem.

npm scripts add binary dependencies to $PATH, so you can do:

“scripts”: { “build”: “grunt build” }

And then npm run build to run that task.

Since you know npm will basically always be installed, these days, getting your devs used to just doing npm test or npm start will be more future-safe. And really, you can let complexity happen over time this way, without complicating the interface, and most importantly: You don’t need to tell devs to npm i -g grunt-cli, which is a really annoying setup step for new dev, imo.

Choices: npm ;)

7. pick a front-end-specific package manager

(optional, discouraged)

These tools are not really that necessary these days, but the fact is, npm’s front-end module support isn’t gonna do as good a job in some cases. npm@3 usually flattens, but there’s no way to guarantee this, so you may run into issues where things you were pathing into node_modules/ for unexpectedly moved deeper in the tree, or suddenly you have two copies of jQuery trumping each other, etc. Bundlers usually fix this, but it can still be a problem.

Choices: bower, jspm, etc

idk. I don’t use any of these anymore. They’re just more dependencies I don’t need <:) (disclaimer: Some of you may not be aware, but I’m a dev for the npm CLI. This last bit is clearly biased. I’ve used bower plenty in the past. Do whatever makes sense for you in the end.)

putting everything together

Curious about what this might all look like? You can check out https://github.com/zkat/mona/blob/develop/package.json for an example of a setup for a front-end-compatible library that:

1. publishes to npm
2. only uses npm scripts as the task runner
3. uses webpack for bundling
4. uses babel for converting ES2015 to ES5 (without bundling) to make it available to Node.js
5. Runs a linter (standard), builds, and uses mocha to run the test suite.
6. Does all of the above as devDependencies, requiring no global or external installations besides npm itself.