[Dicussion] require.resolve caching

We [noticed in eyeglass](https://github.com/sass-eyeglass/eyeglass/pull/189) and [ember-cli](https://github.com/ember-cli/ember-cli/pull/7813) that repeated calls to `require.resolve` can be costly as it can introduce unexpected IO. [I also noticed, that NodeJsImporter](https://github.com/linkedin/css-blocks/pull/196/files#r238795467) introduced recently, may have a similar issue.

My goal here is to have the discussion to ensure css-blocks does not share this problem and that I have not done any testing, so I have no evidence of an issue.

Given that, I figured we should have the discussion here to decide if:

* the problem transfers/is at all relevant to css-blocks
* if so, what constraints are we ok with
* a path forward
* is there a different problem worth solving that address the motivation (wasteful cycles spent during build)

----

### Some Potential Constraints One may be able to rely on

css-blocks, right now operates in the node ecosystem, using `require.resolve` to ensure valid node resolution semantics. Node also uses `require.resolve` under the hood to resolve `require`, with the exception that it caches the result of `require`. This accomplishes two things:

* ensures the result of `require` is frozen given its inputs
* ensures the cost per unique require only occurs once
* does provide an "Escape hatch" for power users to evict the cache.

For css-blocks, it would likely need the ability to evict a cache on a per build basis, ensuring no stale reads occur when someone expects new artifacts to be found.

---

Thoughts?

Start by reviewing the NodeJsImporter and the css-blocks call sites that use require.resolve, then compare their behavior with the eyeglass and ember-cli examples linked in the issue. Done means establishing whether repeated resolution causes wasteful build IO, documenting acceptable cache invalidation constraints, and proposing a path forward.

Written by the indexing model from the issue text.