Ava: Set babel inherit in the cli

[calebmer]

Could --babel-inherit or a similar flag be added to the command line? In my project I cannot depend on any fields being present in a package.json, so "ava": { "babel": "inherit" } is a no go and I do everything from the command line. At the same time I need my tests to use a custom babel configuration defined in a .babelrc file.

[vadimdemedes]

In my project I cannot depend on any fields being present in a package.json

Could you explain a case where it's not possible?

[calebmer]

A monorepo where I have multiple packages and the package.json is created dynamically at publish time. I want to use ava to test independently all of the packages in the monorepo which don't have package.jsons.

Or I'm in a JavaScript environment which abstracts away node (like Meteor).

[novemberborn]

@sindresorhus maybe we can support extends and inherit through the CLI?

[jamestalmage]

@calebmer - you still have a root package.json in your repo though, right?

If you do, just put a common ava config in there.

root/
  package.json  (put ava config here)
  packages/
    pkg-1/
    pkg-2/    (ava will traverse up the directories until it finds a `package.json`)

[calebmer]

Yeah, that would work, but what about a Meteor-like situation?

[jamestalmage]

We don't support browser testing yet. You usually still have a package.json in Meteor projects anyways, so not sure how it would be a problem (I know almost nothing about meteor)

[jamestalmage]

My feeling on options via cli.js: We should only add those where users would conceivably want to temporarily override the contents of their package.json config. Allowing different reporters on CI servers, running in --serial mode occasionally to debug, these are good examples.

I haven't seen a use case yet where someone is arguing to change their babel config between test runs. Even if that was what they wanted, it would probably be best to use babels envs option to do that.

I think this should be closed.

[gajus]

I am running into a similar issue. The company I am consulting is running in-house NPM server, which restricts package.json (that is being published) to specific properties.

I would like there to be either an .avarc file or ability to pass all options (such as the one described in this post) using the CLI parameters.

[novemberborn]

@gajus does it reject the package.json when publishing? Or are their other rejections in place that prevent you from even committing (e.g. CI).

[gajus]

@gajus does it reject the package.json when publishing? Or are their other rejections in place that prevent you from even committing (e.g. CI).

The former: attempt to publish a package with unknown fields will result in HTTP status 400.

[jamestalmage]

The former: attempt to publish a package with unknown fields will result in HTTP status 400.

What NPM server is doing that?

[gajus]

Again: in house and probably totally not compliant with the specs (not that such spec exists in the first place).

On May 11, 2016, at 20:05, James Talmage [email protected] wrote:

The former: attempt to publish a package with unknown fields will result in HTTP status 400.

What NPM server is doing that?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[calebmer]

In #520 @jamestalmage said in regards to an .avarc file:

This is not going to get implemented until someone can demonstrate an actual need.

My point here, is demonstrate some actual need. "Because I want" is not sufficient. Neither is "because project X does it that way". If not having the option is legitimately preventing you from getting things done, and you demonstrate why, we will happily change our minds.

I think @gajus’s situation qualifies as “legitimately preventing” things getting done.

[kevva]

I think @gajus’s situation qualifies as “legitimately preventing” things getting done.

Having a npm server that throws 400 on unknown fields is hardly a legitimate reason for introducing a .avarc file imo.

[jamestalmage]

It's certainly closer to a legitimate need, but if it's in house no implementation of npm, just fix your implementation.

[sindresorhus]

AVA adheres to the official npm. We shouldn't have to adapt to every weird edge-case of unofficial solutions. It's a very common pattern to have config just in package.json. I'm not very interested in complicating the purity of that.

[gajus]

AVA adheres to the official npm.

There is no such thing as the official NPM (there is no spec for what the API, there is no spec defining the structure of the package.json [apart from the supported properties]).

It's a very common pattern to have config just in package.json.

Uh, really? I have not needed to use it once.

Furthermore, this limits code portability. It is easy to copy .eslintrc/ .babelrc from one directory to another. It is not so much obvious to copy some arbitrary properties from package.json.

[sindresorhus]

There is no such thing as the official NPM (there is no spec for what the API, there is no spec defining the structure of the package.json [apart from the supported properties]).

