feat: add node: prefixed modules

[dnalborczyk]

What kind of change does this PR introduce?

follow-up from: #12181

adds 'node:' prefixed builtin modules.

https://nodejs.org/docs/latest-v12.x/api/esm.html#esm_node_imports

nodejs/node#37246

Did you add tests for your changes?

Does this PR introduce a breaking change?

What needs to be documented once your changes are merged?

[webpack-bot]

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

[alexander-akait]

Can you add small test?

[sokra]

make to sure to also add a test case for that.

[webpack-bot]

@dnalborczyk Thanks for your update.

I labeled the Pull Request so reviewers will review it again.

@sokra Please review the new changes.

[sokra]

hmm, seems like node: only works in import and not in require, but we always generate require calls for the node.js externals. We need to revisit that when ESM support allows module externals.

[dnalborczyk]

@sokra

hmm, seems like node: only works in import and not in require, but we always generate require calls for the node.js externals.

that's what I tried to explain here: #12181 (comment)

this will be (could be) supported soon in node.js for commonjs modules as well (also mentioned on top of this thread): nodejs/node#37246

We need to revisit that when ESM support allows module externals.

I thought esm support is currently being added to webpack? https://github.com/webpack/webpack/releases/tag/v5.22.0

[alexander-akait]

@dnalborczyk I think we need wait when it was merged and we can merge it too

[dnalborczyk]

@dnalborczyk I think we need wait when it was merged and we can merge it too

@alexander-akait it's merged now. it seems it's being shipped in node v16.x and possibly backported later on.

[sokra]

Ok node merged node: support for require, so this PR is fine now. A test case is still missing for that.

[karlhorky]

This will close #13290 when merged

[alexander-akait]

@dnalborczyk friendly ping

[karlhorky]

So this feature is about to get more usage: the node: scheme / prefix / protocol was backported to Node.js 14.13.1 / 12.20.0 🎉

https://nodejs.org/api/esm.html -> link "node: Imports" (links with anchors don't scroll properly right now)

[karlhorky]

An alternative to the approaches in #13311 and #12693 would be to use is-core-module (which was split from resolve in browserify/resolve@7c26483), so that this list doesn't need to be maintained and tested by webpack itself.

[webpack-bot]

@sokra The most important CI builds failed. This way your PR can't be merged.

Please take a look at the CI results from azure (1 errors / 1 warnings) and appveyor (success) and fix these issues.

[sokra]

Thanks

[karlhorky]

Thanks @sokra! Looking forward to using this! (also with our students in Next.js!)

Will this be in a new patch (5.39.2) or minor (5.40.0)?

[alexander-akait]

@fregante please create steps to reproduce, if you use target: 'web' it is expected, no node:path in browser

[alexander-akait]

You can use alias and use https://github.com/browserify/path-browserify

[alexander-akait]

But maybe better to ask developer provide browser based version of library

[alexander-akait]

The developer does, but it uses exports.browser in the package.json, which doesn't seem to be picked up and I wasn't able to find any issues regarding exports map on this repo either.

It will be used if it is provided

[alexander-akait]

Give me time, I will investigate

[alexander-akait]

Because the problem in other place, what is the problem with waiting an answer?

[alexander-akait]

Change your import on import * as mod from "filenamify/browser";

[alexander-akait]

Here described https://nodejs.org/api/packages.html#packages_subpath_exports

[alexander-akait]

And we cannot analyze it is subpath for browser or not, so you should explicitly use filenamify/browser

[alexander-akait]

But here other problem resolve.fallback.path/resolve.fallback['node:path'] is not respected

[alexander-akait]

Issue for resolve.fallback and resolve.alias #14166

[alexander-akait]

I don't know what we need explain here, Node.js docs describe how exports works

[alexander-akait]

Where we should docs it?

[alexander-akait]

Here answer #12693 (comment), exports is just subpath of URL, we can't understand that code for browser or for node or for other env

[alexander-akait]

exports.browser in package.json is not automatically picked up on web target #14163 is the issue that's missing a solution, and is not linked to this one

And should not do it - ./browser is part of URL, if you need special target change it on browser, i.e.:

{
	"exports": {
		"browser": "./browser.js",
		"default": "./index.js"
	}
}

No ./

[alexander-akait]

No need discussion, what is the problem? I answered the same multiple times, ./browser will not and should not work as you expected, logic described in Node.js docs