🐛 amazon-cognito-identity-js dependency unresolved

[dfrkp]

🐛 BUG
When using parcel in a react project that also uses aws-amplify, parcel fails to resolve the dependency for amazon-cognito-identity-js even though it is correctly placed in node_modules/ by yarn.

Here is a repository with a minimal setup to reproduce the problem: /~https://github.com/dfrkp/parcel-test

🤔 Expected Behavior

A bundle is created even if aws-amplify is used.

😯 Current Behavior

$ yarn start                                                                                                                                                                                                                                                       [13:38:01]
  yarn run v1.5.1
  $ parcel index.html
  Server running at http://localhost:1234
🚨  /Users/user/Development/parcel-test/node_modules/aws-amplify/lib/Common/Facet.js:20:22: Cannot resolve dependency 'amazon-cognito-identity-js'
  18 | var AWS = require("aws-sdk/global");
  19 | exports.AWS = AWS;
> 20 | var Cognito = require("amazon-cognito-identity-js");
     |                       ^
  21 | exports.Cognito = Cognito;
  22 | var Pinpoint = require("aws-sdk/clients/pinpoint");
  23 | exports.Pinpoint = Pinpoint;

🌍 Environment

Software	Version(s)
Parcel	1.6.2
Node	9.9
Yarn	1.5.1
Operating System	macOS

[gnijuohz]

This happens because parcel tries to load the module from es/index.js instead of lib/index.js, see

parcel/src/Resolver.js

Lines 220 to 224 in fc041d0

	getPackageMain(pkg) {
	// libraries like d3.js specifies node.js specific files in the "main" which breaks the build
	// we use the "module" or "jsnext:main" field to get the full dependency tree if available
	let main = [pkg.module, pkg['jsnext:main'], pkg.browser, pkg.main].find(
	entry => typeof entry === 'string'

However, the es folder doesn't exist.

IMO this is a bug from amazon-cognito-identity-js since that folder should be there. There is an issue reported there about this: aws-amplify/amplify-js#517

Parcel could try to see if the entry specified by "module" or "jsnext:main" exists or not first but I feel like that's not necessary.

[simonbuchan]

If you're going the extra mile, reporting the actual missing file (and why it was used) would be better than falling back to the first existing file, if that's what you meant.
A stronger motivation for fixing this would be monorepos - where it would make it clear you just haven't built yet, rather than that resolution is broken.