Proposal: `run` and `watch` scripts to use different entry points

[lacker]

As I start to build out real apps I find cases where I want to run a one-off script using the same language features as the rest of my app. If the only way to enter my code is via npm start then there's no way to do this.

The proposed solution is to add two more scripts, react-scripts run and react-scripts watch that the developer can use to make their own npm script which uses the same babel environment. For example, let's say you had a script src/populate.js to populate initial data in a remote backend. You could add to your npm scripts:

"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "eject": "react-scripts eject",
    "populate": "react-scripts run src/populate.js"
  },

and then when you ran npm run populate it would invoke src/populate.js but do all the babel preprocessing to let you use ES6 features. watch would work just like run, but when any file changed it would restart the process. So watch would be used for long-running processes; run would be used for one-off scripts. run here works similarly to rails run if you are familiar with rails.

Without this sort of feature, developers are likely to make these one-off scripts using ES5 or using whatever language subset is node-compatible. This would also be a useful hook for people who wanted to build node server functionality, while not forcing it on anyone.

What do you think?

[taion]

The way people normally do this is to drop a .babelrc in project root and just use babel-node script.js.

Note BTW that if #189 gets merged – it can't be literally the same Babel config, since Node doesn't natively support ES modules.

[lacker]

Yeah, I would normally use babel-node and babel-watch but since the .babelrc isn't exposed in this project, there's no straightforward way to do it without ejecting. This run and watch functionality could mostly be simple wrappers around babel-node and babel-watch, with something to deal with the ES module support issue you bring up.

[gaearon]

@ForbesLindesay also suggested this in another thread. Seems like a useful feature.

[gaearon]

I'm not sure I understand the use case for watch though, can you elaborate?

[taion]

There's something a little weird about having a populate script to populate a backend in a front-end project. What are the actual use cases in an application for running one-off scripts? I don't think I have any outside of build-related tasks.

[lacker]

@gaearon watch is useful if you want to write a long-running process such as a server so that it automatically restarts during development. You could make a simple node server this way and have it reuse library code in your src directory. It could be something that's a full backend, or it could also be something simple like a proxy that you're only going to use in development. For example you could have Flash content somewhere and want to write a proxy that served up .swf files from a separate folder & used a separate deployment process.

@taion Well build-related tasks are certainly one use case. You might run a script to update something that you've vendored, for example. If it's straightforward to add your own build-related scripts, then it will let people add features to their projects without needing support from the build tooling provided by create-react-app itself. A script to populate a backend in a front-end project is something you might want if you are using a "serverless" design. For example, you might be using a Firebase backend, and your workflow might be to provision a new one and put some seed data in there whenever a new developer joins your team. With this sort of react-scripts run functionality you can write the seed-data script using helper libraries you've already written.

My hope is, the more there are generic tools to let developers use the runtime environment that create-react-app provides, the more people will be able to build themselves rather than asking for more features to come "out of the box" or ejecting.

[taion]

@lacker "Provision a dev instance in Firebase" is a good point. I bring up "build tasks" as something this isn't necessarily a good fit for, because ideally you'd want to also run build tasks when you do npm run build.

[lacker]

An example where I would want watch is the example at https://github.com/fullstackreact/create-react-app-with-server that @acco created. That project invokes its server with ./node_modules/.bin/babel-node so you could use the proposed react-scripts run to directly match its functionality but I think react-scripts watch would be better for that use case.

[lacker]

OK I am going to take a stab at creating run, and then depending on how that goes maybe watch will also be useful.

[wdhorton]

This run and watch functionality could mostly be simple wrappers around babel-node and babel-watch, with something to deal with the ES module support issue you bring up.

What is the plan for dealing with ES modules? I don't necessarily see a way around it without creating a separate Babel config for this feature that keeps transpiling to CommonJS (which doesn't seem like a good idea), or bundling with Webpack instead of using babel-node.

[suchipi]

I think it would make more sense to use webpack than babel-node, because then you'll be able to rely on the same loaders and plugins you're already using in the application code. It might be confusing for a user if they can't load some filetypes in some of their JS, but they can elsewhere.

[gaearon]

I think it would make more sense to use webpack than babel-node

Agree.

[lacker]

I implemented the run functionality here: #245 Feedback is welcome!