Cannot resolve dependency, but file exists #1986

timglabisch · 2018-09-05T07:14:48Z

❔ Question

i don't understand why pacel could not resolve a dependency.

when i run parcel build index.html i get the error

/Users/tim/proj_/parcel-example/index.html: Cannot resolve dependency '/Users/tim/proj_/parcel-example/index.js' at '/Users/tim/proj_/parcel-example/index.js'

but the file exists:

➜  parcel-example  cat /Users/tim/proj_/parcel-example/index.js
console.log("ok");

why pacel could not resolve the dependency?

🔦 Context

i debugged a little bit and it seems that pacel resolves the path as /Users/tim/proj_/parcel-example/Users/tim/proj_/parcel-example/index.js

the function

parcel/src/Resolver.js

Line 121 in a330668

resolveFilename(filename, dir) {

is called twice, first call

‌‌this.options.rootDir
‌/Users/tim/proj_/parcel-example

‌‌filename.slice(1)
‌index.js

i expected this path as result, but parcel goes on and does a second call:

‌‌this.options.rootDir
‌/Users/tim/proj_/parcel-example

‌‌filename.slice(1)
‌Users/tim/proj_/parcel-example/index.js

which will result in ‌/Users/tim/proj_/parcel-example/‌Users/tim/proj_/parcel-example/index.js

💻 Code Sample

index.html

<html>
<body>
  <script src="/index.js"></script>
</body>
</html>

index.js

console.log("ok");

🌍 Your Environment

Software	Version(s)
Parcel	1.9.7
Node	v10.9.0
npm	6.2.0
Operating System	osx and ubuntu

The text was updated successfully, but these errors were encountered:

chocolateboy · 2018-09-05T15:57:07Z

Parcel	`876bfe2` (same error on 1.9.7)
Node	v10.9.0
OS	Linux (Arch)

Here's an example of the stack traces I get for the first and second call to resolveFilename for the same asset:

Good:

Trace: XXX resolving filename: /src/js/index.js
    at Resolver.resolveFilename (/home/user/build/parcel/src/Resolver.js:122:13)
    at HTMLAsset.addURLDependency (/home/user/build/parcel/src/Asset.js:104:42)
    at HTMLAsset.processSingleDependency (/home/user/build/parcel/src/assets/HTMLAsset.js:95:26)
    at ast.walk.node (/home/user/build/parcel/src/assets/HTMLAsset.js:157:43)
    at traverse (/home/user/build/parcel/node_modules/posthtml/lib/api.js:105:26)
    at traverse (/home/user/build/parcel/node_modules/posthtml/lib/api.js:111:5)
    at traverse (/home/user/build/parcel/node_modules/posthtml/lib/api.js:105:17)
    at traverse (/home/user/build/parcel/node_modules/posthtml/lib/api.js:111:5)
    at traverse (/home/user/build/parcel/node_modules/posthtml/lib/api.js:105:17)
    at Array.walk (/home/user/build/parcel/node_modules/posthtml/lib/api.js:39:10)
XXX resolved filename: /home/user/build/parcel-test/src/js/index.js

Bad:

Trace: XXX resolving filename: /home/user/build/parcel-test/src/js/index.js
    at Resolver.resolveFilename (/home/user/build/parcel/src/Resolver.js:122:13)
    at Resolver.resolveModule (/home/user/build/parcel/src/Resolver.js:84:23)
    at Resolver.resolve (/home/user/build/parcel/src/Resolver.js:59:29)
    at Bundler.resolveAsset (/home/user/build/parcel/src/Bundler.js:409:38)
    at Bundler.resolveDep (/home/user/build/parcel/src/Bundler.js:460:25)
    at Promise.all.dependencies.map (/home/user/build/parcel/src/Bundler.js:583:37)
    at Array.map (<anonymous>)
    at Bundler.loadAsset (/home/user/build/parcel/src/Bundler.js:575:20)
XXX resolved filename: /home/user/build/parcel-test/home/user/build/parcel-test/src/js/index.js

The error occurs when either prefix is used — i.e. tilde (~) or forward slash (/) — and for every asset type I've tried (.html, .scss, .svg, .ts):

/home/user/build/parcel-test/index.html: Cannot resolve dependency '/home/user/build/parcel-test/src/js/index.js' at '/home/user/build/parcel-test/src/js/index.js'

chocolateboy · 2018-09-05T22:41:59Z

Related/Duplicates:

peanutbother · 2018-09-06T09:14:35Z

Did you notice in your index.html you are referencing index.js as absolute path

<script src="/index.js"></script>

did you mean to write

<script src="./index.js"></script>

What happens if you try to import your assets relatively? (like the one above)

Could you please provide a repo?

peanutbother · 2018-09-06T09:17:17Z

Also I don't think this is a sass related issue like in #1555 because sass handles file paths differently (sass can use .sassrc for resolving algorithm)

chocolateboy · 2018-09-06T09:33:38Z

Did you notice in your index.html you are referencing index.js as absolute path

As of #850, absolute paths (i.e. paths starting with a slash) are supposed to be resolved against the project root, and paths starting with a tilde are supposed to resolve against the package root (i.e. the nearest node_modules subfolder) or project root (whichever comes first):

Parcel (v1.7.0 and above) supports multiple module resolution strategies out of the box so you don't have to deal with endless relative paths `../../`.

chocolateboy · 2018-09-06T09:42:09Z

Also I don't think this is a sass related issue like in #1555

#1555 is not a Sass-specific issue. The asset isn't being loaded with an @import from a .scss file. It's a Parcel dependency and the same error occurs with other asset types e.g.:

.html
.scss
.svg
.ts

chocolateboy · 2018-09-06T10:07:51Z

Could you please provide a repo?

There's one provided in #1555, but I've just pushed another version which reproduces the error with a plain JavaScript asset here.

peanutbother · 2018-09-06T10:33:08Z

I tested both repos and both examples worked as intended. I had no errors.
parcel v1.9.7, yarn v1.9.4

peanutbother · 2018-09-06T10:41:37Z

What I just noticed is, that in your issue you mention two different paths in the stacktrace:

Trace: XXX resolving filename: /src/scss/index.scss
    at Resolver.resolveFilename (/home/user/build/parcel/src/Resolver.js:123:13)
  [...]
XXX resolved filename: /home/user/dev/my-project/src/scss/index.scss

one path starting with /home/user/build/ and one /home/user/dev/
I guess build is a subdirectory of /home/user/dev/my-project which would lead me to conclusion that the path might got merged by two levels too high, resulting in filepaths missing dev/my-project

if that is the case, the output files should got to /home/user/dev/my-project/build/

can you explain why there are different paths?

chocolateboy · 2018-09-06T10:44:24Z

can you explain why there are different paths?

I've updated the stack traces to reflect the error from the minimal test case.

chocolateboy · 2018-09-06T10:49:51Z

I tested both repos and both examples worked as intended. I had no errors.

Which OS and node version?

peanutbother · 2018-09-06T10:52:54Z

I can still see two different path, now:

Trace: XXX resolving filename: /src/js/index.js
    at Resolver.resolveFilename (/home/user/build/parcel/src/Resolver.js:122:13)
    [...]
XXX resolved filename: /home/user/build/parcel-test/src/js/index.js

I guess you are using your own local-linked version of parcel-bundler?
did you try to build with the npm-version of parcel-bundler?

Which OS and node version?

Node: 10.4.0
OS: Windows 10 [10.0.17134.228]

chocolateboy · 2018-09-06T10:57:44Z

did you try to build with the npm-version of parcel-bundler?

Yes. I get the same error with the stock v1.9.7 release. ~/build/parcel is just a checkout of parcel's git repo.

peanutbother · 2018-09-06T10:59:43Z

just to make sure...
if you local-linked your own version, try unlinking it and install parcel locally. after that run the yarn dev command again. if that works, there you might have forgotten to unlink parcel properly.

chocolateboy · 2018-09-06T11:12:39Z

I'm not npm-linking the git version of parcel. I'm just using a symlink:

$ ln -s ~/build/parcel/bin/cli.js ~/bin/parcel-dev
$ parcel-dev watch index.html

But, like I say, the same error occurs with the released version. I'm only using the git version to troubleshoot this issue.

I've just installed node v10.4.0, and get the same error. Maybe it's an OS issue?

peanutbother · 2018-09-06T11:24:57Z

That's weird. despite I would never symlink any npm package on my own but use npm link / yarn link, that might not be the issue for this behaviour.
I will try to reproduce this on an Ubuntu host.

chocolateboy · 2018-09-06T11:31:24Z

I would never symlink any npm package on my own but use npm link / yarn link

It's the way that's recommended in the contributing guidelines (the shebang uses /usr/bin/env, so the wrapper/alias isn't needed) :-)

Thanks for your help btw 👍

peanutbother · 2018-09-06T12:17:01Z

My Ubuntu / WSL installation also fails with same errors:

https://github.com/absentees/parcel-test

$ parcel watch index.html
🚨  /c/Projekte/forks/absentees-parcel-test/index.html: 
Cannot resolve dependency '/c/Projekte/forks/absentees-parcel-test/src/css/main.scss'
 at '/c/Projekte/forks/absentees-parcel-test/src/css/main.scss'
 at Resolver.resolve (/c/Projekte/forks/absentees-parcel-test/node_modules/parcel-bundler/src/Resolver.js:69:17)

https://github.com/chocolateboy/parcel-test

$ parcel watch index.html
🚨  /c/Projekte/forks/chocolateboy-parcel-test/index.html: 
Cannot resolve dependency '/c/Projekte/forks/chocolateboy-parcel-test/src/js/index.js' 
  at '/c/Projekte/forks/chocolateboy-parcel-test/src/js/index.js'
  at Resolver.resolve (/c/Projekte/forks/chocolateboy-parcel-test/node_modules/parcel-bundler/src/Resolver.js:69:17)

Node: 10.4.0
Yarn: 1.9.4
OS: WSL (Debian 9.3) 4.4.0-17134-Microsoft
running on: Windows 10 [10.0.17134.228]

chocolateboy · 2018-09-06T18:17:17Z

From what I can gather (someone correct me if I'm wrong), it looks like there are (at least) two passes over each dependency:

parsing/discovery: an asset-specific parser/processor discovers each dependency e.g. src/assets/HTMLAsset.js uses PostHTML to detect links to scripts, stylesheets etc. in HTML files. This is where the dependency objects originate and is represented by the "Good" stack trace above.
processing/bundling: an additional pass by the app itself (i.e. src/Bundler.js) processes the tree of dependencies discovered by the first pass. This is represented by the "Bad" stack trace above.

The dependency objects produced by the first pass only contain a few fields (at least to start with) e.g.:

{
    name: '/home/user/build/parcel-test/src/js/index.js',
    parent: '/home/user/build/parcel-test/index.html'
}

Note that the name, which appears as /src/js/index.js in the HTML, is resolved to its absolute path in the dependency object. However, the second pass is unaware of this, and blithely re-resolves the path.

An easy fix would be to add a field to the dependency which indicates that it has already been resolved e.g.:

{
    name: '/home/user/build/parcel-test/src/js/index.js',
    parent: '/home/user/build/parcel-test/index.html',
    resolved: true,
}

But it turns out this is already supported (in a slightly different form)! The processing/bundling pass checks each dependency object's resolved field for an absolute path (in Bundler#resolveDep) and uses that if it's available. It's just not being set when these dependencies are resolved in the first pass.

Adding that field (in Asset#addURLDependency) fixes this issue for me:

{
    name: '/home/user/build/parcel-test/src/js/index.js',
    parent: '/home/user/build/parcel-test/index.html',
    resolved: '/home/user/build/parcel-test/src/js/index.js',
}

I've raised a PR for this here. Let me know if there are any issues.

Fix "Cannot resolve dependency" errors for valid slash and tilde paths. Before: /src/js/index.js -> /home/user/my-project/src/js/index.js -> /home/user/my-project/home/user/my-project/src/js/index.js Error: Cannot resolve dependency /home/user/my-project/src/js/index.js After: /src/js/index.js -> /home/user/my-project/src/js/index.js The code already has a way for asset-handlers to signal to the bundler that a dependency has been resolved to an absolute path, but it isn't being used. fixes #1555 fixes #1986

tadinski · 2020-07-09T23:57:58Z

issue still exists

kevinhaas · 2020-09-02T16:24:51Z

Yes it does. I'd suggest moving to webpack, it's a much better experience. They seem to just ignore issues in this repo and mark stuff closed that is clearly still an issue.

mischnic · 2020-09-02T17:03:12Z

They seem to just ignore issues in this repo and mark stuff closed that is clearly still an issue.

This issue was closed because it was fixed (at the time). If it happens again, there might be a different cause (= new issue).

Clingonboy · 2020-11-08T17:03:39Z

I have the same problem

Server running at http://localhost:1234
🚨 /home/uge/Sandbox/webgame/foracciodue/src/game.js:1:21: Cannot resolve dependency './player' at '/home/uge/Sandbox/webgame/foracciodue/src/player'

1 | import {Player} from './player'
| ^
2 |
3 | export class Game {
4 | constructor (cards) {

ffigiel · 2020-11-20T14:27:06Z

If it helps, note that ~ resolves to the directory of your entry point. so if you have

.
└── src
    ├── app
    │   ├── ...
    └── index.html

and run parcel src/index.html, you should import ~/app/..., not ~/src/app/...

ctjlewis · 2021-12-17T05:44:57Z

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.

DeMoorJasper added the ❔ Question label Sep 5, 2018

chocolateboy mentioned this issue Sep 6, 2018

Don't resolve slash and tilde paths twice #1993

Merged

DeMoorJasper closed this as completed in #1993 Sep 6, 2018

anivle mentioned this issue Dec 18, 2019

Parcel does not resolve asset by absolute path #3929

Closed

This comment has been minimized.

Sign in to view

ctjlewis mentioned this issue Dec 17, 2021

Bug report: Cannot build inside subdir root #7462

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cannot resolve dependency, but file exists #1986

Cannot resolve dependency, but file exists #1986

timglabisch commented Sep 5, 2018 •

edited

chocolateboy commented Sep 5, 2018 •

edited

chocolateboy commented Sep 5, 2018 •

edited

peanutbother commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018 •

edited

chocolateboy commented Sep 6, 2018

chocolateboy commented Sep 6, 2018 •

edited

peanutbother commented Sep 6, 2018

peanutbother commented Sep 6, 2018 •

edited

chocolateboy commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018 •

edited

chocolateboy commented Sep 6, 2018

This comment has been minimized.

tadinski commented Jul 9, 2020

kevinhaas commented Sep 2, 2020

mischnic commented Sep 2, 2020

Clingonboy commented Nov 8, 2020

ffigiel commented Nov 20, 2020

ctjlewis commented Dec 17, 2021 •

edited

Cannot resolve dependency, but file exists #1986

Cannot resolve dependency, but file exists #1986

Comments

timglabisch commented Sep 5, 2018 • edited

❔ Question

🔦 Context

💻 Code Sample

🌍 Your Environment

chocolateboy commented Sep 5, 2018 • edited

chocolateboy commented Sep 5, 2018 • edited

peanutbother commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018 • edited

chocolateboy commented Sep 6, 2018

chocolateboy commented Sep 6, 2018 • edited

peanutbother commented Sep 6, 2018

peanutbother commented Sep 6, 2018 • edited

chocolateboy commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018

chocolateboy commented Sep 6, 2018

peanutbother commented Sep 6, 2018 • edited

chocolateboy commented Sep 6, 2018

This comment has been minimized.

tadinski commented Jul 9, 2020

kevinhaas commented Sep 2, 2020

mischnic commented Sep 2, 2020

Clingonboy commented Nov 8, 2020

ffigiel commented Nov 20, 2020

ctjlewis commented Dec 17, 2021 • edited

timglabisch commented Sep 5, 2018 •

edited

chocolateboy commented Sep 5, 2018 •

edited

chocolateboy commented Sep 5, 2018 •

edited

chocolateboy commented Sep 6, 2018 •

edited

chocolateboy commented Sep 6, 2018 •

edited

peanutbother commented Sep 6, 2018 •

edited

peanutbother commented Sep 6, 2018 •

edited

ctjlewis commented Dec 17, 2021 •

edited