CAF: Can't use with create-react-app

Hello, I tagged you on Twitter about this a few days ago, but I figured it was okay to open an issue here. I feel like create-react-app is used by enough people (80k stars on GitHub) that it’s worth looking into this issue.

How to reproduce the error

Make a new create-react-app app:

npx create-react-app my-test-app
cd my-test-app

Install caf:

npm install caf

Include caf in any /src file – say App.js – as specified in the readme:

var CAF = require("caf");

Save the changes and run the app:

npm start

Observe the following error, when running locally:

Error: Cannot find module '/dist/abortcontroller-polyfill-only.js'

Or observe the following error when running on CodeSandbox:

ModuleNotFoundError
Could not find module in path: 'caf/dist/abortcontroller-polyfill-only.js' relative to '/node_modules/caf/index.js'

CodeSandbox for convenient testing

https://codesandbox.io/s/frosty-tree-cwe5z


I’ll post comments here as I try to figure out how to fix the issue.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 28 (13 by maintainers)

Most upvoted comments

Hi friends! Not from either project’s respective teams, but drove by the convo on Twitter and the problem looked familiar, so figured I’d take a stab.

If I’m looking at this right:

package.json has browser set to ./src/caf.js. That file doesn’t exist though - src/caf.src.js does.

When webpack is searching for the entry point in package.json, it looks at fields based on the resolve.mainFields config. CRA does not customize the mainFields setting, so it’ll use webpack defaults, which are ['browser', 'module', 'main'].

When webpack’s resolver doesn’t find src/caf.js (wrong filename) when looking at the browser key, it falls back to the other fields in order (how enhanced-resolve works, used by webpack). For this package, that would be the main field, pointing to index.js in the root. That file is doing a require on the polyfill, which would likely yield the behavior y’all are seeing.

I can’t reproduce the issue anymore 🎉 . I think I might have experienced before because I had caf in devDependecies and peerDependencies. Moving it to dependencies where it probably should be seems to have solved the problem. No need to create new issue I think.

@getify I could have been more specific, sorry about that.

I’ll investigate more.

I’m developping a vue plugin that uses CAF. The issue already appears when I try to create a production build with vuepress - which I use for the addon documentation.

I’ll also test if the error is present in a vue app that consumes the vue plugin.

I’ll create an issue afterwards.

Sorry, I guess I was confused. It seems you have a separate problem. This issue was about needing to change what the browser field points to, which I was happy to accommodate since it seemed to fix CRA.

But you’re saying that vue needs the main to change as well, and that’s different. You could file a separate issue for that so we could explore what’s wrong with vue’s tooling, but main is not going to be changed to point at the src file… it’s intentionally set to point at the index.js because it’s including the polyfill for the benefit node users. Seems like vue’s tooling needs to be fixed (or differently configured).

Just released v9.0.0. Hopefully this is resolved now! Please let me know.

So it’s more canonical/correct/expected to point it at src/caf.src.js, it seems. Agreed that this is the best fix here?

Yep! Agreed.

I’ll have to take some time to digest what you said. And I think this all might be above my pay-grade to comment on productively. But I want to say some things, for now, just in case they’re helpful.

  1. It might be that CRA and/or webpack don’t like the entry point of a package being in the /src directory. As a layman, I would expect the entry point to always be somewhere in the /dist or /build folder, as that’s where the compiled/bundled/finalized package gets put.
  2. Here is a very quick and dirty test of what this library could look like using ES6 imports and a simpler build configuration: https://github.com/vincerubinetti/CAF It at least seems to get included and exposed properly using it in a different project ("caf": "git+https://github.com/vincerubinetti/CAF#master"). Haven’t fully tested it yet though.
  3. Trying to figure out what was going on in this library’s configuration was very difficult for me to understand, and I have to believe there’s an easier way to set it all up. And perhaps some of the things you’ve tried to include, like your Note: above, add complexity that isn’t worth the value it adds. Even if you want to keep it, there might be a less confusing way to set it all up.
  4. Even if you don’t want to do 4, using the newer import/export syntax over the UMD/require/etc stuff where possible might be easier to read and debug for simpletons like me. Assuming you can still compile everything with enough backwards compatibility. In general, I do tend to find that the newer ES6+ ways to do things are easier to read and a little less verbose.
  5. I agree that JS tooling, and hell everything about the web ecosystem, is an adhoc convoluted mess. I can sympathize with your frustration.

Perhaps it’d be valuable to show you the contents of the /dist folder files

Those are minified files so I’m not 100% sure, but it sure seems at a glance like the files are correct as expected. Both those files look to me like how CAF’s build tool creates them, not as having been modified from CRA/webpack.