feat: update to support babelConfig and tsConfig

[justinhelmer]

Fixes #110

[justinhelmer]

Change needed locally to contribute: #108
Replaces the need for: #100
Potential alternative approach for: #93

[justinhelmer]

You may notice the configuration option is called is babelOptions instead of babelConfig (which is used internally by vue-jest). I originally had called it babelConfig for consistency with the rest of the vue-jest source code, but changed it.

I decided to make the external interface align closer with the nomenclature used by other community tools, including babel itself.

[eddyerburgh]

This looks great, I have some thoughts on the API. I think the babelOptions object should support a string path or an object of options, similar to ts-jest tsConfig option, so it would look like this:

{
  "jest": {
    "globals": {
      "vue-jest": {
        "babelOptions": {
          "presets": [
            [
              "env",
              {
                "useBuiltIns": "entry",
                "shippedProposals": true
              }
            ]
          ],
          "plugins": [
            "syntax-dynamic-import"
          ],
          "env": {
            "test": {
              "plugins": [
                "dynamic-import-node"
              ]
            }
          }
        }
      }
    }
  }
}

Or

{
  "jest": {
    "globals": {
      "vue-jest": {
        "babelOptions":  "relative/path/to/file"
      }
    }
  }
}

Also we need full tests to check that both API options work. Other than that, looks great :)

[eddyerburgh]

Please update the API to match the ts-jest API, and add tests (not just unit) to check that both API options work. Other than that, looks great :)

[justinhelmer]

@eddyerburgh - To match the ts-jest API, it would result in a breaking change to the current default logic for vue-jest.

From the docs:

The option is babelConfig and it works pretty much as the tsConfig option, except that it is disabled by default. Here is the possible values it can take:

false: the default, disables the use of Babel
true: enables Babel processing. ts-jest will try to find a .babelrc, .babelrc.js file or a babel section in the package.json file of your project and use it as the config to pass to babel-jest processor.
{ ... }: inline Babel options. You can also set this to an empty object ({}) so that the default Babel config file is not used.

Currently, even if no configuration is provided, the default fallback logic for vue-jest is to search for babel config. This would equate to babelConfig: true as the default behavior given the changes.

So the question is,

1. Do you want me to proceed with matching the API exactly, including default behavior? This may need to result in a major version bump. Not sure if you want to go down this route.

2. Do you want me to match the API with the one difference being the default behavior of true vs false?

3. What about the current babelRcFile config? If babelConfig also supports a string representation as a path to a babel config file, then babelRcFile would be repetitive. Are you suggesting removing this option as well or leaving it as-is? If removing it, that would definitely dictate a major version bump.

Also, can you clarify what you mean by "not just unit tests"? It looks to me like that's all there is

[justinhelmer]

Requested changed done, please see comments relating to final solution.

I rebased against master to get #108 which is why the "Review Changes" doesn't link to the original commit.

[eddyerburgh]

Do you want me to proceed with matching the API exactly, including default behavior? This may need to result in a major version bump. Not sure if you want to go down this route.

1. Not exactly, we should default to true

2. Do you want me to match the API with the one difference being the default behavior of true vs false?

Yes

3. What about the current babelRcFile config? If babelConfig also supports a string representation as a path to a babel config file, then babelRcFile would be repetitive. Are you suggesting removing this option as well or leaving it as-is? If removing it, that would definitely dictate a major version bump.

I think we should deprecate the option as part of this work. To deprecate it, we need to remove it from the docs and add a warning when the method is called (without removing functionality).

I also think we should keep the API the same between tsConfig and babelConfig. Could you also deprecate the tsConfigFile option, and add a new tsConfig file option that behaves the same way?

Sorry for the amount of work, but you highlighted an issue with our globals design and I think we should address it now. Also, the next release will be a major due to this PR which changes the behavior of the babelrc lookup

[justinhelmer]

Sure, no worries. I was coming to the same conclusion.

[justinhelmer]

Requested changes in place.

Build will fail, because there is a prerequisite on #113

[justinhelmer]

@eddyerburgh - rebased against #113; should be good to merge.

[eddyerburgh]

Good work :)

[eddyerburgh]

Hey @justinhelmer I decided that we should just let ts-jest and babel-jest handle compiling, like you suggested. Would you like to work on ts-jest integration?

[justinhelmer]

@eddyerburgh - I believe you are referring to #114 .

Unfortunately I don't have the bandwidth right now to take on this challenge. It might change in the future if someone else doesn't take this on, but I don't want to be a bottleneck for delivery.