Skip to content
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

[DCA11Y-1145] Node version manager support #4

Open
wants to merge 73 commits into
base: master
Choose a base branch
from

Conversation

flipatlas
Copy link
Collaborator

Changes:

  • add node version support for node and npm installers

@flipatlas flipatlas requested a review from atl-mk September 16, 2024 17:36
Copy link
Collaborator

@atl-mk atl-mk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lot of work, but looking pretty good so far

@atl-mk
Copy link
Collaborator

atl-mk commented Sep 17, 2024

I think I'd rather we get feature complete now so we can do one QA demo to rule them all.

I'm thinking in the QA demo we check;

  • version files not available and nothing specified in the POM (should give a good message instead of using the global version)

I can't think of anything else right now

@atl-mk
Copy link
Collaborator

atl-mk commented Sep 17, 2024

Perhaps a good development loop is to set yourself up some docker containers, one for each version manager? Maybe you already having something working for you

@atl-mk
Copy link
Collaborator

atl-mk commented Sep 17, 2024

One case I'm not sure about yet is no version file is specified and a version of Node is specified in the POM. I'm tempted to say we should do the vanilla behaviour and download it ourselves. We tell the users that the file is missing and they probably should create it.

This offers a simple way to drop-in this fork as a replacement in situations where they haven't previously created the files. That's because we'll have other features like incremental compilation which we want them to adopt.

flipatlas and others added 2 commits September 19, 2024 08:41
- fix fnm when multiple node versions installed
- use fnm dir to get installed node
- disable tests on windows
- fix paths in tests setup
@flipatlas
Copy link
Collaborator Author

I have skipped the new tests on windows, for now I'll assume we don't support windows. I'll revisit it later

@flipatlas
Copy link
Collaborator Author

QA Demo note: test on a project with split node installation in root and npm execution in modules

…ger-support

# Conflicts:
#	FORK_CHANGELOG.md
#	frontend-maven-plugin/src/main/java/com/github/eirslett/maven/plugins/frontend/mojo/NodeAndNpmMojo.java
#	frontend-maven-plugin/src/main/java/com/github/eirslett/maven/plugins/frontend/mojo/NpmMojo.java
+ update prebuild script output streams
+ fix npmmojo after nodemojo revert
+ fix fnm node directory
* Enables node installation using node version manager
*/
@Parameter(property = "useNodeVersionManager", defaultValue = "true")
private boolean useNodeVersionManager;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do one more like you suggested before? Just direct path to where node binary is. Both Maven property and use System.getEnv. I'm worried that someone will use an old branch with old version of this in the future and it won't support new version of FNM/NVS/etc. If we can tell them "no worries" modify your .mvn/cnfig and/or shell envinroment, that will be a great get out of jail pass.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added installedNodeDirectory property and AFMP_INSTALLED_NODE_DIRECTORY env var for specifying node explicitly

@@ -84,6 +102,19 @@ protected boolean skipExecution() {

@Override
public synchronized void execute(FrontendPluginFactory factory) throws Exception {
String nodeVersion = getNodeVersion(workingDirectory, this.nodeVersion, this.nodeVersionFile, project.getArtifactId(), getFrontendMavenPluginVersion());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to update metrics too so we can say x% of time using from version manager

}

String validNodeVersion = getDownloadableVersion(nodeVersion);
factory.loadNodeVersionManager(validNodeVersion);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to myself: Does this actually install if it's missing? If it does, not sure we want that? Probably don't want to encourage this, should be installing once in the parent POM.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't, it only sets the values of node and npm executable paths if version manager is available

}

String validNodeVersion = getDownloadableVersion(nodeVersion);
factory.loadNodeVersionManager(validNodeVersion);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did it get the webpack binary before? Presumably out of node_modules/.bin? How did it know the node version, relied on it being in the FMP managed node installation folder before?

FORK_CHANGELOG.md Outdated Show resolved Hide resolved
Platform platform = installConfig.getPlatform();
String architecture = platform.getArchitectureName();
String osCodename = platform.getCodename();
String nodeOnPlatform = String.format("node-%s-%s-%s", nodeVersionWithV, osCodename, architecture);
Copy link
Collaborator

@atl-mk atl-mk Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All my local installastions are like:
fnm/node-versions/v6.17.1/installation/bin. maybe only macOS problem?

until we can better reproduce, not sure the oscodename and architecture will perfectly match, hopefully they do and they might both be based off NodeJS' zip filename scheme

VersionManagerFactory versionManagerFactory = new VersionManagerFactory(installConfig);
for (VersionManagerType versionManagerType : VersionManagerType.values()) {
VersionManagerClient versionManagerClient = versionManagerFactory.getClient(versionManagerType);
if (versionManagerClient.isInstalled()) return versionManagerType;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like trying each version manager so people can have multiple installed without issues, e.g. fnm for everything except mise for JSM. Problem is we should adjust the logs to be less noisy. Single output

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ATM it only checks if version manager directory is available but it doesn't check if node version is available in the version manager. This could be improved to choose version manager based on node versions available


}

public VersionManagerType getVersionManagerType() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super nit: don't really gain anything from getters/setters when this isn't API. IDEs ca refeactor this almost instantly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, it was autogenerated by IDE in the first place. Some of the getters have extra logic so using getters for everything makes it uniform

Copy link
Collaborator

@atl-mk atl-mk Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can probably avoid extraction if it's nested classclass, should be able to make public static nested. then it's only two line change

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exception is used in all the executor classes (BunExecutor, YarnExecutor, etc..). Nesting it will require changes in those classes instead AFAICS

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this cache shared between <executions> (the Maven definiton)? If so, will cause problems if configuration is changing (it can) between them?

@atl-mk
Copy link
Collaborator

atl-mk commented Dec 6, 2024

Sorry, I'm not trying to sound pass-agro, I reviewed, but I don't know the ansers yet till I read the code and play with it more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants