[node-resolve] .js files imported from a.ts file gets resolved to .ts extension

[motss]

Facing an issue with @web/dev-server at modernweb-dev/web#1376 where the node resolution breaks for dependencies that are using node's exports map, e.g.

// main.ts
import { highlight } from 'nodemod/dist/lib/prismjs.js'; // nodemod@2.7.3 is using `exports` map in node

FYI, nodemod's package.json is as follows:

// nodemod's package.json
...
"exports": {
  "./dist/*": "./dist/*",
  ...
}

What's happening in @web/dev-server is that files are imported with .ts extension due to the following code as pointed out by the author of @web/dev-server:

plugins/packages/node-resolve/src/index.js

Lines 178 to 184 in 53776ee

	if (importer && importee.endsWith('.js')) {
	for (const ext of ['.ts', '.tsx']) {
	if (importer.endsWith(ext) && extensions.includes(ext)) {
	importSpecifierList.push(importee.replace(/.js$/, ext));
	}
	}
	}

Expected behavior

import { highlight } from 'nodemod/dist/lib/prismjs.js'; should resolve to 'node_modules/nodemod/dist/lib/prismjs.js';

Actual behavior

import { highlight } from 'nodemod/dist/lib/prismjs.js'; resolves to 'node_modules/nodemod/dist/lib/prismjs.ts';

[swissmanu]

is there anything going on with this issue? if there is a decision/common understanding how this should work, i am happy to take over the implementation work with a pull request if possible :)

[abdonrd]

I have the same issue!
My exactly use case: modernweb-dev/web#1376 (comment)

[shellscape]

Thanks for opening an issue. Citing the issue template:

🚨 Issues WITHOUT a valid reproduction WILL BE CLOSED!

Please provide one by:

1. Using the REPL.it plugin reproduction template at https://repl.it/@rollup/rollup-plugin-repro
2. Provide a minimal repository link (Read https://git.io/fNzHA for instructions).
   Please use NPM for installing dependencies!
   These may take more time to triage than the other options.
3. Using the Rollup REPL at https://rollupjs.org/repl/

⚠️ ZIP Files are unsafe and maintainers will NOT download them.

We cannot make this any clearer. Please add a reproduction and we'll be happy to triage further.

--

@swissmanu if you'd like to take up the task on this we'd certainly welcome it. without a proper reproduction though, the maintainers can't make a call on which direction would be most beneficial, or if this deserves another option. @motss please edit your issue and add back our issue template with all requested information and I'll be happy to reopen.

[abdonrd]

@motss can you update the issue with the Andrew request? Thanks!

[abdonrd]

@shellscape this small test repo from @peschee show the issue: https://github.com/peschee/wds-esbuild-lit-test

---

Test case for wds + esbuild + lit 2.x

The import lit/directives/class-map.js should resolve to node_modules/lit/directives/class-map.js

// src/MyElement.ts
import { classMap } from 'lit/directives/class-map.js';

Instead, it resolves to node_modules/lit/directives/class-map.ts and triggers the following error in the browser:

GET http://localhost:8000/node_modules/lit/directives/class-map.ts net::ERR_ABORTED 404 (Not Found)

How to run

1. Run npm start
2. Visit localhost:8000 with Dev Tools open
3. Inspect network tab on the resources
4. Notice how lit/directives/class-map.js gets resolved using .ts instead of .js

[tjenkinson]

Is this the same as #911 ?

In which case #921 should fix this too

[abdonrd]

Is this the same as #911 ?

In which case #921 should fix this too

Yeah, I would say it is the same problem! Thanks!