deno: Parcel Bundler Error - fs.findAncestorFile

Hi I am currently running into an issue where I am following the Parcel API documentation, and currently running into a Type error as below

error: Uncaught TypeError: fs.findAncestorFile is not a function

Currently using Deno 1.27.0, I would like to find out if there is another way to use parcel with Deno ?

I am importing @parcel/core and not parcel

System Apple M1 macOS Ventura

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 25 (8 by maintainers)

Commits related to this issue

fix(napi): clear currently registering module slot (#19249) This commit fixes problem with loading N-API modules that use the "old" way of registration (using "napi_module_register" API). The slot... — committed to denoland/deno by bartlomieju a year ago
fix(node): make 'v8.setFlagsFromString' a noop (#19271) Towards https://github.com/denoland/deno/issues/16460 — committed to denoland/deno by bartlomieju a year ago

Most upvoted comments

@rawkakani, no, they will be available in v1.34.1 to be release later this week.

bartlomieju on May 28, 2023

@rawkakani That specific error has to do with Node’s V8 API. V8 is what Node and Deno use under the hood to run javascript, and for now Deno does not have a compatibility layer to directly interact with it. v8.setFlagsFromString makes changes to V8, you can’t manually implement it from within javascript land.

The fact that you are directly able to import findAncestorFile from @parcel/fs-search is interesting though, because @parcel/fs could not. I fiddled around a bit more and it turns out Deno imports different functions from @parcel/fs-search depending on how/where it is imported.

Via another npm package

Screenshot (11)

Directly via an npm specifier

Screenshot (12)

lilnasy on Nov 22, 2022

I believe the error you are seeing is the same problem as #18334 is trying to fix.

okay awesome thank you, is it cool to close this issue and watch the PR you mentioned

rawkakani on May 30, 2023

Thanks @marvinhagemeister! I just spotted the error here, will fix it at first convenience.

bartlomieju on May 25, 2023

I think I found a clue. Was logging all exports when a native addon is loaded and noticed that @parcel/watcher/prebuilds/darwin-arm64/node.napi.glibc.node is loaded just before the one that has wrong exports. The load order is:

@parcel/source-map/parcel_sourcemap_node/artifacts/index.darwin-arm64.node - Correct
@parcel/hash/parcel-hash.darwin-arm64.node - Correct
@parcel/watcher/prebuilds/darwin-arm64/node.napi.glibc.node - Correct
@parcel/fs-search/fs-search.darwin-arm64.node - WRONG, returns exports from node.napi.glibc.node

Screenshot of the exports:

Logging out the v8 pointer confirms that both node.napi.glibc.node and fs-search.darwin-arm64.node share the same address. Somehow it seems that deno returns the same pointer for two different modules. Comparing the exports and the packages confirms that the returned API belongs to @parcel/watcher and not @parcel/fs-search.

marvinhagemeister on May 24, 2023

The issue seems to be with the experimental Node API support. @parcel/fs re-exports a few functions from @parcel/fs-search which is an NAPI library. At least 3 of the functions that @parcel/fs expects from require("@parcel/fs-search") are missing, including findAncestorFile.

lilnasy on Nov 19, 2022