Parcel reporting errors for an ES6 import that was already fixed

[paharvey]

🐛 bug report

parcel build is finding an error with an ES6 import statement, but after we fix the import statement the error continues to be reported. Parcel is even quoting the corrected line with the old error message.

This issue was discovered on an internal company project but we've produced a minimal test case (link below).

🎛 Configuration (.babelrc, package.json, cli command)

package.json

{
  "name": "test-case",
  "version": "1.0.0",
  "source": "src/index.js",
  "dependencies": {
    "lodash-es": "*"
  },
  "devDependencies": {
    "@parcel/config-default": "^2.9.3",
    "parcel": "2.9.3"
  }
}

bug.sh

A longer version of this script is in the provided repo, but this shorter one may help describe the issue.

#!/bin/sh

# Remove all caches
rm -rf node_modules .parcel_cache dist

# Do first build, passes correctly
npm install
npm exec parcel build

# Break a specific import statement, do second build, fails correctly
sed -i 's_lodash-es_./other.js_' src/main.js
npm exec parcel build

# Fix that specific import statement, do third build, fails :(
sed -i 's_./other.js_lodash-es_' src/main.js
npm exec parcel build

🤔 Expected Behavior

If we attempt to import something from the wrong file or module, parcel build is correctly flagging it. However, after we fixed the import line, we expected that parcel build would no longer flag that as an error.

For example, we had something like import { Thing } from './file.js' when it should have been import { Thing } from 'some-module'. After we fixed the import we expected that parcel build would no longer flag that import line.

😯 Current Behavior

Parcel continues to flag the fixed import line as an error. It even quotes the fixed line while reporting the original error. In the sample below, Parcel is complaining that src/other.js does not export a function, but then quotes the fixed source code where we are now importing from lodash-es.

Build failed.

@parcel/core: src/other.js does not export 'chunk'

  ./ParcelCacheBug/src/main.js:1:10
    > 1 | import { chunk } from 'lodash-es';
    >   |          ^^^^^
      2 |
      3 | export function main() {

💁 Possible Solution

Removing .parcel-cache, disabling the Parcel cache, or touching package.json all seem to workaround the issue. These are not proper fixes though.

Testing suggests that the issue does not occur in 2.0.0-nightly.1265 (2023-03-25) but does occur in 2.0.0-nightly.1271 (2023-03-27), and it does occur in all 2.9.0 - 2.9.3 releases. Presumably the issue was introduced in some commit between 2023-03-25 and 2023-03-27.

🔦 Context

We have disabled the Parcel caching mechanism for now, which increases load on our CI system. We have a large-ish monorepo, so we would really likely to re-enable Parcel's caching.

💻 Code Sample

https://github.com/paharvey/parcel-cache-bug/

🌍 Your Environment

We have replicated this on multiple systems, include Linux, Windows, and MacOS. We tend to use Yarn internally but the minimal test case provided above uses npm. Replication does seem to require Parcel 2.9.0 - 2.9.3 (more accurately, Parcel 2 from 2023-03-27 onwards).

The following are specific versions from a Linux system.

Software	Version(s)
Parcel	2.9.0 - 2.9.3
Node	20.5.1
npm	9.8.0
Operating System	22.04.1-Ubuntu

[mischnic]

Presumably the issue was introduced in some commit between 2023-03-25 and 2023-03-27.

#8723 fits the merge date and also your description of the bug

[paharvey]

Can we assume that this caching bug only impacts cached errors? Or is there a risk of it impacting the output of successful builds? I'm only asking so we know whether to re-enable Parcel's caching mechanism. Thanks for all the work on Parcel.

[paharvey]

I've updated the sample repository to use Parcel 2.10.3. The bug still occurs there.

[paharvey]

I've updated the sample repository to use Parcel 2.11.0 now. The bug still occurs there.

[paharvey]

I've updated the sample repository to use Parcel 2.12.0. The bug still occurs there.

[paharvey]

I've updated the sample repository to use Parcel 2.13.0. The bug still occurs there but required longer repro steps.

We now need to alternate back and forth between "correct" and "incorrect" code a couple of times to trigger the bug.