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 notifications@github.com 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.