By that I mean, what works with official npm is what we'll follow.

[gajus]

Not listening to what community wants and driving the project solely by ones personal preferences will simple result in ava-io...

Not that I care. We stopped using ava for this and several other reasons. Just chipping in to the discussion.

[sindresorhus]

@gajus We always consider user's needs, but you're just one user with a very edge-casy need. If we adapted to every edge-case, AVA would be bloated and hard to use. Creating great simple products requires saying _no_ to thousand things.

We stopped using ava for this and several other reasons.

I would appreciate if you would elaborate on what other things stopped you from using AVA :)

[gajus]

I agree that feature creep is a thing. I disagree that wanting to have a separate config file is an edge-case.

There are multiple reasons for wanting to have a separate config file:

• Version control (being able to see what is the scope of the changes without viewing the diff).
• Project scanability – I see .avarc therefore I know that you are using ava test runner.
• Scaffolding.
• Convention.
• Tight coupling with NPM. What if we are not using NPM in the first place.

For these reasons, I would want ava to accept configuration _only_ through .avarc.

I agree that these reasons are opinionated and have little practical impact.

I would appreciate if you would elaborate on what other things stopped you from using AVA :)

No business case. Our current test suits work. I have suggested ava as an improvement to our development, CI flow. My main argument was that it will enforce atomic tests and parallelisation will reduce the waiting time in day to day development.

Note, when I am talking about "our", I am referring to the current company I am consulting. I am already using ava myself in open source and other personal projects.

[calebmer]

We always consider user's needs, but you're just one user with a very edge-casy need. If we adapted to every edge-case, AVA would be bloated and hard to use. Creating great simple products requires saying no to thousand things.

But this isn't one user's edge-casy need, a couple of issues have been opened asking for a better way to define configuration. Whether that be in the CLI (as this issue requests) or in an .avarc. Ava is already hard to use for all the users that are accustomed to dot file or CLI configurations for the reasons @gajus mentioned above.

Creating great products does require saying no to some things, but also listening to users to discover the things you should say yes to. See #637, #520, and #782.

[kevva]

See #637, #520...

None of those issues contains a problem which is preventing users from getting things done (which makes this one an edge-case) and they are both answered why we're not having a .avarc file.

This is not going to get implemented until someone can demonstrate an _actual need_.

Users preference is not an _actual need_. Unless npm suddenly starts preventing users from defining custom fields in their package.json (which they never will), I don't see a need for adding a .rc file ever.

[eisisig]

This is actually the first time EVER I add config for a package to the package.json file. In all our repos there is a clear conventions that if anything needs config there is a file for it. .eslintrc, .babelrc, .jscsrc, web.config, cosmic.config, webpack.config, rollup.config and the list goes on... It is really good as most of these are shared or used as templates... We have few repos with configs only. On the other hand the package.json file in each project is strictly for dependencies... We are not even publishing most of the packages...

For us the package.json is npm related... Even tho the tools are installed with npm (some git) they are not related or npm should not be a requirement for using them... Most used packages encourage you to use config files (eslint, babel, rollup...)

Enforcing limited config usage sounds geared towards simple, small projects. And that is ok if that is the goal. I'd really like .avarc - Just my 5c

[kevva]

.eslintrc, .babelrc, .jscsrc, web.config, cosmic.config, webpack.config, rollup.config and the list goes on

That's also a point for not having one. I feel like all those dotfiles will only pollute your project.

[gajus]

and having one giant package.json that includes config of arbitrary software is Okay?

I come from a different planet.

[kevva]

I didn't say it needed to be giant. I guess I don't use as many tools (or as much configuration) as you are. If I compile using babel I'll only need a few presets and for linting I'm using xo which I rarely need to configure.

I respect that you're using other tools and it's fine if there are rc files for them, but ava doesn't come with a _ton_ of config and in most cases you only need to override some of the options.

[novemberborn]

At this stage I'm not convinced we need CLI flags to control AVA's usage of Babel. That's not to say this can't be improved or that AVA shouldn't integrate better with Babel improvements though. We're always open to suggestions there.

We won't add CLI flags to work around configuration issues. We're yet to be convinced we truly need support for non-package.json config files. Please continue to share your use cases.