Parcel 2: mainFields ordering leads to duplicated dependencies in bundle

[speigg]

🐛 bug report

When running parcel serve, by default the mainFields order (unexpectedly) appears to be:

["source", "browser", "main", "module"]

This ordering can lead to broken builds when importing standalone esm modules from packages that also include main and module entries. For example, the three package defines main entry as "/build/three.js" and module entry as "/build/three.module.js", whereas the standalone modules in "three/examples/jsm/**/*" import from`three.module.js".

// wrongly adds 'three/build/three.js' instead of  'three/build/three.module.js'
import * as THREE from 'three';

// adds 'three/build/three.module.js'
import { OrbitControls } from 'three/examples/jsm/controls/OrbitControls.js';

So when the main entry is prioritized over module, both entries (one bundled and the other unbundled) end up being included in the same application. These duplicated dependencies can cause subtle and very hard to track down problems due to (for example) duplicate singleton instances being referenced (each with their own state) in different places as if they were the same instance. I would expect that only build/three.module.js is included.

More so, due to an inconsistency in behavior related to the scopeHoist option between parcel serve and parcel build, this problem only occurs when running parcel serve.
When running parcel build, the scopeHoist option is enabled which changes the mainFields order to the (more reasonable/expected):

["source", "browser", "module", "main"]

I would expect to have module preferred over main in all cases (by default), which would enable nested esm imports in threejs to work consistently.

[mischnic]

in all cases (by default

You have probably seen the comment in the sourcecode?

parcel/packages/resolvers/default/src/DefaultResolver.js

Lines 20 to 21 in afc2c9e

	// If scope hoisting is enabled, we can get smaller builds using esmodule input, so choose `module` over `main`.
	// Otherwise, we'd be wasting time transforming esmodules to commonjs, so choose `main` over `module`.

[speigg]

@mischnic right, that's what I'm referring to when I say that the current behavior is to choose main over module when running parcel serve (since parce serve does not enable scope hoisting). I would expect the default behavior to be consistently that module always has priority over main whether running parcel serve or parcel build.

[speigg]

bump

[wbinnssmith]

@devongovett @mischnic maybe we should discuss this now that transformation is faster? Should probably back it up with performance metrics.