tslib
tslib copied to clipboard
DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field
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.
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.
https://github.com/postcss/postcss/issues/1455
Any update on this?
To get the ball rolling, I've created a pull request based on the mentioned postcss solution. https://github.com/microsoft/tslib/pull/139
Tested with node v15.2.1
.
Thanks @ericgopak, really appreciated.
upgrading nodejs to v15.8.0 fixed the warnings for me
@omostan this works indeed, thanks for your reply!
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.
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?
+1
+1
Yep, can replicate this with v16.3.0
+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?
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?
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"
Same Node v16.8.0
this is a ticking time bomb going for years. Some day it will go off and break production for sure ! please fix this !!
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...
Same!
Same error :/ node v16.9.1
same error node version v16.10.0
same error node version v16.10.0
Having the same issue with node v14.15.1
[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)
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?
Yes, especially given the issues this causes with @microsoft/rush
which is another Microsoft library.
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?
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?
Reading further into it I find some duplicate issues in this repo.
https://github.com/microsoft/tslib/issues/134 (this thread) https://github.com/microsoft/tslib/issues/152 https://github.com/microsoft/tslib/pull/135
v16.11.1 same
Suggested a possible solution in this PR: #163