[dev-server-esbuild] Unable to resolve packages with correct extensions when imported in an .ts file using node's exports

[motss]

When files being imported in an .ts file, the resolver automatically assumes all the imports must be ended with .ts when some could be .js. It seems like the dev server does not support node's exports quite well.

Actual behavior

Packages that use exports in node resolves with .ts when it gets imported in a .ts file.

Expected behavior

Packages that use exports in node must be resolved with the correct extensions when it gets imported in a .ts file

Steps to reproduce

Clone this repo and run the project to reproduce the stated problem.

[LarsDenBakker]

I looked into this, and it's an issue inside rollup node resolve. There is special handling for .ts files: https://github.com/rollup/plugins/blob/master/packages/node-resolve/src/index.js#L178. Together with the export map of this package, it creates this situation...

[motss]

Not sure if it is a rollup plugin issue but I tried it with rollup, rollup-plugin-typescript2 and @rollup/plugin-node-resolve. Everything runs without issue. There is no resolution issue with node's export map.

[LarsDenBakker]

Will need to do some more investigation on our side

[peschee]

@LarsDenBakker @motss I think I am running into the same or similar issue when using Lit 2.x directives. I have created a small test repo: https://github.com/peschee/wds-esbuild-lit-test

[peschee]

I think this issue blocks users from upgrading to Lit 2.x when using TypeScript and the recommended esbuild setup in wds.

[swissmanu]

Same problem here, in conjunction with lit 2.x.

[abdonrd]

@LarsDenBakker @motss I think I am running into the same or similar issue when using Lit 2.x directives. I have created a small test repo: https://github.com/peschee/wds-esbuild-lit-test

I have the exactly same problem!

[abdonrd]

Will need to do some more investigation on our side

@LarsDenBakker Have you had time to investigate it? Thanks in advance!

[thescientist13]

Not sure if related, but I may be running into something similar? I'm using test runner, but as I understand it, all the file routing and handling gets handled by dev server, so I think the context applies?

Was using web test runner, writing some ES2015+ custom elements and specs with new lit, everything is good. 💯
https://github.com/AnalogStudiosRI/www.analogstudios.net/tree/chore/design-system-poc

Added a new TypeScript based component following the lit.dev playground, using tsc and middleware to transform .ts files on the fly for web test runner.
https://github.com/AnalogStudiosRI/www.analogstudios.net/tree/chore/design-system-poc-typescript

Now getting this error when running test runner

src/components/greeting/greeting.spec.js:

 🚧 Browser logs:
      TypeError: Failed to resolve module specifier "lit". Relative references must start with either "/", "./", or "../".

 ❌ Could not import your test module. Check the browser logs or open the browser in debug mode for more information. 

Chrome: |██████████████████████████████| 3/3 test files | 6 passed, 0 failed

Code coverage: 100 %

Finished running tests, watching for file changes... 

I noticed comparing the responses using the browser debugger that Dev Server (presumably) was correctly re-writing my bare imports in my other components, like footer.js

But not for greeting.ts. Maybe that's because import is not at the top?

Either way, for greeting.ts the bare imports stay, well bare. 🐻👀

---

Let me know if you need more info or if this should be its own issue. 🙏

[LarsDenBakker]

@thescientist13 that's a different issues, you need to serve your files as JS. This might work:

        return {
          body: result.outputText,
          type: 'js'
        };

but it might be that your plugin runs after node resolve. So then you might need to add a mimeTypes option to your config instead:

{
  mimeTypes: {
    '**/*.ts': 'js',
},

@abdonrd The issue is in rollup node resolve, as I expected. We need to make this behavior of the rollup plugin configurable, so that we can turn it off.

[thescientist13]

Thanks @LarsDenBakker , that did it! 🙌

[abdonrd]

@tjenkinson is working on a fix for this (rollup/plugins#921)! Thanks!

[zenwork]

return {
          body: result.outputText,
          type: 'js'
        };

for anyone looking for a more complete quick workaround example:

if (context.path.includes('node_modules/lit') && context.path.endsWith('.ts')) {
      const path = `${__dirname}/../../..${context.request.url}`.replace(/\.ts$/,'.js')
      console.log(path)
      const body = fs.readFileSync(path)
      return { body, type: 'js' };
    }

[abdonrd]

rollup/plugins#921 has been solved and @rollup/plugin-node-resolve@13.0.4 published!

[abdonrd]

@LarsDenBakker could you merge this #1433 to see if fix it? Thanks!

[abdonrd]

Fixed in @web/dev-server@0.1.18! 👏

---

Edit: Reverted in new version: #1569. 😢

[WickyNilliams]

Hey. What was the reason for rolling #1433 back in #1569?

I am experiencing this issue where an import of a .js file ends up being replaced with an import for a non-existent .ts file when served by the dev-server.

Forcing my local install to use @rollup/plugin-node-resolve@13.0.4 (by hand editing my package-lock.json) fixes the problem. So it seems this all is good in latest releases.

Edit: I see the rollback was forced because of a failing test. What is the plan for this issue?

[bennypowers]

the failing test case is cjs dependencies outside the web root (e.g. in node_modules). Rollup recently made a breaking change to how it internally handles module resolution, which causes those imports to either not resolve at all or to resolve with rollup internal cjs urls (depending on which attempted solution is tried)
So far we don't have a clear solution, see #1633