DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field

[johncrim]

When building with tslib, I'm seeing the following on every build:

(node:40688) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at <snip>\node_modules\tslib\package.json.
Update this package.json to use a subpath pattern like "./*".

I'm pretty sure this started when upgrading to Node 15.1.0.

Environment:

Angular CLI: 11.0.0
Node: 15.1.0
OS: win32 x64

Package                         Version
---------------------------------------------------------
...
typescript                      4.0.5
webpack                         4.44.2
tslib                                 2.0.3

This is an Angular project - I can provide a repro case if it's not obvious.

[johncrim]

In case it's helpful, here's another popular library fixing the same issue. It looks like the first try didn't work; so this is something that would need to be tested with multiple versions of node.

postcss/postcss#1455

[rangelier]

Any update on this?

[ericgopak]

To get the ball rolling, I've created a pull request based on the mentioned postcss solution.
#139

Tested with node v15.2.1.

[rangelier]

Thanks @ericgopak, really appreciated.

[omostan]

upgrading nodejs to v15.8.0 fixed the warnings for me

[rangelier]

@omostan this works indeed, thanks for your reply!

[johncrim]

This could be closed (though I'm not sure whether it should be), since the deprecation in node was reversed:

Some relevant PRs from node repo:
nodejs/node#35747
nodejs/node#36859

If there were a benefit to the changes aside from eliminating the warning, it might be worth keeping this open, but I'm not sure what those benefits are.

Comments on nodejs/node#36859 indicate that this deprecation may come back, but they've reversed the deprecation warnings for libs within node_modules. So I'll leave it up to the tslib maintainers to decide whether to close this, or take a fix to avoid the future deprecation.

[EricDitp]

In NodeJs 16 this issue reintroduced:
(node:7972) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at ~/node_modules/tslib/package.json.
Update this package.json to use a subpath pattern like "./*".

Versions: 16.0.0 and 16.2.0

Any news?

[Alphavader]

+1

[uganjha]

+1

[vinayakkulkarni]

Yep, can replicate this with v16.3.0

[haddadzineddine]

+1

In NodeJs 16 this issue reintroduced:
(node:7972) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at ~/node_modules/tslib/package.json.
Update this package.json to use a subpath pattern like "./*".

Versions: 16.0.0 and 16.2.0

Any news?

[zvikasdongre]

I am getting the same warning:

(node:180913) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of
the package at /home/user/path/to/folder/node_modules/rxjs/node_modules/tslib/package.json.
Update this package.json to use a subpath pattern like "./*".

Can someone please tell me how to fix this?

[YaoaY]

I am getting the same warning:

(node:180913) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of
the package at /home/user/path/to/folder/node_modules/rxjs/node_modules/tslib/package.json.
Update this package.json to use a subpath pattern like "./*".

Can someone please tell me how to fix this?

same warning
node 16.6

for now , i disabled the warnings by using cross-env:
npm i cross-env -D
and in package.json:
"build": "cross-env NODE_OPTIONS='--no-deprecation' ng build"

[RabbitYui]

Same
Node v16.8.0

[yonnic]

this is a ticking time bomb going for years. Some day it will go off and break production for sure !
please fix this !!

[DennisKraaijeveld]

I have exactly the same now on node 15.8.0 when trying to build my site on Gatsby Cloud. This error is coming out of nowhere...

[asheroto]

Same!

[luisegarduno]

Same error :/
node v16.9.1

[Abaddon-88]

same error node version v16.10.0

[JayCuthrell]

same error node version v16.10.0

[matthiasunt]

Having the same issue with node v14.15.1

[prescience-data]

[DEP0148] DeprecationWarning: 
Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at 
*****\node_modules\tslib\package.json.

Update this package.json to use a subpath pattern like "./*".

(Use `node --trace-deprecation ...` to show where the warning was created)

[TheWirv]

I am still facing this issue, almost a year later. I'm on v16.12.0, and there is a PR for this, as many people have already pointed out: #135 by @JonSenpai The CI fails for it, however; the v14.x job fails, to be specific. But maybe @ExE-Boss's suggestion could fix that?

[prescience-data]

Yes, especially given the issues this causes with @microsoft/rush which is another Microsoft library.

[StudioSpindle]

Potentially perhaps changing the export path to ./* could fix this deprecation warning.

However, as per the nodejs documentation doing so would:

"As a last resort, package encapsulation can be disabled entirely by creating an export for the root of the package "./": "./". This exposes every file in the package at the cost of disabling the encapsulation and potential tooling benefits this provides. As the ES Module loader in Node.js enforces the use of the full specifier path, exporting the root rather than being explicit about entry is less expressive than either of the prior examples. Not only is encapsulation lost but module consumers are unable to import feature from 'my-mod/feature' as they need to provide the full path import feature from 'my-mod/feature/index.js."

So the issues with this approach:

• file encapsulation is lost
• API is changed (users will be unable to import feature from 'my-mod/feature')
• it will break old Node.js compatibility.

Another library postcss had the same issue (postcss gh-1561) and they solved it by being explicit about the exports.

So if we would explicitly define the exports that are necessary rather than ./ would solve this deprecation warning once and fore good?

[StudioSpindle]

Yes, especially given the issues this causes with @microsoft/rush which is another Microsoft library.

@prescience-data What are the issues that are caused in that library?

[StudioSpindle]

Reading further into it I find some duplicate issues in this repo.

#134 (this thread)
#152
#135

[broven]

v16.11.1 same

[StudioSpindle]

Suggested a possible solution in this PR: #163

[ghost]

node v16.13.2 same

[nurbashanghai]

+1 seems like this is broken

[AlejoFlorez0]

node 16.14.0 same

[haggholm]

Hopefully fixed in #135, though they need to also cut a release.

[muniom]

c'mon Microsoft wtf

[EricDitp]

any news?

[tettoffensive]

@haggholm Doesn't seem like they'll cut a release anytime soon. Last release was in August.

[MaEdAlpha]

Umm... I made this error go away by changing in the \node_modules\tslib\package.json

`
"exports": {
".": {
"module": "./tslib.es6.js",
"import": "./modules/index.js",
"default": "./tslib.js"
},
"./": "./"
}

`

swap out "./": "./" with "./*": "./"

Why and how? I do not know. We can leave that to the tslib-overlords on whether this is acceptable or not. This works with
node v16.14.0

I went through the [https://github.com/postcss/postcss/issues/1455](postcss issue) November 6 2020 Sheng Hong Fei comment.

[tibin-carestack]

https://www.npmjs.com/package/patch-package

https://stackoverflow.com/questions/69857568/deprecationwarning-use-of-deprecated-folder-mapping-in-the-exports-field

ds300/patch-package#49

[DamianoPantaniHT]

Bumping tslib to 2.4.0 in devDependencies and resolutions solved these warnings here

[Made-of-Clay]

Bumping tslib to 2.4.0 in devDependencies and resolutions solved these warnings here

I had tslib @ 2.4.0 and it was not removing the messages, but it was in dependencies instead of devDependencies. Once I moved it, the messages went away 👍 Thanks @DamianoPantaniHT

[haggholm]

I had tslib @ 2.4.0 and it was not removing the messages, but it was in dependencies instead of devDependencies. Once I moved it, the messages went away

Are you sure this is correct? tslib is a runtime library. Unless you're bundling things (e.g. using Webpack or something), not having them in production dependencies sounds like it might break.

[Made-of-Clay]

Are you sure this is correct? tslib is a runtime library. Unless you're bundling things (e.g. using Webpack or something), not having them in production dependencies sounds like it might break.

I'm sure - it is for a Vue.js application, so TS doesn't run at runtime; it's compiled JS when the app's runtime occurs.

[jakebailey]

This has been fixed as of tslib 2.4.0.