Parcel v2 scope hoisting fails on one file

[MaffooBristol]

🐛 bug report

This is a regression for Parcel v2, as it was fine in v1.

One file within my entire multi-build repo is failing to hoist.

> TARGET=business parcel build src/business.html --dist-dir dist/business/ --no-source-maps --cache-dir .cache/business/

🚨 Build failed.
@parcel/packager-js: No reachable bundle found containing src/business/state/selectors/getAnswersForQuestionSelector.js

There is nothing at all different about this file than any of the other many reselect selectors within the codebase. It is linked to by other files and is reachable by the entry point.

I've checked if it's a filename case-sensitivity issue but appears to not be.

Running with --no-scope-hoist fixes the issue, but it doesn't explain why it's happening.

Build environment is basic browser based.

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

Fairly standard. Multi-dist mega-repo. Uses absolute paths (eg. import foo from '/business/foo';

The only non-standard thing conf-wise is parcel-namer-rewrite and a transformer for "*.{svg,jpg,png,gif,pdf,woff,woff2,ttf,eot}": ["@parcel/transformer-raw"]

Uses a fair bit of lazy loading with Parcel's dynamic import() and React Suspense

Fails on all tested node versions, so not that. Fails on Mac and Linux, local and CI.

🤔 Expected Behaviour

The source should build perfectly fine with default hoisting

😯 Current Behaviour

As above. It struggles on that one file and no others. No observable circular dependencies (and again, has worked fine before upgrading)

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-beta.1
Node	v15.7.0
npm/Yarn	7.4.3
Operating System	MacOS 10.15.7 (Catalina) but also Bitbucket pipelines' Ubuntu

[mischnic]

Can you try using the parcel@nightly version?

[MaffooBristol]

Hi Niklas, I've been avoiding the nightly because of this:

Unfortunately I can't really test the nightly because it forces postcss@^8 and I have a load of other dependencies that are all stuck at postcss@^7

... but I'll see if I can break the other stuff to test this one bit locally

[MaffooBristol]

Hmm... Had a hack. Nightly appears to break all the absolute path stuff I have currently working on v1 and @next, so it's dying trying to build that anyway

[mischnic]

absolute path stuff in @next

What exactly doesn't work anymore in the latest nightly? May or may not be a bug in itself

[MaffooBristol]

@mischnic
I have a folder structure with multiple entry points like this:

./
  package.json
  src/
    foo/
    bar/
    shared/
    foo.html
    bar.html

foo.html loads in ./foo/index.js, bar.html loads in ./bar/index.js

Then in a file somewhere deep within foo/, a JS file will load something in /shared by going import something from '/shared/path/to/something'

If I make the entry points inside the subfolders, the absolute path convention doesn't quite work. So that's why the entries and their folders are in the same level.

This works in the next version, but in the nightly gives me @parcel/core: Failed to resolve... and @parcel/resolver-default: Cannot load file... errors

[MaffooBristol]

Update on the scope hoisting issue. One of our other build targets/dists fails at runtime with scope hoisting. This time with a index.80ead948.js:1 Uncaught ReferenceError: require is not defined in the main JS bundle. Especially strange because the other dist failed at build time.

[mischnic]

This works in the next version

Strange, both next and nightly resolve absolute paths from the project root (= the folder containing the lockfile or .git).

require is not defined

That might be related to this problem: #4634 (comment)

[MaffooBristol]

I would git bisect it, or equivalent, but it seems to have the same issue with every nightly-xxx version I tried. I'm afraid I don't quite understand the release process and exactly how often @next is updated to be able to find a point where it regresses. I'll double check it's not a caching issue first, although I'm pretty sure it's not since I periodically blitz all the various folders

[mischnic]

There's a list of nightly versions on https://www.npmjs.com/package/parcel under versions.

2.0.0-nightly.300 is the first nightly after 2.0.0-beta.1 (= next).

[MaffooBristol]

Hi mate, thanks for that info.

I've done a bit of manual bisecting and it appears the absolute path thing borks between 339 and 341

npm install -D [email protected] && rm -rf .cache && npm run build-consumer
# ......
✨ Built in 41.81s

npm install -D [email protected] && rm -rf .cache && npm run build-consumer
# .....
🚨 Build failed.
@parcel/core: Failed to resolve '/shared/util/whyDidYouRender' from './src/consumer/index.jsx'
@parcel/resolver-default: Cannot load file '../../shared/util/whyDidYouRender' in './src/consumer'.
⠧ Building es.object.get-own-property-descriptors.js..

[MaffooBristol]

Is it rootDir vs entryRoot? https://diff.intrinsic.com/@parcel/core/2.0.0-nightly.339/2.0.0-nightly.341

It used to use the actual root of the directory, now it uses the root from the entry file?

(thinking about it, root from entry file sounds like what it was already doing...)

[mischnic]

rootDir -> entryRoot was just a rename.

Except for this here: 1f558665...fce662ec#diff-f309dc0f12

So I guess I was wrong here and it wasn't already the case in the beta

both next and nightly resolve absolute paths from the project root

[MaffooBristol]

Ah okay, thanks. What is the course of action with this then? Will nightly be adjusted to act as next currently does? Let me know if there's anything I can do to help!

[mischnic]

Will nightly be adjusted to act as next currently does

No, the nightly has the intended behaviour. https://v2.parceljs.org/features/module-resolution/
Parcel 1 had the behaviour of next, but we changed it because adding another entry point could suddenly change what / resolved to. E.g.
parcel build src/foo/index.html (/ = src/foo) ->
parcel build src/foo/index.html src/bar/index.html (/ = src).

[MaffooBristol]

Ah, I see. I get that a lack of clarity with multiple entries means this technically does make sense, but it's a very confusing back and forth of paradigms between versions.

Is there any way in which I can just force parcel to assume /src/ is the root, regardless of anything else, number of entries, etc? I could change my thousands of imports to, I presume, include the src/ at the start, but I'd rather not change the main codebase so drastically just for this.

[mischnic]

1. it the JS API can set entryRoot yourself, but that isn't exposed in the parcel CLI
2. a custom resolver plugin that treats / differently (related: Offer a way to overwrite project root #5476)
3. (more of an alternative to prepending src/):

{
  "dependencies": {
  },
  "alias": {
  	"shared": "./src/shared"
  }
}

import x from "shared/b.js";

console.log(x);

[mischnic]

a custom resolver plugin that treats / differently

-> https://www.npmjs.com/package/@mischnic/parcel-resolver-root

[MaffooBristol]

@mischnic Oh wow, that's some high-speed plugin creation! Many thanks, I'll check it out

[gorakong]

hey @MaffooBristol, could you try checking out the unreachable-asset branch and see if that fixes your issue? 🙂

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.