Support a --require flag

[LandonSchropp]

I'm submitting a...

[ ] Bug report  
[x] Feature request

Current behavior

Currently, in order to run @babel/node, you have to include a plugin.

Expected behavior

I would like to see a --require flag added to the CLI.

Minimal reproduction of the problem with instructions

N/A

What is the motivation/use case for changing the behavior?

We're now writing all of our JavaScript code using the async/await syntax in our JavaScript. This syntax will eventually be integrated into Node, but for now, we're using Babel. Many Node CLI tools include a --require flag that can be used to load modules directly from the command line, making it easy to add @babel/register to the project. There are also other ES6/ES7 niceties we're using that aren't currently supported by Node, and it's plausible there will be additional ones in the future.

This could be done with a plugin, but it strikes me as unnecessary when there's already a standardized solution to this problem. Plugins also require maintenance. For example, db-migrate-plugin-babel is using the old babel-node instead of the new @babel/register. I'll submit an issue to that project, but that wouldn't be necessary with --register.

Environment

db-migrate version: 0.10.2
db-migrate-pg: 0.2.5

Additional information:
- Node version: 9.2.0
- Platform: Linux (via node Docker image)




---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/53403387-support-a-require-flag?utm_campaign=plugin&utm_content=tracker%2F73887&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F73887&utm_medium=issues&utm_source=github).

[wzrdtales]

We're now writing all of our JavaScript code using the async/await syntax in our JavaScript. This syntax will eventually be integrated into Node, but for now, we're using Babel.

It is already part of node and available, so actually no more need for babel for that though :)

Do you have a reference of a CLI that does support --register?

[LandonSchropp]

Hmm, maybe I was mistaken about the precedence of this. I know mocha supports this flag, but it seems to be the only prominent example of it that I could find with a quick search.

mocha --require @babel/register spec/spec_helper.js 'spec/**/*.js'
mocha --require ts-node/register spec/spec_helper.js 'spec/**/*.ts'

After thinking about it a little more, I think my larger concern is that there's not an easy way to add a register package without writing a custom plugin for it. The db-migrate source code looks for packages beginning with db-migrate in the package.json file and uses that to require them. Maybe there could be a different way that you could modify the behavior of db-migrate, even if it's just specifying local plugins?

Also, I mixed up --register with --require. 😃

[wzrdtales]

Dump question:

Why would you want to use babel, typescript, coffeescript and crappyscript all at the same time for the same project? Plugins are loaded from the package.json of your current project, having everything thrown in one single application sounds like a huge mess. So how would the require approach be more useful than just installing the plugin for the specific project. Also to add that you can install all plugins at once which would make for you no difference at all. Specifically looking here at what makes sense and what not and currently it seems like this is not really anything db-migrate releated and therefor nothing I would put into the core. If you've got a specific use case ok, and for the old version thing, you can publish your own plugin and could for example publish a peerDependency based one. This would allow to always use the version you want to use of babel. Or submit a PR for it to that plugin :)

[wzrdtales]

Basically plugins are for everything that would be bloat, they're the freedom option for the community to get where they want whatever that will be.

[LandonSchropp]

My use case isn't driven by wanting to use different plugins at the same time. In my particular case, I wanted to use Babel with db-migrate. However, for version 7 the babel-register package is being renamed to @babel/register. I opened benjie/db-migrate-plugin-babel#2 to address this issue, but there's going to be a painful transition period for people using that plugin—both won't be able to exist at the same time, and not everyone will update right away.

My next thought was that I'd just create a local plugin to solve my particular issue. However, db-migrate specifically requires plugins to be listed in the package.json. This meant that I had to fork that plugin and make my changes to use it. I opened this issue because I assume other people are having the same troubles.

I also wanted to avoid publishing my own plugin to NPM. Eventually, db-migrate-plugin-babel will update to @babel/register, and when that happens there will be two plugins floating around. I thought that would be confusing to other people. The --require approach struck me as a simpler solution because it allows you to pull in anything you'd like, whether it's a plugin, a register package or a local script.

I totally agree with the idea of removing bloat from db-migrate. I think it's a mistake for tools to try to pick winners and losers in technologies, and you'd be setting yourself up for a maintenance nightmare if you tried to support everything. However, I still wonder if there's a simpler way to solve some of these problems. Maybe my suggestion of a --require flag isn't the right way to go, but there might still be some other way to mitigate this.

[wzrdtales]

Actuallly I aim to get plugins to exactly this state, protecting from bloat, but don't limit the possibilities.

And about your PR, it is not so painful, if @benjie does release this as a major release, like semver specifies, no one will have a painful transition. Everyone will be aware that this is somehow a breaking change there and they can move to the new version whenever they think it is the right moment.

[benjie]

Personally I support the request for a --require flag; but I can also understand the desire not to complicate core. I don't use the plugin myself any more - I just use SQL migrations now.

Here's a suggestion - do plugins get access to the CLI arguments? Because if so we could totally just have a db-migrate-plugin-require that adds a --require option - thus it's not in core, but it's simple and wouldn't require any maintenance.

Ultimately it's literally one statement we're talking about: if (typeof args.require === 'string') require(args.require);

[wzrdtales]

The plugin also registers new file endings to be handled though, but yes plugins will get access to CLI arguments. I still can't see the benefit of require over a plugin doing this directly here though.

[LandonSchropp]

@benjie: I think the difficulty of a require plugin would be that db-migrate would have to ignore any flags related to the require plugin. I'm not sure how db-migrate currently handled things under the hood, but that would require some work. Even if db-migrate simply ignored a --require flag, that still leaks the abstraction out of the plugin.

@wzrdtales: Although I think a --require flag would be useful, I respect that you'd like to take db-migrate in a different direction. The challenge for me is there's still no way to add a local plugin. My problem would have been easily solvable if there were a way to add a file that includes @babel/register.

[benjie]

@LandonSchropp I was thinking db-migrate could give plugins access to optimist so that they can register their own CLI options - that way they'd even come up in --help, etc.

https://github.com/db-migrate/node-db-migrate/blob/master/lib/commands/set-default-argv.js#L22-L99

[LandonSchropp]

Gotcha. That makes sense.

[wzrdtales]

@LandonSchropp You could have produced at any time your own plugin, there is absolute freedom of how it acts actually. If you would want it to be configurable this would be totally open to you though.

Concerning to the access to CLI, this is already on the list if you want to help and write the necessary hooks for the plugin system at that level feel free to contribute a PR though :)

[javidjamae]

I think the more general issue here is that you can't easily define a "local" plugin. Currently, the code loads plugins by reading the package.json file from the filesystem.

In addition to reading the package.json file, if you allow the definition of a plugin file in the configuration, that would be loaded before or after the package.json plugins are, then the user would have the flexibility to just create a simple plugin to bootstrap using babel or whatever else without having to go through the hassle of creating a new published library that they can include in package.json.

It should be a simple change and I'm glad to do a pull request for this if I know it's something you'll consider for approval.

[benjie]

Maybe yarn can help here:

https://stackoverflow.com/a/40116358/141284