@parcel/core: Failed to resolve error in ts file after (empty) tranformer

[wclr]

🐛 bug report

I've created a simple transformer package (linked locally):

const { Transformer } = require("@parcel/plugin")

module.exports = new Transformer({
  async transform({ asset }) {    
     return [asset]
  },
})

Even if it does nothing (just returns asset) I get the error (there in the file I'm creating svg URL from local asset):

@parcel/core: Failed to resolve 'bfa690e8b0a64f58' from './src/ui.ts'

Error looks this way

If to remove "parcel-transformer-ts" from ts transformers lits, it works, though I aslo need to rf -rf .parcel-cache otherwise the error persists.

More strangely it is a kind of floating bug because sometimes it started work while I was updating the transformer file when the bundler was running.

So any advice on this, maybe something wrong with the config?

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

{
  "extends": [
    "@parcel/config-default"
  ],  
  "transformers": {
    "*.ts": [
      "parcel-transformer-ts", "..."
    ]
  }
}

🤔 Expected Behavior

Should work without error.

😯 Current Behavior

The resolve error.

💁 Possible Solution

As a workaround, if not to include files with such URLs in transformed, it works.

Repro example

I've create repro example: https://github.com/wclr/parcel-transform-issue

🔦 Context

💻 Code Sample

🌍 Your Environment

Software	Version(s)
Parcel	2.2.1
Node	v16.13.2
npm/Yarn
Operating System

[wclr]

Also with this transformer in config parcel build doesn't work.

I've create repro example: https://github.com/wclr/parcel-transform-issue

[cairomassimo]

FWIW I'm getting the same issue with v2.12.0.

It happens both with new URL('...', import.meta.url) and with inline require(...) calls (inside ESM modules).

[cairomassimo]

Add the problem goes away if I replace the "*.ts" selector with "*.{js,ts,tsx}" (my project contains both .ts and .tsx, but no .js).

Maybe it's related to assets changing type from .ts[x] to .js during transformation? Just guessing here...

[mischnic]

This is likely the same bug as described in #4936 (comment)

[cairomassimo]

Thanks @mischnic! It sounds right.