Bug report: Cannot build inside subdir root

[ctjlewis]

I have a Next project. next export emits HTML files in ./out/. I would like to use Parcel to combine and minify the <script> content in those HTML files but unfortunately, Parcel does not seem capable of doing this.

From #1986 (comment):

Program is making bold assumptions about my project structure.

$ cd out
$ parcel build index.html

@parcel/core: Failed to resolve
'/_next/static/chunks/polyfills-5cd94c89d3acac5f.js' from
'./out/index.html'

@parcel/resolver-default: Cannot load file
'../_next/static/chunks/polyfills-5cd94c89d3acac5f.js' in
'./out'.

It's not wrong that this is a directory inside a project, but as a CLI, the project directory should be the current working directory. I do not need Parcel confusing itself about what the root directory is. Is it looking for package.json, or what? If you're going to ship logic like that, we need an escape hatch at the very least.

If you're inside ., and I feed you index.html and it contains a <script src="/_next/..." />, it is startling that you would come back to me with an error. /_next is ./_next relative to ., it's super straightforward? I would send in a PR but if this is possible this late in the software's lifecycle, I imagine it would be a waste of time.

In fact, not only does it fail with such simple resolution requests—which is remarkable—but it also causes Node to crash.

uv loop at [0x7f84f1df9ad8] has open handles:
[0x7f84e8021d98] async (active)
        Close callback: 0xefb065e62511002 
        Data: 0x7f84e8021cf0 
        (First field): 0x7f85082c38a8  [/home/christian/.config/yarn/global/node_modules/lmdb-store/prebuilds/linux-x64/node.abi83.node]
uv loop at [0x7f84f1df9ad8] has 1 open handles in total
node[614505]: ../src/debug_utils.cc:322:void node::CheckedUvLoopClose(uv_loop_t*): Assertion `0 && "uv_loop_close() while having open handles"' failed.
 1: 0xa25510 node::Abort() [node]
 2: 0xa2558e  [node]
 3: 0x9b7081  [node]
 4: 0xaddc8f node::worker::Worker::Run() [node]
 5: 0xaddcd8  [node]
 6: 0x7f850b487609  [/lib/x86_64-linux-gnu/libpthread.so.0]
 7: 0x7f850b3ae293 clone [/lib/x86_64-linux-gnu/libc.so.6]
Aborted (core dumped)

Just forwarding the report. I showed the required bug report form the same level of care and attention that was shown to the underlying logic in this issue. Feel free to close and do nothing, but it will not make the software any better.

[ctjlewis]

Making do with this hand-rolled script for now:

let src = "";

for (const script of document.getElementsByTagName('script')) {
    const scriptSrc = script.getAttribute('src');
    const scriptType = script.getAttribute('type') ?? '';

    if (scriptType.includes('json')) {
        continue;
    }
    
    if (!scriptSrc) {
        src += script.innerHTML;
    } else {
        src += await fetch(scriptSrc).then((res) => res.text()) + "\n\n";
    }
}

[devongovett]

Hey, no need to be hostile about it. We're all trying to build the best software we can. I'm sorry that it didn't work for you. 😄

/ is resolved relative to the project root directory, which is typically where your git repository or package manager lock file lives. See https://parceljs.org/features/dependency-resolution/#absolute-specifiers. It works this way so that you can run Parcel from any directory pointing at your entries and it still builds the same thing. Depending on the current working directory of your terminal wouldn't work in some cases, e.g. CI builds, or monorepos.

That said, it should be possible to use aliases to remap the /_next folder to the correct location. See https://parceljs.org/features/dependency-resolution/#glob-aliases. Something like this:

{
  "alias": {
    "./_next/**": "./out/_next/$1"
  }
}

I do hear this feature request though, and I think we could probably add a --project-root CLI option to explicitly override the default project root in the future.

[mischnic]

A resolver plugin like https://github.com/mischnic/parcel-resolver-root can also change the meaning of / for imports, without changing the project root itself which would have other effects as well.

[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.

[flaviotordini]

I just want to say that I've been hit by this in the first five minutes of evaluating Parcel. I'm trying to use Parcel in an 11ty-based project. Not a good start.

[colorincode]

This is still an issue for me.
I have a glob resolver (which, at the moment doesn't work - I had to roll it to the canary build), used ~ & $ to alias file resolution as the docs state to do for multiple targets. If you're building a basic 1-3 page app you won't really encounter it. Once your app starts to get any larger, especially with ES imports, the entry & out directories, this becomes a serious issue.

I tried several plugin resolvers (e.g. cwd relative to dir, namers etc) but often they introduce more problems than they fix.

currently am not getting it to bundle properly at all. When I was running a successful production build it was outputting something like
Index.hash.js
Index.runtime.js
Index.hasheddep1.js

So the way this resolves directories ends up breaking the tree shaking, code splitting, dependency resolution and other core functionality of parcel. Every directory (until parcel 3 is out?) has to be built as a separate app - workers are almost always failing.