It seems like a strange set of tooling and I don't get to configure it how I like.

Why would I want to use Babel to compile server side code rather than just use the latest version of Node? It's actually doing two compilation steps because it's got TypeScript in there too, which is also a compiler. It uses Jest for testing, which is primarily designed for React.

I haven't found my preferred environment scaffolding yet. As I go I find better and better ways to set up my app and usually it's pretty app specific. If I did find a great scaffolding tool I think it would be one I have full control over. Maybe a lot more like Yeoman which has been around for quite a while.

You can do a lot even without scaffolding, just npm init and git init.

Jest isn't primarily designed for React. It has a lot of built in feature for making testing React components easier. But it's a generic Javascript test runner and framework

Yep - the main thing that Jest gives out of the box is jsdom, so allows for dom based testing without needing phantom (or more modern now, headless browser).

I also find it's faster and has better features than Mocha (for instance, coverage out of the box).

I use Babel and TS server side. TS for types, and Babel because the latest stable version of node does not always support the latest Ecmascript features. Example from recent memory: Async generators (async function* yada(){} and for await of).

FYI Jest is great for Node too, not just React. Very happily using Jest for my non-React project right now.

It doesn't do double compilation when using TypeScript, .ts goes goes to tsc and .js to Babel. It uses Babel so you can use ES6/7/8 on the server.

This is meant as a simplified project build tool, not for every use, but you can configure it quite extensively if you need to (although it has limitations). I would estimation that ~80% of projects could use this, and is less than 5 minutes of migration or 30 seconds to get started. It's not for the 20% of projects with very custom needs for build configuration.

You might be interested in Concatapult [1]. I built it to minimally cover server needs (first-time setup, env vars, testing) and optionally add tech as your project needs it (react, knex, typescript, etc).

Basically it's a lego-like version of yeoman, and opinionated towards simplicity.

[1] https://github.com/Concatapult/pult

I am interested. It looks at the very least as interesting as the project in the op thanks for the link.

I'm not really on board with using babel for a server-only project either, but I do like jest for testing and have in fact only used it for node app servers so far.

Author here! Let me know of any questions or suggestions for the project.

Quick links:

https://noderize.js.org

https://github.com/Cretezy/Noderize

Just noticed the docs have a tutorial on creating a command line interface app[0]. Thanks for this. Would love to read the next steps involved in making the app accessible with with just `fibonacci`, as opposed to `npm start fibonacci`.

[0]https://noderize.js.org/docs/tutorials-cli.html

Check out something like pkg by zeit[0] which compiles the node app to a binary. Then put it in a directory in your $PATH and you'll be able to run it as `fibonacci`.

[0]https://github.com/zeit/pkg

The easiest way is simply to use npm's bin, which if installed globally (npm i -g my-command) is added to path.

I’m interested in making binaries, to hopefully ease distributing in-house utils. Our various projects depend on misc node versions and reinstalling our utils to each new global bin ain’t fun. If there’s a better way, I’m all ears.

Please don't use this if the project is for work/something you care about, because it's a bitch to support in production, especially when compatibility becomes an issue. Better to not mention it at all in a work related context and just say there's no way to distribute nodeJS applications as binaries.

Good idea! I'll add it to the tutorial on the next release.

It's basically making a custom entry for that specific command and adding it as a bin in the package.json.

`sudo npm link` will do that

I do not recommend using npx. Any typo can result in downloading a malicious package published using a similar name.

The same is true of `npm install`. Custom lifecycle scripts can be run during the install process.

Adding "ignore-scripts=true" to your ~/.npmrc helps here.

Although true, it is the same for npm or yarn too. There's no real solution to the typo problem, and it's not npx specific.

In a team environment npm or yarn configuration would go through peer review, whereas getting used to typing npx increases your chances of falling victim to a typo.

The npx part is only to setup the project, which is making a package.json and a src directory.

Is there something like this that is a template for server-side node apps? My experience with node has been small scripts and build configs but I would love to find a template to start with. Any recommendations are appreciated!

I created a mostly unopinionated starter project [1] for creating RESTful APIs using Koa2 and ES2017+ features in a Node.js server environment as well as providing linting and testing support. It provides the setup for compiling, linting and testing your code but doesn't make any further assumptions on how your project should be structured.

[1] https://github.com/pranavpr/koa2-es2017-api-boilerplate

From what I understand, it installs a bunch of opinionated packages and then you're on your own. This isn't the same as "create a useful app in 30 seconds".

Cool initiative, would be great to see an "eject" command similar to what CRA provides so that the user can expose all of the configs if they wish.

While I appreciate the value people get from TypeScript, I do not use it and would prefer if it were optional (along with babel). Looks ok otherwise.

It is. You must actually TypeScript support (it's a single option), but it is turned off by default.

You can also disable Babel (and JavaScript) if running only TypeScript.

Someone needs to figure out how to do this in 20 seconds and then they would really have something.

Most of the time is waiting for npm/yarn to load up! The whole process on a fast connection is closer to 10s :P

It’s not clear why one would use this instead of yeoman. Perhaps the docs could mention that?

Yo is a scaffolder. At the end of the generation you are more or less on your own. This is a full prepackaged config you can easily upgrade. The cost? Hard (if not impossible) customizations of underlying products config. Not a con IMHO.