Comments (9)
I just came here to suggest this feature to be implemented, but before opening a new issue, I've searched and found this issue already opened.
I think this feature would be very welcome. Should be disabled by default and explicitly enabled through configuration $HOME/.asdfrc
. In case the developer wants to use this feature, he must to be aware of the effects that it may cause.
Is there a way to print an alert message in terminal when the directory is navigated to ?
Another observation is that the implementation of this feature should be simpler as possible, nothing more than check if exists a package.json file, parse it as JSON, check the presence of the "engines.node" field filled, validate it with a regular expression, and resolve the version, keeping the behavior aligned as if the version was read from .toolversion.
My suggestion to solve the question raised about the engines.node field allowing the semver format which in some cases may not be compatible with asdf, the field must be validated using the regular expression found on the official website https://semver.org, and in case of failure, ignore and use the default strategy. It should also be clear in the documentation that in order to use package.json as a source of information for the node.js version, the engines.node field must be in a format compatible with the format expected by asdf. Otherwise, it makes no sense to use package.json as a replacement for .toolversions.
from asdf-nodejs.
@Stratus3D I would really like to see support for engines
in asdf. I understand the complexity involved in supporting the semver expressions though.
What if we compromised and asdf supported strings that have a specific version without semver syntax? So if it had 16.x
, it'd get ignored like it does currently. But if it had 16.13.1
, it'd install that specific version.
Thoughts?
from asdf-nodejs.
After looking at this a bit more, I don't think we should add support for this. Adding support for this would require a lot of code. Here is the PR for nvm (which isn't going to be merged) - nvm-sh/nvm#1535. It is over 1200 lines of code.
I think my biggest objection to this is that it doesn't make sense semantically.
I don't think the feature makes sense semantically - in other words, that the package.json "minimum supported version range" field makes sense as a "run it under this one single version of node/io.js"
-- @ljharb
package.json specifies a version or range of versions that the package is compatible with, whereas .tool-versions
and .node-version
specify a single version that must be used. We'd have to implement our own logic for choosing the highest or lowest version for the package, or maybe prefer a version the user already has installed. That gets very complicated. I think we should just stick with .tool-versions
and .node-version
.
from asdf-nodejs.
+1 I would love to see this feature in asdf. There are already so many files that need to be in the root of a project and package.json already officially has a field that designates what version should be used. Following DRY, we should use package.json.
Fringe Use Benefit: I imagine this feature would also be useful in some cases where the latest version of Node causes a break -- with the ">=14.0.0" specified in package.json, this would force developers to have their code tested with the latest version before sending it off to a public registry.
In regard to @Stratus3D 's comment about nvm's implementation being over 1200 lines -- most of the code is test code/mock data for the tests. The actual bash script logic is about 300 lines in the nvm.sh
file.
If we brought this feature to asdf, we could probably recycle the code from the nvm commit.
I don't have the bandwidth to pick this up currently plus I'm not in active communication with the maintainer but I'd be willing to fund the PR by giving an NFT of a girl's fart in a jar to see this get done (Source: https://news.bitcoin.com/wind-breaking-nfts-reality-star-who-made-200k-selling-farts-in-mason-jars-launches-nft-collection/)
from asdf-nodejs.
If we have both package.json
and .tool-versions
in the same directory it's obvious that we should choose the version in .tool-versions
.
But what to do if .tool-versions
is in a parent directory relative to the package.json
?
e.g.
foo/
├── .tool-versions
└── bar/
└── package.json
Also, take into an account that the version inside the package.json
might be actually a range of versions.
Would you rather install the version from engines
after using node or npm for the first time inside the project or use the version from engines
only if it is already installed?
from asdf-nodejs.
Replying to @MrQubo's questions with an opinion.
.tool-versions
should take precedence.
In a subdirectory, any legacy file, or .tool-versions
if available, should take precedence for that directory.
For a range of versions, the latest version allowable, and installed, should be used, if available.
The last question seems to point to automatic installation, which I do not believe is reasonable. If a specified version is not available, that would be an error.
from asdf-nodejs.
Here is a PR that attempts to add support for package.json - #120. The problem with this PR is that the engine value isn't a plain version that can be used by asdf-nodejs. We would have to address all the issues nvm would have to address on their PR.
from asdf-nodejs.
Closing since I don't think this makes sense as a feature. Please comment if you think I should re-open this ticket.
from asdf-nodejs.
@augustobmoura what do you think about that? I suppose it wouldn't really break asdf-nodejs semantics, but would it be worth the hassle to implement?
from asdf-nodejs.
Related Issues (20)
- Force compile flag has a typo HOT 3
- Ability to skip installing default npm packages HOT 3
- Issues in running test scripts from Eclipse with Appium shim HOT 1
- bug: nodejs plugin segfault with node `11.1.0` HOT 4
- Resolving LTS version only outputs major number HOT 4
- npm shim should work without $HOME HOT 5
- Unable to install 18.18.1 HOT 1
- import-release-team-keyring not found HOT 1
- NodeJS 18.18.2 is not in the list! HOT 2
- Can't install 21.0.0 HOT 4
- bug: asdf cannot resolve config paths with whitespace in them HOT 2
- Last version is 20.5.1 but Node is already at 21.0.2 HOT 1
- asdf cant find definition for v18.19.0 HOT 2
- Dependency on nvm HOT 1
- How to install Nodejs latest LTS version? HOT 1
- default-npm-packages support registry
- asdf: Warn: You have configured asdf to preserve downloaded files (with always_keep_download=yes or --keep-download). But asdf: Warn: the current plugin (nodejs) does not support that. Downloaded files will not be preserved. HOT 2
- not using project .tool-versions to set node version in tmux
- Is it possible to show the LTS version in the list of versions right after installing the plugin?
- Cannot install node 21.7.x HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asdf-nodejs.