Doesn't work with yarn workspaces

[PaulRBerg]

Description

I followed the tutorial and I made it work with the example subgraph, but I encountered the following error when I switched to a monorepo maintained with lerna + yarn workspaces:

Failed to compile subgraph: Failed to compile data source mapping: Import file '~lib/@graphprotocol/graph-ts.ts' not found.

Of course, I made sure I have all the dependencies installed and I confirmed by that by looking into the node_modules folder at the root of the repo. I suspect that's actually why the CLI tool is complaining: it can't resolve higher-up node_modules!

EthereumTupple Error

I tried to manually copy over the libraries:

cp -R ../../node_modules/@graphprotocol ./node_modules/@graphprotocol

That indeed changed the output, but I got the error I documented in this comment.

Environment

• macOS
• yarn 1.15.2
• @graphprotocol/graph-cli 0.10.0
• @graphprotocol/graph-ts 0.6.0

Also tried downgrading the versions but had the exact same issues.

[Jannis]

Looks like you figured the EthereumTuple error in #257 out yourself.

Due to the way the AssemblyScript compiler works, we're using our own logic to look up the @graphprotocol/graph-ts module. Support for proper module resolution in the compiler is being tracked here: AssemblyScript/assemblyscript#448.

[Jannis]

Having said that, it should be easy to add support for this.

[PaulRBerg]

For what it's worth, I just managed to fix this by using nohoist:

// package.json
{
  ...
  "workspaces": {
    "packages": [
      "packages/*"
    ],
    "nohoist": [
      "packages/subgraph/@graphprotocol/graph-ts",
      "packages/subgraph/@graphprotocol/graph-ts/**"
    ]
  }
}

[andr11111]

Any update on this? I'm getting the following when trying to have subgraph as a yarn workspace package.

Error: Failed to compile data source mapping: Import file '~lib/@graphprotocol/graph-ts.ts' not found.

[piavgh]

Any update on this? I'm getting the following when trying to have subgraph as a yarn workspace package.

Error: Failed to compile data source mapping: Import file '~lib/@graphprotocol/graph-ts.ts' not found.

Updating graph-cli and graph-ts to version ^0.20.0 solves this problem

[ezescigo]

Any update on this? I'm getting the following when trying to have subgraph as a yarn workspace package.

Error: Failed to compile data source mapping: Import file '~lib/@graphprotocol/graph-ts.ts' not found.

Updating graph-cli and graph-ts to version ^0.20.0 solves this problem

OMG thank you. This solved my problem as well with yarn workspaces

[AlbertSu123]

I'm getting a similar issue:
Error: Failed to compile data source mapping: Import file '~lib/prettier.ts' not found.
Tried both ideas, didn't work. Does anyone have suggestions?

[AlbertSu123]

I'm getting a similar issue:
Error: Failed to compile data source mapping: Import file '~lib/prettier.ts' not found.
Tried both ideas, didn't work. Does anyone have suggestions?

My solution was to just uninstall and reinstall everything related to the graph protocol on my computer. That fixed it for me.

[0xjjpa]

I'm seeing a similar issue when trying to install an external dependency in Typescript, but not within a workspace project. In my case, I'm importing a Typescript dependency on my mappings.ts as follows:

import { generateChannelId } from '@hoprnet/hopr-utils/lib/types/channelEntry'
import { Address } from '@hoprnet/hopr-utils/lib/types/primitives'

(these are JavaScript compiled files, and I'm fetching directly from the folders but they are also exported as you can see in the source package)

As a result, I cannot compile the project:

gitpod /workspace/hopr-analytics/subgraph-channels $ yarn build
yarn run v1.22.10
$ graph build
  Skip migration: Bump mapping apiVersion from 0.0.1 to 0.0.2
  Skip migration: Bump mapping apiVersion from 0.0.2 to 0.0.3
  Skip migration: Bump mapping apiVersion from 0.0.3 to 0.0.4
  Skip migration: Bump mapping specVersion from 0.0.1 to 0.0.2
✔ Apply migrations
✔ Load subgraph from subgraph.yaml
  Compile data source: HoprChannels => build/HoprChannels/HoprChannels.wasm
✖ Failed to compile subgraph: Failed to compile data source mapping: Import file '~lib/@hoprnet/hopr-utils/lib/types/channelEntry.ts' not found.
Error: Failed to compile data source mapping: Import file '~lib/@hoprnet/hopr-utils/lib/types/channelEntry.ts' not found.
    at Compiler._compileDataSourceMapping (/workspace/hopr-analytics/subgraph-channels/node_modules/@graphprotocol/graph-cli/src/compiler.js:312:13)
    at /workspace/hopr-analytics/subgraph-channels/node_modules/@graphprotocol/graph-cli/src/compiler.js:206:20

You can replicate this error in the following branch.

[schmidsi]

@jjperezaguinaga as Jannis commented above, the import process into AssemblyScript is different and does not follow the same standards as node.js. As far as I know, important is that the source .ts files are deployed to NPM.

That said, there is a library that seems to be importable: protofire/subgraph-toolkit. The only difference that I see currently, is that you do not expose a module field in your package.json like they do.

[0xjjpa]

@schmidsi Thanks for pointing this out! And checked out protofire's subgrapth toolkit, super useful (wouldn't expect anything less from @mgarciap's team!).

We aren't ESM friendly yet, but might be enough time to change that. I will test locally and get back to you, merci!

[0xjjpa]

@schmidsi Reporting back as promised. Although I successfully managed to have graph-cli process my updated module (see changes here), the follow-up problem comes from imported libraries that are not ESM friendly and thus breaking the build.

Although I can live with that, I started to wonder how many of these libraries are actually supported, or whether graph-cli supports at all importing and reusing lives. For instance, ethers can't be imported as a ESM module despite having exporting their .ts files, and trying to fetch them as such, will return

which will prompt you to include @ethersproject/bytes/src/index (as an example), which in turn will follow-up with the dependency tree corresponding errors (here's a blog post documenting this behaviour):

Furthermore, I tried with @otaviopace PR #690 as you can see in my branch to no avail. I'm not sure how I can import external libraries to parse my contract events, or to be more accurate, to reuse my own typings to avoid recoding logic using the generated types.

FWIW, I inspected @sistemico 's subgraph-toolkit, and noticed everything was coded from scratch. Even @PaulRBerg 's sablier subgraph's, @pi0neerpat's superfluid subgraph's and @austingriffith's scaffold-eth demo subgraph relies only on automatically generated schema, so it might be safe to say that for most cases you do not need an external library.

As a conclusion, would it be fair to say that,

• as of today general importing of libraries to process event mappings is not supported, and thus
• the rule of thumb is to leverage on the generated schema tooling to process events data?

For now I'll go ahead and process the events using the in-house tooling. If anyone has a working example of a two-levels depth importing of a CJS compiled library to map events, it would be great.

[0xjjpa]

FWIW the documentation states that it's indeed not supporting importing other libraries. This is unrelated to the original issue, but might be enough for googlers that find this issue useful.

[zimmah]

@schmidsi Reporting back as promised. Although I successfully managed to have graph-cli process my updated module (see changes here), the follow-up problem comes from imported libraries that are not ESM friendly and thus breaking the build.

Although I can live with that, I started to wonder how many of these libraries are actually supported, or whether graph-cli supports at all importing and reusing lives. For instance, ethers can't be imported as a ESM module despite having exporting their .ts files, and trying to fetch them as such, will return

which will prompt you to include @ethersproject/bytes/src/index (as an example), which in turn will follow-up with the dependency tree corresponding errors (here's a blog post documenting this behaviour):

I am having this problem too but with @graphprotocol.

I don't understand why it doesn't just get it from node modules. But even if I specifically point to node modules, it will have a similar problem for imports within the node module files.