-
-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
es-abstract@1.17.0-next.1 release breaking old applications #84
Comments
I'm having the same issue |
Since the file is present there’s no reason it shouldn’t resolve. What do you mean by “dynamic dependency statement”? Nothing I’m aware of uses es-abstract as a peer dep, since it’s not stateful. Is there any possibility your webpack config has some kind of special overrides for es-abstract? |
Dynamic dependency statement is maybe a weird phrase but something like |
I've tried making a new clean project and importing only the library that uses airbnb-prop-types and object.entries. While running: |
@norpisdev ok, "using semver ranges", which is a best practice (not using them is hostile; a lockfile is how an app-level consumer should pin things). @andjelboskovic that sounds like an issue that should be filed with webpack then, as there's nothing es-abstract is doing that, say, lodash isn't doing (deep requires). |
@ljharb thanks. I edited my post to use the correct phrasing. Undenyibly some parts of our codebase are really outdated and need to be updated ASAP (webpack version 2.x ...) so for now I am running the development build under production flag similar how @andjelboskovic mentioned it. Which lets the code compile just fine. |
You updated minor version and you use #next version tag on some dependecies, I think that's not good way, you should use #next tag for this testing phase, for example package function.prototype.name (below is package-lock.json). I suggest to revert changes and create next tag for dependencies that use es-abstract#next Previous version "function.prototype.name": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/function.prototype.name/-/function.prototype.name-1.1.1.tgz",
"integrity": "sha512-e1NzkiJuw6xqVH7YSdiW/qDHebcmMhPNe6w+4ZYYEg0VA+LaLzx37RimbPLuonHhYGFGPx1ME2nSi74JiaCr/Q==",
"requires": {
"define-properties": "^1.1.3",
"function-bind": "^1.1.1",
"functions-have-names": "^1.1.1",
"is-callable": "^1.1.4"
}
} New minor version "function.prototype.name": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/function.prototype.name/-/function.prototype.name-1.1.2.tgz",
"integrity": "sha512-C8A+LlHBJjB2AdcRPorc5JvJ5VUoWlXdEHLOJdCI7kjHEtGTpHQUiqMvCIKUwIsGwZX2jZJy761AXsn356bJQg==",
"requires": {
"define-properties": "^1.1.3",
"es-abstract": "^1.17.0-next.1",
"functions-have-names": "^1.2.0"
},
"dependencies": {
"es-abstract": {
"version": "1.17.0-next.1",
"resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.17.0-next.1.tgz",
"integrity": "sha512-7MmGr03N7Rnuid6+wyhD9sHNE2n4tFSwExnU2lQl3lIo2ShXWGePY80zYaoMOmILWv57H0amMjZGHNzzGG70Rw==",
"requires": {
"es-to-primitive": "^1.2.1",
"function-bind": "^1.1.1",
"has": "^1.0.3",
"has-symbols": "^1.0.1",
"is-callable": "^1.1.4",
"is-regex": "^1.0.4",
"object-inspect": "^1.7.0",
"object-keys": "^1.1.1",
"object.assign": "^4.1.0",
"string.prototype.trimleft": "^2.1.0",
"string.prototype.trimright": "^2.1.0"
}
}
}
},
Quick solution is that you override version buy manually check package-lock.json and find all packages that use es-abstract@next and put them as your project dependency with fixed version for example
```
npm i -D function.prototype.name@1.1.1
```
|
Not sure what the real issue is, but @ninosaurus's suggestion worked. I needed to override both dependencies from the error:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There are no breaking changes - this is a minor, and thus new things are added, and thus if you use an older version it won’t have that functionality. Using the next tag is irrelevant since the dist-tag only matters when installing something by name without a semver specifier. This is a problem with webpack in development mode, it seems, so I’m going to close this. Please file an issue with webpack. |
While I can agree that the issue might not be here, can we be sure that it's a webpack issue? In our case, code is breaking while running tests with jest.
|
This is what
This is for the version failing
They both call @ljharb Do you think this could be the cause of this issue? |
No, those are all valid requires. Are you sure you aren’t mocking anything out in jest? Does npm ls exit successfully? |
We are not mocking anything in this failing project.
The working project has a few errors like above as well. |
While all of those errors are very serious and should be fixed ASAP, I agree they're not relevant here. https://unpkg.com/browse/array.prototype.flat@1.2.3/implementation.js is the latest version of |
Ok, I think I understand what's happening. With the current state of things, my package-lock includes:
and
Pre-release verions have lower precedence (https://semver.org/#spec-item-9) and worse, are not resolved by this pattern "^1.0.0" (https://semver.npmjs.com/) will not match That said, my node_modules folder ended up with es-abstract@1.16.3 installed es-abstract@1.17.0-next.1 will be installed as a subdependency of array.prototype.flat However having it required like this |
I'd say that releasing this without a pre-release tag should solve the issues for everybody becuase 1.17.0 would be the version resolved for all these subdependencies. |
That’s fair; i do plan to do that very soon. |
Thinking about this, I believe that the underlying issue is to use absolute paths when requiring because it opens up a door for this kind of issues. It's up to you though how to proceed. |
What do you mean, absolute paths? That it's listed as a |
I mean, instead of |
That wouldn't work - because the |
That's exactly the issue. The bare specifier is going to node_modules of my project, but the installation of es-abstracts 1.17.0-next is in the node_modules folder of my project's dependency (node_modules/array.prototype.flat/node_modules/es-abstracts - this is 1.17). Node is resolving ALL of the requires to node_modules/es-abstracts - which is 1.16. Anyway, up to how to proceed. |
if |
All. Check your configuration for module directories https://jestjs.io/docs/en/configuration#moduledirectories-arraystring for jest and https://webpack.js.org/configuration/resolve/ for webpack. Jest docs says An array of directory names to be searched recursively up and Setting this option will override the default, which happens to be @ljharb is right when he says that
I fixed that in jest in a broken scenario and it works fine now. |
In our case we had to change webpack
|
ERROR Error: Cannot find module 'es-abstract/2020/RequireObjectCoercible' |
@yogithesymbian do you have a v1.18 prerelease installed? v1.17 doesn't have any ES2020 operations. |
i used |
I’d go up to v1.18.5 at this point :-) |
I am currently experiencing an issue where which was already raised by another person on stackoverflow where the latest release
es-abstract@1.17.0-next.1
which is apparently being auto-installed by common libraries (redux-form, react-date) as a semver range.Upon building the frontend with
webpack
andwebpack dev server
the following error occurs:Upon investigating whether the path is really not existing I found out that it is indeed present -> therefore I don't quite understand why this not being resolved properly.
We are using npm modules on a locked version state which stayed the same for a few years - but some of them install dependencies using semver ranges which leads to
es-abstract@1.17.0-next.1
being installed as a peer dependency.Since we arent the owner of the npm modules we can't simply manually requirea locked version.
The text was updated successfully, but these errors were encountered: