Allow macro config to come from plugin options in babel config.

[conartist6]

Fixes #112

I'm missing test coverage, but I'm also not familiar with the way this test environment is set up. Some tips on how to test this well would be appreciated.

[conartist6]

I don't know why it did this. Maybe you hadn't run the newest version of your kcd-scripts formatter on this file?

[conartist6]

Never mind I figured out how to write the tests. Should be ready to go.

[conartist6]

Whoops, forgot to git add a folder. Should really be ready to go.

[conartist6]

So I appreciate the comment, but maybe phobia was the right word for what influenced this decision. First, if you must synchronously load cosmiconfig no matter what I don't see how you can gain anything useful by doing it later, unless of course it turns out that babel-plugin-macros is loaded but no macros are used (which hardly seems like the case to optimize for).

Second, in optimizing for that case, you've actually hurt performance for the common case significantly. If you read the cosmiconfig docs you'll see that its caches are internal to the explorer object. You create a new explorer every time you process a file, so you are also doing a full config search every time you process a file, which is far more costly in the common case than what you were trying to avoid.

It's easy to refactor the code, but it seems like it'll be a bit tricker to fix the tests.

[conartist6]

Actually I suppose we can have the best of both worlds if we lazy load and cache the explorer

[conartist6]

This is done now.

[conartist6]

I've added some more or less unrelated changes, but I've split them out into separate commits.

When trying to debug the tests I discovered that most tests assertion output was silently discarded.
I also found that failing objectContaining assertions where the actual object contains babel were printing output so long that they were obscuring useful output by pushing it completely out of my 1000 line terminal scrollback.

[kentcdodds]

I'd prefer babel.config.js and babel-plugin-macros.config.js rather than .babel.config.js and .babel-plugin-macros.config.js

[conartist6]

Are we sure we want the plugin option to override the config version. It feels more intuitive to me that it would be the other way around.

That makes sense to me too now that I think about it since the file config can be more granular -- there could be different files for different directories. I've added that change.

[kentcdodds]

Awesome. Thanks for this :)

[kentcdodds]

@all-contributors please add @conartist6 for code, tests, and docs

[allcontributors]

@kentcdodds

I've put up a pull request to add @conartist6! 🎉

[kentcdodds]

🎉 This PR is included in version 2.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[conartist6]

Awesome! Thanks! By the way, I realized that something I said was wrong. It definitely does make sense for macros to optimize for the case where it isn't being used, because one of its goals is to allow people who don't have control over their transpilation environment access to the power of transformations. That means it is a reasonable expectation that it will be added to quite a few projects that won't use it at all.

[InvictusMB]

@conartist6 @kentcdodds
Shouldn't the options also be passed in another applyMacros invocation?

babel-plugin-macros/src/index.js

Lines 146 to 154 in d11217e

	const result = applyMacros({
	path: call,
	imports,
	source,
	state,
	babel,
	interopRequire,
	resolvePath,
	})

[kentcdodds]

Could you open a new issue and/or a pull request with a failing test? Thanks!

[conartist6]

@InvictusMB You are right. It would affect macros meant to be configured via plugin options which are imported with const { sym } = require('path/to/macro'). Nice catch.

[conartist6]

I have created #120 with the repro and fix for this issue.